3 ms·
I am just going to go over Upstart and systemd systemd: dependency based init system. A service is written by declaring which services need to be started for t
by CameronNemo 13y ago
I am just going to go over Upstart and systemd
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.
- gingerlime 13y ago> 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 [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1043332 https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/10433... [2] https://gist.github.com/mitsuhiko/d55199e9b1ad7fc65504 https://gist.github.com/mitsuhiko/d55199e9b1ad7fc65504
- CameronNemo 13y agoYou should use init-checkconf before enabling the scripts.
- gingerlime 13y agoThanks 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)
- b6fan 13y agoI 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.
- CameronNemo 13y agoSIGSTOP 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).