On 2014-07-15, Jonathan Billings <billings at negate.org> wrote: > > Ok, I'll give some examples of my experiences. Warning: long post. Long, but really helpful. Thank you so much for putting your time in! > So, the things that have bothered me so far: > 1.) The order of the 'service SERVICENAME start|stop|status' options > is reversed for 'systemctl start|stop|status SERVICENAME.service' Yes, I've seen this too with initctl. Grr! But that's mostly cosmetic, and just something to get used to (as you have). > 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? > 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? Thanks for your patience in this sometimes frustrating thread. ;-) --keith -- kkeller at wombat.san-francisco.ca.us