5

So, I read a lot about init systems in the last two hours, since this topic was completely new to me.

I now know that Raspbian Jessie uses SystemD. I also found out that systemctl list-units --type=service shows me a list of all SystemD services defined (services in /etc/systemd/system), which works fine as expected on my system.

On the other hand, I thougth that service --status-all shows all SysV services. Since Jessi uses SystemD, I thought that this would not even work, or return an empty list, but it also shows a good amount of services. I checked the /etc/init.d directory (which should store SysV services), which has a lot of files in it.

Question 1: Why does service --status-all show services, even though SystemD is the init system, and not SysV?

Question 2: Why is there a /etc/init.d directory, even though SystemD is the init system (whichs services are defined in /etc/systemd/system), and not SysV?

Improve this question
2
  • One word - compatibility.
    – Dmitry Grigoryev
    Sep 21, 2016 at 16:30
  • "...I now know that Raspbian Jessie uses systemd..." only by default you still have the Debian provided option to use an alternative should you wish, and it is possible to prevent the change away from the 30-odd year old System V initwhen upgrading from Debian/Raspian "Wheezy" to "Jessie"... 8-)
    – SlySven
    Nov 12, 2016 at 10:13

1 Answer 1

Reset to default
5

These are for SysV compatibility, which traditionally has been the most widespread init system used on GNU/Linux since its inception. I believe SysV scripts also have a degree of compatibility with BSD init, used on other contemporary POSIX operating systems. While none of that is actually part of the POSIX specification, some commonplace cross-platform software targeting a particular (linux, BSD) side of the family make use of it.

Although systemd has been around for about half a dozen years, it is only in the past 1-2 that it has become the predominant one used in the GNU/Linux world, after Debian gave up on SysV with version 8 and Ubuntu abandoned Upstart.

On Fedora, which started using systemd as the default 5 years ago, there is very little left in /etc/init.d but it does remain, together with a README which notes:

...traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization.

Commands like service are also implemented, although things like update-rc.d, which I think was a Debianism to start with, are not -- except on Debian (and derivatives including Raspbian). These Debian things like update-rc.d may remain indefinitely or may disappear in the next version or so, but I expect that systemd's implementation of more core SysV commands like service are permanent.

The current /etc/init.d/README on Raspbian is still the old Debian one. The Fedora one also includes this link which may be of interest:

https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

Beware that while systemctl list-units will show everything, service ---status-all only applies to this that are managed via an init.d script. There are various systemctl commands that have parallels to service --status-all:

  • systemctl list-units [--type=service]: Will show all "active" units (note if you read the key at the end, there are two contexts for the word "active").

  • systemctl list-units --all: Will show all available units.

  • systemctl list-unit-files: Similiar to the above, but simplified.

  • systemctl status: Used with no service name, this shows a process tree of everything descended from an init service -- which since all processes have parents except init itself, means all running processes. This makes it similar to pstree, but organized using the concept of "slice" groupings (see man systemd.slice).

All this is explained further in man systemctl.

Improve this answer
6
  • Great answer, thank you. Also for the additional link. One last thing: Do you know if it's planned to remove service in the future? Because I like service --status-all's output more than systemctl list-units --type=service
    – Markus Weninger
    Sep 21, 2016 at 17:15
  • 1
    I don't know but I would guess if they intend to support /etc/init.d then service will continue to exist. However, as per the man page, beware it applies only to actual SysV scripts, whereas systemctl should apply to anything actually started as a unit by systemd. E.g, my Fedora desktop only has two things in init.d and that's all service --status-all mentions.
    – goldilocks ♦
    Sep 21, 2016 at 17:26
  • 1
    There is a bit of a difference in those commands though; service is applied to everything with a file, even if it isn't being used. A correlate to that might be systemctl list-unit-files, except I presume that won't include unused init.d files, since those won't be "mapped into a service unit ... during system initialization". It would be all unused existent systemd units. I.e., there's nothing which covers everything, although systemctl list-units should cover everything actually in use.
    – goldilocks ♦
    Sep 21, 2016 at 17:26
  • 1
    Also, systemctl status, which gives a comprehensive tree of running processes related to init services (and every running process is, one way or another), may be more equivalent than systemctl list-units.
    – goldilocks ♦
    Sep 21, 2016 at 17:28
  • 1
    As a die-hard Sys V init user (even on my RPis running Jessie!) I would note that the output from service --status-all which runs the /usr/sbin/service shell script may be a little buggy in that the definitive [ + ] $SERVICE and [ - ] $SERVICE outputs are sent to standard output but the unknown [ ? ] $SERVICE output is sent to standard error - which might confuse things for a super-user script interpreting the output...!
    – SlySven
    Nov 12, 2016 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.