Ubuntu – /etc/init.d/rsyslog {start | stop | restart} : Need this to work

Functionally, there is no difference between any of these invocation methods.

start and stop are symbolic links to initctl. service is a shell script that determines whether to execute the init script or use initctl.

The simplest way to see what is an Upstart job is to take a look at /etc/init/. Everything in there is an Upstart job. If you ls -l /etc/init.d/ you'll see every service and system task. The SysV init jobs will be real files, while the Upstart jobs will be symlinks to /lib/init/upstart-job which will properly invoke the Upstart job.

In other words, you can also invoke Upstart jobs by calling, for example, /etc/init.d/apport restart, though the output will suggest using service, start, or stop instead.

So, in practice it makes no difference (yet!). But if I were scripting something, I would certainly use service, start, or stop as there is almost no chance that will deprecated, whereas calling services through /etc/init.d/ could go away down the road (though probably not any time soon).

A note on disabling services: renaming the .conf file works, but I don't recommend it. You might disable a service that way, but if there is a package upgrade available, dpkg will copy down a fresh copy of the Upstart job and without intending it, your service is enabled again. The correct way to disable an Upstart job is to use a .override file which leaves the original job intact.

For example, to disable apport, simply create a file called /etc/init/apport.override that contains the word "manual".

# echo "manual" > /etc/init/apport.override

Personally, I would avoid using sysv-rc-conf. It may be safe enough to use it to modify SysV jobs, but I'm not sure; it doesn't seem to support Upstart jobs, and there's no way to tell form the interface which is which. I would stick with update-rc.d for managing SysV scripts.

For more Upstart information see:

1. The Upstart Cookbook: http://upstart.ubuntu.com/cookbook/
2. The command man 5 init: http://manpages.ubuntu.com/manpages/precise/en/man5/init.5.html

I would continue to use the pre/post inst scripts,

preinst - This script executes before that package will be unpacked from its Debian archive (".deb") file. Many 'preinst' scripts stop services for packages which are being upgraded until their installation or upgrade is completed (following the successful execution of the 'postinst' script).

postinst - This script typically completes any required configuration of the package foo once foo has been unpacked from its Debian archive (".deb") file. Often, 'postinst' scripts ask the user for input, and/or warn the user that if he accepts default values, he should remember to go back and re-configure that package as the situation warrants. Many 'postinst' scripts then execute any commands necessary to start or restart a service once a new package has been installed or upgraded.

see - https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html

The syntax of invoking start|stop|restart is written as a conditional, see https://www.debian.org/doc/debian-policy/ch-opersys.html section 9.3.3.2 Running initscripts

if which invoke-rc.d >/dev/null 2>&1; then

invoke-rc.d package

else

/etc/init.d/package

fi

so ...

if which service >/dev/null 2>&1; then
        service package <action>
elif which invoke-rc.d >/dev/null 2>&1; then
        invoke-rc.d package <action>
else
        /etc/init.d/package <action>
fi

and add another conditional for systemd when needed ;)

So yes, the proper way to start|stop|restart a service is with the appropriate wrapper script (invoke-rc.d / system), when possible, rather then calling the init script (/etc/init.d/package) and falling back to the /etc/init.d script when no wrapper is available.