* As the FIXMEs note: only exit if enable state is going to change.
* This is already handled in service_enable_rcconf() being called by both subclasses.
commit e057ea671395ec8847f920a63cf9524f5c8fde5f
Author: Ton Kersten <tonk@tonkersten.com>
Date: Thu Feb 28 13:02:25 2013 +0100
Fixed the service command not working
On Ubuntu 1[02].04 the service name was not recognized because
there is a SysV style init script, but not an upstart config file.
Example: The `ntp` client.
Also removed extra spaces at the end of the lines, while at it.
really due for some refactoring, but telling how a service is managed is
a little fuzzy anyway. on a systemd system typoing the service will now
give you a rather systemd specific error which is somewhat suboptimal.
management tools, which meant upstart services on CentOS6 were not startable. This tweak allows things like vmware-tools to be controlled
via the service module. More testing on other distributions (particularly with systemd) is presumably needed.
This adds "69" to the return codes from the status command that should be
considered as not running. At least "django-celery" uses this return code,
maybe others::
/venv/bin/python /code/project/manage.py celeryctl status
echo $? # 69 when not running.
A bit of googling let me to http://tldp.org/LDP/abs/html/exitcodes.html and
on a Ubuntu Server 12.10 I get::
~# cat /usr/include/sysexits.h | grep 69
#define EX_UNAVAILABLE 69 /* service unavailable */
I'm not sure if the content of sysexits.h is the same on other OS'es.
This updates apt, apt_repository, command, cron, easy_install, facter,
fireball, git, group, mount, ohai, pip, service, setup, subversion,
supervisorctl, svr4pkg, user, and yum to take advantage of run_command
in module_common.py.
This makes the line parsing a lot more robust (and easier to read).
Code supplied by @dhozac, thanks!
Remove re import because this is not used anywhere.
When trying to perform enabled=yes followed by enabled=no
against FreeBSD the module would die with the following error:
TypeError: sub() takes at most 4 arguments (5 given)
The target FreeBSD client (8.2) is running python 2.6.6. It seems the
extra 'flags' argument was added to re.sub() in 2.7.
In fixing this issue I have attempted to create a general atomic method
for modifying a rc.conf file. Hopefully this will make it easier to add
other rc based platorms. The strip/split magic was inspired by the user
module.
* Basically the moving parts from the original service module arranged in
subclasses.
* General structure and helper methods comes from the user module.
* Less forgiving to unsupported platforms: it requires a subclass per platform.
(This makes it easier to work on one platform without having to think about.
what other platform might be affected in unexpected ways).
* Now has basic OpenBSD support.
* Solaris support needs to be added.
Thanks to @dhozac for general advice and Linux testing.
Thanks to @bcoca for clearing up some FreeBSD questions.
In some cases (see issue #1067) with state=restarted, a failure to stop
the service (which wasn't running) would appear to the module to be a
failure to restart the service even though it successfully started the
service. This changes the behavior of the service module to focus
on the return code of the start command. If the rc of stop is not
0 and the rc of start does equal 0, it considers the service
successfully restarted. It then ignores the rc, stdout, and stderr
from the unsuccessful stop command.
* Migraed easy_install, pip, service, setup, and user.
* Updated fail_json message in apt_repository
* Fixed easy_install to not hardcode location of virtualenv in
/usr/local/bin/.
* Made handling of virtualenv more consistent between easy_install and
pip.
