On Jul 15, 2014, at 4:16 PM, Keith Keller <kkeller at wombat.san-francisco.ca.us> wrote: > On 2014-07-15, Jonathan Billings <billings at negate.org> wrote: > >> 2.) Daemons under systemd don't really need to daemonize anymore. In >> the past, to start up a daemon process, you'd need to fork (or >> double-fork) and disconnect STDIN, STDOUT and STDERR file >> descriptors. This was just accepted knowledge. You don't need to do >> that anymore in systemd service units. Heck, write to stdout or >> stderr, it'll be recorded in the journal. Check out the >> openssh-server service unit, you'll see that sshd is run with -D >> there. Systemd supports daemonized services, it's just not necessary >> anymore. > > How is logging handled if services are printing to stdout? Does systemd > separate logs (if told to) so that e.g. my sshd logs are separate from > my postfix logs? Service stdout logging goes to the journal and is copied to rsyslog, log entries are tagged with the control group they came from, in addition to the process name, so it is easy to see any logs, whether via syslog or stdout, generated by any process in the sshd.service control group, or postfix.service control group. $ journalctl --follow _SYSTEMD_UNIT=sshd.service man systemd.journal-fields for a list of all the fields you can search on >> 4.) Debugging. Why is my unit not starting when I can start it from >> the command line? Once I figured out journalctl it was a bit easier, >> and typically it was SELinux, but no longer being able to just run >> 'bash -x /etc/rc.d/init.d/foobar' was frustrating. sytemd disables >> core dumps on services by default (at least it did on Fedora, the >> documentation now says it's on by default. Huh. I should test >> that...) > > Hmm, this seems most problematic of the issues you've described so far. > Is journalctl the way to get to stdout/err of a systemd unit? If a > service fails, where is that failure logged, and where is the output of > the failed executable logged? When you view the status of a service with systemctl it shows you the command line, when it last tried to start it, what processes are associated with the service if any are running, what the exit code was, and the last few lines from the journal of anything logged by that service, so is kind of a one-stop-shop. For example: $ systemctl status sshd sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled) Active: active (running) since Thu 2014-07-10 20:55:47 CDT; 4 days ago Process: 1149 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS) Main PID: 1164 (sshd) CGroup: /system.slice/sshd.service └─1164 /usr/sbin/sshd -D Jul 10 20:55:47 localhost systemd[1]: Starting OpenSSH server daemon... Jul 10 20:55:47 localhost systemd[1]: Started OpenSSH server daemon. Jul 10 20:55:48 localhost sshd[1164]: Server listening on 0.0.0.0 port 22. Jul 10 20:55:48 localhost sshd[1164]: Server listening on :: port 22. $ sudo systemctl stop sshd $ systemctl status sshd sshd.service - OpenSSH server daemon Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled) Active: inactive (dead) since Tue 2014-07-15 17:29:09 CDT; 3s ago Process: 1164 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS) Process: 1149 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS) Main PID: 1164 (code=exited, status=0/SUCCESS) Jul 10 20:55:47 localhost systemd[1]: Starting OpenSSH server daemon... Jul 10 20:55:47 localhost systemd[1]: Started OpenSSH server daemon. Jul 10 20:55:48 localhost sshd[1164]: Server listening on 0.0.0.0 port 22. Jul 10 20:55:48 localhost sshd[1164]: Server listening on :: port 22. Jul 15 17:29:09 localhost systemd[1]: Stopping OpenSSH server daemon... Jul 15 17:29:09 localhost sshd[1164]: Received signal 15; terminating. Jul 15 17:29:09 localhost systemd[1]: Stopped OpenSSH server daemon. — Mark Tinberg, System Administrator Division of Information Technology - Network Services University of Wisconsin - Madison mtinberg at wisc.edu