step
Signed-off-by: Brian Coca <briancoca+dev@gmail.com>

Expanded the documentation slightly.

This fixes handling of arguments (module argument) in service_control().
It is now locally scoped such that modifications to it, in the case of a
systemd host, do not later impact subsequent calls to service_control().
See issue #2449.

Without patch:
ansible-service[6177]: Command /usr/bin/systemctl stop cups cups , daemonize True

With patch:
ansible-service[6475]: Command /usr/bin/systemctl start cups , daemonize True

I also updated the comments to reflect the case where systemd is really
being called.

* 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.

Per LSB spec, consider service stopped if rc from 'service status' is 1.
Added comment with url to LSB spec reference.

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.

The service module made some assumptions about how a service should be managed based on what was installed on the system in terms of service
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.