On 2014-07-15, Jonathan Billings billings@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