14

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.

ilkkachu
  • 133,243
  • 15
  • 236
  • 397
sorin
  • 1,219
  • 2
  • 14
  • 18
  • 5
    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. – jasonwryan Oct 01 '15 at 06:55
  • 1
    Extra: if service command become useless, can I remove it? What package provides it? – sorin Oct 01 '15 at 06:55
  • 3
    Doesn't make sense to replace the old `service` command with a wrapper that calls servicectl instead? – sorin Oct 01 '15 at 06:59
  • It's a *completely* different init system: and you can do a lot more than just start/stop/restart. – jasonwryan Oct 01 '15 at 07:14
  • 4
    @jasonwryan Yes, but you also can do *just that*, and a wrapper could handle it, making the transition to systemd smoother for the users. – Dmitry Grigoryev Oct 01 '15 at 07:29
  • 1
    @DmitryGrigoryev Sure. It just prolongs the inevitable, though... – jasonwryan Oct 01 '15 at 07:31
  • 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! – sorin Oct 01 '15 at 10:54
  • 3
    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. – terdon Oct 01 '15 at 10:56
  • 1
    OpenSUSE 13.2 still provides `service` as a wrapper around `systemctl`. – Martin Schröder Oct 07 '15 at 20:11

4 Answers4

8

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 ;)

DanSut
  • 592
  • 4
  • 14
  • And prior to this was xinetd, and prior to that was inetd – jas- Oct 01 '15 at 11:06
  • @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. – DanSut Oct 01 '15 at 11:21
  • 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. – jas- Oct 03 '15 at 12:37
  • Ubuntu used upstart since 6.10 and Fedora since 9 (until they were replaced by systemd) http://upstart.ubuntu.com/, and it's been possible to switch Debian away from sysvinit for quite a few years... – James Tocknell Oct 06 '15 at 00:19
6

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

JdeBP
  • 66,967
  • 12
  • 159
  • 343
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.

Evgeny Vereshchagin
  • 5,286
  • 4
  • 35
  • 43
  • Somehow it seems that Ubuntu guys were able to keep the service script working after switching to systemd. Looking inside it seems to be smart enough to use the right backend. Cannot say the same about Debian. – sorin Oct 02 '15 at 08:41
  • @sorin, well, [service(8): use systemctl on machines that run systemd](http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/debian/service/service?id=aaf0b7a3485f6cfc5b2c0edf9d4e48c53088ce98). 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](http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/tree/debian/service/service#n202). Is it ok? – Evgeny Vereshchagin Oct 02 '15 at 11:49
  • @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.](http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/tree/debian/service/service#n215). Is it ok? – Evgeny Vereshchagin Oct 02 '15 at 12:10
1

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.

YoMismo
  • 4,005
  • 1
  • 15
  • 31