goss

uring program logs from all processes on a machine, and that's what systemd offers me. Syslog by itself does not achieve this goal. How do you recommend capturing and logging program output, if not by having the supervisor do it? (And why is that approach preferable?) The journal is an integrated part of the systemd toolkit, and that's a good thing because it enables useful capabilities like capturing stdout and good user experiences like `systemctl status`. But you don't have to interact with it. If you prefer the syslog toolchain instead, then redirect the journal to syslog via ForwardToSyslog=yes in journald.conf. The journal still adds value with this approach because it captures logs that syslog can't (and without kludges like `logrotate` and `logger`). You can see more log lines with e.g. `systemctl status -n50`. If you want to see everything, invoke `journalctl -u service-name`. I view the systemd journal as a logging facade, a complement to facilities like syslog, not an alternative to it. As Russ said in my quote above, "systemd is agnostic to the underlying syslog implementation." I'm not sure I grasp your point about dbus. I have not seen anyone make the argument that dbus should be part of a zombie reaper or process supervisor. However, IPC is a useful and sensible way for processes on the system to communicate with their process supervisor, which is why both systemd and upstart integrate with dbus. I've read that it is possible to use systemd without dbus [1] (there are apparently Debian configurations that work this way), though I haven't deeply looked into it. If you want to launch supervised processes with clean environments, namespaces, and cgroups, then it is necessary for a system process to be the one that forks. Communicating that request between processes necessitates IPC. As the most widely adopted IPC system for Linux, dbus was an appropriate choice for systemd and upstart to integrate with. Again, going back to our anchors: Is there another IPC framework you think systemd should have integrated with instead? Or if not by using IPC, how do you think service management commands (e.g., restart a service) should be communicated to the system? [1] E.g. https://github.com/mitchellh/vagrant/issues/7973 https://github.com/aelsabbahy/goss/issues/101

ec, almost same syntax, made by the chef guys * https://github.com/philpep/testinfra - Python, don't know much about it, but mentioning it since Ansible is Python. Spend a little bit of time experimenting with all of them, see which one you like. Full disclosure: I'm the author of goss.