When I start a service such as:

root@foo [~]# service foobar stop
Stopping Foobar:                                       [  OK  ]

I can see a status indicator: [ OK ] which is different from the one visible on /var/log/boot.log:

[  OK  ] Started LSB: disk temperature monitoring daemon.

Or even different from:

* /proc is already mounted
* Caching service dependencies ...        [ ok ]

In these three examples which process is responsible of displaying and starting the daemons? Said differently, which library is used to display [ OK ], [FAILED]?


When a manual invocation of service runs a SysV style script from /etc/init.d or /etc/rc.d, all status output depends entirely on that script.

Properly written init.d scripts will use a library of shell functions provided by the distro. For example, in Debian, most scripts will load (source) the file /lib/lsb/init-functions, and simply call its provided functions like this:

case "$1" in
    log_daemon_msg "Starting $DESC" "$NAME"
    case "$?" in
        0|1) log_end_msg 0 ;;
        2) log_end_msg 1 ;;

Here's the list of standard functions defined by LSB. (Note that distros may provide additional functions beyond the standard, as the example above. Also note that e.g. OpenRC or Arch Linux aren't LSB-compatible and use entirely different styles.)

In fact, some distros will provide this boilerplate code centrally as well, and all that's left to the init.d script is to implement do_start. (See Gentoo's OpenRC and Debian's /lib/init/init-d-script as examples). However, that's not a "standard" LSB feature – scripts trying to be LSB-compatible still have to do it manually.

Note: I emphasize 'Properly written' because really there's nothing that would force an init.d script to use these functions, other than human supervision. If the script wants to report status via plain echo (or via cowsay for that matter), it is always able to do that. This is especially a problem with commercial software distributed outside the normal channels: their status output never looks quite right (and frankly, the whole init.d script never behaves quite right).

Meanwhile, when SysV scripts are called during the boot process, the result is even more distro-dependent – sometimes you'll see output directly from the scripts themselves, but sometimes the "main" init system will provide its own status output for all services it starts. (Example: Arch Linux's old initscripts, when starting a service in background.)

But your 2nd example is actually not a SysV style init – it's systemd (which just happens to be starting a 'legacy' init.d script in your example). Systemd is a full service manager which uses service configurations (not scripts), and therefore all boot/shutdown status output is provided by systemd itself. This also applies to most other "service managers", including init-ng, SMF, or Upstart.

  • I took a quick look at /lib/lsb/init-functions, but when I try to execute [ 1 != 2 ] && log_end_msg 1 I get ` ...fail!` not [fail]. I am a bit confused. – nowox Jun 6 '18 at 8:41
  • @nowox: You probably want log_failure_msg then. (init.d scripts aren't very consistent in what functions they use. My Debian sid system has a mix of several different styles.) – grawity Jun 6 '18 at 8:44
  • 1
    @nowox: Indeed the actual LSB specification specifies log_success_msg and log_failure_msg for this purpose. (Though of course many distros used non-LSB-conformant scripts...) – grawity Jun 6 '18 at 8:58

This comes from distro-dependent init scripts. Check contents of service program, this is probably some shell script invoking underlying managements scripts (SysV are considered obsoleted now) or binaries (systemd is the way to go). This is one of the systemd pros - you won't get "that depends" answers.

  • ...because systemctl start has no feedback output whatsoever. – grawity Jun 6 '18 at 8:09
  • ... and it seems systemctl relies on start-stop-daemon. – nowox Jun 6 '18 at 8:10
  • No, systemctl doesn't rely on start-stop-daemon, unless you use some braindead distro. – Tomasz Pala Jun 6 '18 at 8:11
  • 1
    @grawity - yes, there is no output, as the [OK] message was nothing more than a lie, because it was only the status of some first-stage start, before forking and deamonization. Very often a deamon died seconds after that. The only message that was reliable was [FAILED], which sometimes meant only, that the service ...was allready running, but the service command didn't know that. – Tomasz Pala Jun 6 '18 at 8:13
  • 1
    Or, occassionally, none of the above – grawity Jun 6 '18 at 8:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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