4

I run Debian 8 jessie.

I have activated a daemon's debugging facility, which causes the daemon to print debugging info to stdout and/or stderr. How can I persuade start-stop-daemon(8), as invoked by /lib/lsb/init-functions, to redirect the daemon's stdout and stderr to my debugging log file /root/log?

It appears that >/root/log 2>&1 is ineffective. I suppose that this makes sense, since start-stop-daemon(8) is not a shell. At any rate, how shall I redirect the daemon's stdout and stderr?

[The daemon happens to be exim4(8), but this is not relevant to my question as far as I know. LSB evidently delegates the management of the daemon to Systemd; this could be indirectly relevant for all I know.]

thb
  • 1,135
  • 1
    You do have a systemd .service for exim, right? Or, otherwise, how do you invoke start-stop-daemon. Remember, you do not need to run exim directly through start-stop-daemon you can run a script that performs the redirection (but that's a little hacky since you cannot use --pidfile) – grochmal Oct 01 '16 at 21:19
  • @grochmal: Good question. I am debugging Exim as packaged by Debian's maintainer. Therefore, it would defeat my purpose to work around the packaging. I need to use the packaging. dpkg -L exim4-base shows no .service file. Exim4 as such seems to be unaware of Systemd. Apparently, Systemd is involved only through the medium of /lib/lsb/init-functions.d/40-systemd. As to running a script, I had indeed thought of that, but, as you say, it seemed hacky. I just wondered if there was not a right way to do it. – thb Oct 01 '16 at 21:29
  • 1
    I never use start-stop-daemon so i'm not of great help. But maybe a script is not that terrible. Have a look at this question about making a script relay signals. i.e. using exec is the simplest way to make the output redirection and then reuse the PID (exec >log 2>&1; exec exim --stuff). – grochmal Oct 01 '16 at 21:47

1 Answers1

2

Trying to pass magic options through the various layers of shell scripting is entirely the wrong way to go about this on a systemd Linux operating system.

systemd already logs the standard outputs/errors of services that are auto-generated by the "sysv" service generator, as this one is. The "sysv" service generator has made an exim4.service (somewhere under /run/systemd) that invokes your /etc/init.d/exim4 as the service.

There's no delegation going on. Your rc scripts aren't in charge of the service in the first place. They're simply being run as handy proxies for it.

So what you need to do is look at the already captured log output for the exim4.service service. This will either be in the journal or in whatever syslog variant you have arranged to feed off the journal.

For the latter do whatever is appropriate for your syslog variant. For the former, observe that systemctl shows you the recent journal entries for the service whenever you run

systemctl status exim4.service
with appropriate privileges (superuser or membership of the systemd-journal group). You can also view the journal entries for the service since the last bootstrap (that the journal has not already rotated off) with
journalctl -u exim4.service -e -b

exim under proper service management

Ironically, all of that rc script monstrosity can be replaced with some fairly short exim4-queue.service, exim4-smtp-relay@.service+exim4-smtp-relay.socket, and exim4-smtp-submission@.service+exim4-smtp-submission.socket service and socket units.

Also note that it is a falsehood that exim conflates "foreground" and "debug"/"verbose". Its -bdf option is explicitly the non-"dæmonizing" version of -bd, although to invoke it as a per-connection "socket-activated" dæmon (as per the examples in the further reading) where the service management tools handle the listening socket, one would use -bs rather than -bdf anyway.

Further reading

JdeBP
  • 68,745
  • +1 Good answer. Excellent links. The only reason I have not yet accepted the answer it is that it does not happen to solve my particular problem. Why not? The reasons would probably not interest you, but basically, the daemon I am using normally disconnects itself from the controlling terminal, only not if debugging is switched on. I prefer to test with minimum hackery. I could explain much more, but no one has asked me to, nor would my explanation be pertinent to the question asked, so I'll leave it there. Your answer looks good, thanks. – thb Oct 03 '16 at 13:46