systemd: dependency based init system. A service is written by declaring which services need to be started for that service to start. It is also a syslog like program (journal) and a cgroups writer (cgroups are a cointainment feature of the linux kernel). It also features socket activated and bus activated services, where the init system watches for a socket or dbus bus to be accessed, and then starts the job then. It is criticized for being too invasive and too tied to linux kernel features (like cgroups).
Upstart: an event based init system. Jobs start and stop on a certain event (or events). These events can be socket events, dbus events, udev events (network-device-added, removed, changed, etc.) or job events ($JOB-started, stopped, starting, stopping). There are also other events, but those are the basics. It suffers in two areas: socket activation is limited to one tcp or unix socket (no UDP, no tcp6, no DGRAM), and it unreliably stops services. The former is a simple problem that would not be too much work to fix (the developers of Upstart did not want to use socket activation, so they decided to stop efforts on developing it), and the latter is a fundamental code problem. Upstart uses ptrace to track daemons, while systemd uses pidfiles and cgroups. Because Upstart does not use cgroups, it can not kill all of a services children (just that service), and so zombie services might be problematic.
> Because Upstart does not use cgroups, it can not kill all of a services children (just that service), and so zombie services might be problematic.
from my (very limited) experience with upstart, even the upstart scripts themselves can get into a unrecoverable zombie state[1], where the only workaround is to do one of the following 1) reboot ; 2) run some crazy-ass script[2] that forks processes until the right pid is grabbed to then kill it ; 3) rename the upstart script
Thanks for the tip. An init system that gets itself into such a fragile position is a signal that something isn't quite right (not to mention there was not even a response to this bug report, which isn't a great sign either)
I have used ptrace and cgroup (in an online judge system). The cgroup way feels more correct and stable while ptrace feels a hack. The usage of ptrace and SIGSTOP in upstart looks pretty ugly to me.
SIGSTOP is actually pretty clean, but it takes away some debugging methods from the sysadmin. Please note that systemd uses PID files to track services, which is an incredibly horrible method (although not as bad as ptrace).
systemd: dependency based init system. A service is written by declaring which services need to be started for that service to start. It is also a syslog like program (journal) and a cgroups writer (cgroups are a cointainment feature of the linux kernel). It also features socket activated and bus activated services, where the init system watches for a socket or dbus bus to be accessed, and then starts the job then. It is criticized for being too invasive and too tied to linux kernel features (like cgroups).
Upstart: an event based init system. Jobs start and stop on a certain event (or events). These events can be socket events, dbus events, udev events (network-device-added, removed, changed, etc.) or job events ($JOB-started, stopped, starting, stopping). There are also other events, but those are the basics. It suffers in two areas: socket activation is limited to one tcp or unix socket (no UDP, no tcp6, no DGRAM), and it unreliably stops services. The former is a simple problem that would not be too much work to fix (the developers of Upstart did not want to use socket activation, so they decided to stop efforts on developing it), and the latter is a fundamental code problem. Upstart uses ptrace to track daemons, while systemd uses pidfiles and cgroups. Because Upstart does not use cgroups, it can not kill all of a services children (just that service), and so zombie services might be problematic.