Ubuntu – When we enable any service using systemctl, in which runlevel would that service run

Before I'd asked my question, I didn't know about upstart. For those interested, upstart is an event-driven (instead of a state-transition driven) replacement for the old "System V init" system.

To get to the point and skip the documentation, have a look at the /etc/init folder. You'll find several .conf files in there. Editing these files allow you to control at which runlevels different services come up and go down. These include samba4.conf, which was the main one I was concerned about (as this also controls ldap, kerberos, etc).

I initially went to /etc/init.d/rc2.d and wondered why there were no entries for samba there.

Just to confuse the issue, bind9 (along with other services) is still configured via the old system V init scripts in /etc/rcx.d, so, I rm'd /etc/rc2.d/S15bind9 and made a symlink K15bind9 to the same target in /etc/rc2.d/

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