Is there a standard way to start and stop services on Linux?

Question

Until recently there was a simple and effective way to start/stop/restart services:

service nginx start|stop|restart

This worked perfectly for so many years,... until the distribution switched to systemd and now I am facing with Debian/Ubuntu systems where the service script does nothing (as I am supposed to use the stuff like systemctl start nginx.service (much much longer, no auto-complete working,...)

My question refers specially to Debian and Ubuntu but it would also be helpful to cover CentOS/RedHat distros too.

In case it was not clear, I am looking for a consistent way to deal with those, one that would work on Debian 7.x, 8.x, latest Ubuntu LTS and non-LTS.

PS. Outside the scope of this specific question, but extra kudos granted if the solution would also cover the enable and disable part for the services.

Solution 1

There have been a number of varied boot and service control systems across Unix platforms over its tangled history.

The service\chkconfig based system you found simple and effective is generally referred to as SysVinit style and was a major step along the way to some sort of standardization. You will find this style of boot on RHEL/CentOS(EL) through the 6 release, Fedora through 14, and on Debian/Ubuntu based distributions up until 2015. It was not the only boot system around though, the (simpler) BSD style init system still has many fans.

SysVinit was not a perfect solution (what is?) and Systemd was devised to overcome many of the issues; this is the systemctl command based system you are now experiencing. Although it is not universally liked (people hate change, bloat, etc) there is no doubt that it is fast becoming the defacto standard across the majority of distributions.

Therefore, looking immediately forward the answer to your original question is simply:
The standard way to control services across most Linux distributions is now systemctl!
How long this will hold true is anyone's guess; probably just until something comes along that is better and becomes widely adopted.

I'm sure there will be wrappers available to allow, your current favorite, the service/chkconfig commands to continue to do mostly sane things, but with this particular learning curve it is probably best not to fight it. Maybe looking forward, for a time there'll also be systemctl wrappers for older systems, to make managing them alongside more current ones less of a pain ;)

Solution 2

Doesn't [it] make sense to replace the old service command with a wrapper that calls servicectl [sic] instead?

Yes, but […] a wrapper could handle it, making the transition to systemd smoother for the users.

… which is, as others have said in comments, what has been done long since.

The /usr/sbin/service command on Debian 8 is part of the sysvinit-utils package. It has been there since 2009. It's a Debian-specific RedHat-originated addition to the original sysvinit source package, and as can be seen from reading the script it recognizes both systemd running and the presence of upstart jobs, farming out commands to systemctl and initctl (via its aliases) respectively. This it has done since 2013.

service name action is quite widely available even on non-Linux operating systems. It will even work on most of the BSDs, as they too have their own service commands. There is also a shim service command in the nosh package that translates to system-control action name. But …

• … get beyond this common subset, and there's far less compatibility all around.
• … OpenBSD has no service command.
• … the BSD service commands have well-known problems of long standing that system administrators have been telling war stories about for decades.

Enabling and disabling services is a similar situation. Although the SuSE chkconfig program (available packaged for Debian and Ubuntu) is very different to the the Fedora one (they being written in entirely different programming languages, even — one compiled, one interpreted), there is a common minimal chkconfig name action syntax, with action being on or off. But …

• … again, beyond this common subset there is less compatibility.
• … there's no chkconfig on the BSDs, as the conventional tools for this are either sysrc or the more recent OpenBSD rcctl enable and rcctl disable. There are chkconfig and rcctl shims in the nosh package that translate to system-control enable name and system-control disable name.
• … only the Fedora chkconfig knows about systemd and acts as a shim for systemctl enable and systemctl disable. The SuSE chkconfig has no knowledge of systemd.

Further reading

• "Download sysvinit-utils: List of files". sysvinit-utils package. Debian 8 packages.
• script/service. init-system-helpers. Debian source archive.
• Jonathan de Boyne Pollard (2015). telinit. nosh Guide. 1.20. JdeBP's Softwares.
• Jonathan de Boyne Pollard (2015). No more problems with the service command. nosh pages. JdeBP's Softwares.
• chkconfig package. Debian 8 packages.
• "Does chkconfig command work with systemd?". systemd. Fedora project wiki.
• "Does service command work with systemd?". systemd. Fedora project wiki.
• Douglas Barton (2012-12-11). service. §8. FreeBSD Manual Pages.
• Antoine Jacoutot (2014-08-19). Introduce rcctl(8), a simple utility for maintaining rc.conf.local(8).. OpenBSD CVS.
• Jonathan de Boyne Pollard (2015). The nosh package. JdeBP's Softwares.

Solution 3

There is no standard way to start and stop services on Linux.

is there something that can save me from this doomed changes?

Try the configuration management/orchestration tool: Ansible, Chef, Saltstack, Puppet or whatever.

You can start and enable a service with Ansible:

ansible all -i inv -m service -a 'name=service-name state=started enabled=true'

Take a look at the LinuxService class in the Ansible's service module:

This is the Linux Service manipulation class - it is currently supporting a mixture of binaries and init scripts for controlling services started at boot, as well as for controlling the current state.

Solution 4

Your problem is that Debian/Ubuntu have switched to the new systemd as a replacement of the old sysvinit. Ask which one is better and you will start a flame war, but you can allways switch back to the old sysvinit, check this if you want to go back.

View more solutions

Comments

[Admin]

Tab completion works for systemctl for me... And, like it or not, systemd is the de facto standard now: may as well get used to it.

[Admin]

Extra: if service command become useless, can I remove it? What package provides it?

[Admin]

It's a completely different init system: and you can do a lot more than just start/stop/restart.

[Admin]

@jasonwryan Yes, but you also can do just that, and a wrapper could handle it, making the transition to systemd smoother for the users.

[Admin]

@DmitryGrigoryev Sure. It just prolongs the inevitable, though...

[Admin]

Thanks Dmitry, it seems that those working on improving those systems do lack UX skills. Planning for easy migration seems to be something of less importance. This does apply to both, system.d and upstart. Keeping the old API working does apply for command line too!

[Admin]

Does service really do nothing for you? It works as expected on my LMDE (which is basically Debian testing), I didn't think that was an LMDE-specific thing. It also works as expected in my Ubuntu VM.

[Admin]

OpenSUSE 13.2 still provides service as a wrapper around systemctl.

[jas-]

And prior to this was xinetd, and prior to that was inetd

[DanSut]

@jas- I think the inetd's are really services themselves, I believe they can exist within all boot systems. They are a special kind of service in that they provide an alternative for some other services to running as full services, by instead providing them on-demand. I understand where you are coming from in the context of this Q though, just another way of starting services.

[Evgeny Vereshchagin]

@sorin, well, service(8): use systemctl on machines that run systemd. But When running "service foo stop" and foo happens to be a service that has one or more .socket files, we also stop the .socket units. Is it ok?

[Evgeny Vereshchagin]

@sorin, also The reload action falls back to the sysv init script just in case the systemd service file does not (yet) support reload for a specific service.. Is it ok?

[jas-]

In all distributions; gentoo, centos, redhat, debian, ubuntu etc., xinetd and previously inetd consisted of small shell script to start, stop & reload configurations for various services, but yes you are correct they were indeed a service just like systemd is.

[James Tocknell]

Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) upstart.ubuntu.com, and it's been possible to switch Debian away from sysvinit for quite a few years...