. /lib/lsb/init-functions
log_daemon_msg "this is a daemon s message"

On the shell console, it prints,

this is a daemon s message

A daemon process doesn't have stdout at all. So why do daemon startup scripts write to stdout? Are they not supposed to use syslog file? How can I redirect the init logs to a system log file so that I can debug boot time issues? I am using Ubuntu 14.04.

  • My first guess is that syslog is handling these messages as important that they are printed to the console.
    – Lambert
    Mar 27, 2015 at 13:27
  • no, i don't see /etc/init.d/ssh log_daemon_msg stuff inside my /var/log/syslog. and log_daemon_msg source code also doesn't have the logic to write messages to a file.
    – user93868
    Mar 27, 2015 at 13:33
  • From what I've read, the lsb init functions are used while stopping and starting services and print status messages like [ OK ], or [ Failed ]. See refspecs.linuxbase.org/LSB_3.0.0/LSB-generic/LSB-generic/… for details
    – Lambert
    Mar 27, 2015 at 14:58

1 Answer 1


A daemon process doesn't have stdout at all.

Not true. If one's dæmons are being managed by one of the daemontools family of toolsets (https://unix.stackexchange.com/a/179798/5132), then the dæmon will have inherited an open standard output file descriptor, for a pipe that connects it to a logging service. If one is using systemd, then (in the default configuration) the the dæmon will have inherited an open standard output file descriptor, for a socket that connects it to the systemd journal service.

In any case, you are conflating the init.d script, which manages the dæmon, with the dæmon itself. With System V rc and with systemd, the init.d script merely causes the starting and stopping of the dæmon process proper. (In the System V rc case it does this with helpers such as start-stop-daemon. In the systemd case, it uses systemctl to send commands over D-Bus RPC to process #1.) It isn't the dæmon process itself.

The standard output of the dæmon process isn't necessarily any relation at all to the standard output of the init.d script. And it's the standard output of the latter that you are addressing with log_daemon_msg. This shell function, and its relatives, print friendly messages from the dæmon management script, showing what the management script is doing as it attempts to enact dæmon control commands. They aren't being used in the dæmon itself.

Ironically, since daemon management is done differently with systemd, all of the log_daemon_msg commands become irrelevant, since any management script that sources /lib/lsb/init-functions ends up diverting all control commands to systemctl.

How can I redirect the init logs to a system log file so that I can debug boot time issues?

You have a task. You've decided that a subtask of that task is somehow addressible with log_daemon_msg, and here you are asking how to get log_daemon_msg to do something that it wasn't designed to do. Concentrate upon your real question.

Ubuntu 14.04 uses upstart. That has an /etc/init/rc.conf upstart job that provides backwards compatibility with System V rc by actually running System V rc whenever a runlevel event occurs. This job is listed in the upstart Cookbook and as you can see uses the console output stanza.

As you can see from the Cookbook, with upstart — as well — dæmons (by default) inherit an open standard output file descriptor that is connected to upstart's per-job logging mechanism. Yet again, the notion that dæmons "don't have standard output" is wrong. The /etc/init/rc.conf job uses the (non-default) option of connecting the standard output to the console. This of course also redirects the output of the various dæmon management scripts that System V rc spawns, in its turn.

So if you want to log the output of your /etc/init/rc.conf job, and all of the System V management scripts that it spawns, elsewhere, modify that job specification.

If you want to debug boot-time issues, then employ the mechanisms that are described in the upstart Cookbook (and also on the AskUbuntu Stack Exchange in several answers) for boot-time debugging.

Further reading

You must log in to answer this question.