Can anyone give a quick rundown of the different init systems?
For the most part it can get confusing for a non day to day system administrator when I am trying to get a program to "run on boot". Between rc.local, init.d, run levels, etc. sometimes it is just frustrating.
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).
Just my two cents as I haven't seen it mentioned in this thread:
launchd is the init system used by Mac OSX and has been ported to FreeBSD a few years ago with a recent resurgent effort for improvements [1]. It has been suggested that launchd could one day be the new FreeBSD init system due to speed and feature improvements, but many FreeBSD users think that the init system is a non-issue and efforts could be better spent elsewhere. launchd has also been criticized as to have been developed for OSX and not BSD (e.g. it depends on CoreFoundation features).
There is growing concern that applications will become more reliant on systemd and therefore Linux-only features [2], reducing or eliminating portability to the BSDs. Unfortunately, most conversations about init systems and FreeBSD degenerate into flame wars [3].
IIRC, when a presentation a few years ago at Chaos Communication Congress revealed systemd security issues, Lennart Poettering argued that these issues aren't a problem because they're resolved on Solaris and will be as soon as Linux gets some additional security mechanism. That sounded to me like systemd would also (theoretically) support Solaris.
Solaris had an init system like systemd for some years, called SMF. It was first released in 2005, the same year Apple released launchd.
It features service dependencies, log collection, fault detection and much more. One of the biggest differences is probably the usage of config files. SMF uses XML files to describe the service and its variables and a program called svcprop to edit variables and create new instances of the service. These can then be managed with svcadm.
I was aware of that, and it wasn't my point. I was talking about the supposed portability of systemd. The question remains, is systemd really Linux-only, or portable to some degree?
I can give a simplified overview of the major difference as I understand it (the difference being the method by which each init system starts its daemons on boot):
sysvinit/bsdinit - Starts daemons in serial (i.e. synchronously). Considered slow and outdated by today's standards.
upstart/launchd - Starts daemons in parallel, based on which daemons depend on each other (If B depends on A, A is started first. If C doesn't depend on anything. C is started at the same time as A. If D depends on C, D is started at the same time as B, and so on).
systemd - Creates all the necessary sockets for each daemon beforehand, and starts nearly all processes in parallel.
Aside from that, they're all configured differently, but if the competition is primarily over speed, systemd wins every time due to its clever design. the newer inits also include a lot of handy tools that aren't part of a traditional init, but that's a different story.
upstart doesn't have dependencies thats systemd. Upstart you have to specify when a service should start based on events or combinations of events like "start on started avahi and started nfs". Theoretically this make upstart more flexible though complex event handling is mostly broken. This system also means upstart ends up trying to start everything it can it might start a service which is not needed but because it's start on event has activated it starts. systemd differs in that only required services for that .target are started (and services required by those.
systemd has Require/Wants to specify dependencies as well as the socket activation features. Socket activation requires a compliant daemon as well so a lot of services still use explicit dependencies. Socket activation does give you a lot of other stuff for free, listening on privileged ports as user, restarts without dropping connections, delayed start (not starting until requests come) etc.
I know less about the new Linux ones, but a brief summary of the two big "traditional" ones:
Linux systems traditionally use "SysV Init", the init system from AT&T UNIX System V (1983). It's the one that has: 1) run levels; and 2) a pile of shell scripts in /etc/init.d that run on run-level changes. Run levels probably make most sense if you think of Ye Olde Mainframe booting: first it initializes core services, then it enters multi-user mode, then it initializes network services, then (optionally) it enters full application mode. These are supposed to be discrete, semantically meaningful boot levels that you could purposely initiate: boot to runlevel 1, boot to runlevel 2, drop back to runlevel 1. Dependencies are handled by a mixture of those runlevels, and scripts that are run in alphabetical order within run levels. That ordering (unlike runlevels) is not supposed to be meaningful to the sysop, but just necessity-based: some stuff depends on other services already being started, even if conceptually you want them all "at once". The convention is to prefix startup-script filenames with numbers that effectively serve as priorities within a runlevel.
BSD systems traditionally use their own "BSD init". There are no runlevels, though there is still a separate "single-user mode" for maintenance. In classic BSD startup was just one very large shell script in /etc/rc. In later versions it was augmented by an /etc/rc.local script that allowed local modifications to be made without mucking with the main script. Modern BSDs (starting with NetBSD, later adopted by the others) modularized it, with an /etc/rc.d directory (base system) and /usr/local/etc/rc.d/ directory (ports). This differs from SysV init in that it still has no run levels, and rather than explicit ordering via filename sorting, has dependency-resolution ordering via semantic comments at the top of each script that are parsed and resolved by rcorder(8) (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8). Afaik this system, originating in NetBSD, was the first dependency-based startup system on a free Unix (I believe commercial Unixes like Solaris also moved to dependency-based init in the 2000s).
Many Linux vendors have decided that SysV Init is not such a nice system nowadays, because it involves maintaining fairly complex scripts with edge cases that have to be handled in every script through error-prone boilerplate, and an explicit global startup ordering: all programs that can be installed on Debian and need startup must be assigned an integer that fully specifies their position in the startup sequence relative to all other programs that might also be installed. Runlevels as a mechanism also seem pretty unhelpful for most uses people have nowadays. Instead there is a hope for some kind of dependency-based startup. But the big disagreement is over what to replace it with. It is also complicated by other changes that are happening in parallel and which are caught up in it. For example, Linux's 'cgroups' resource-control mechanism has long been in the kernel, but not widely used by userspace tools, and there are moves to sort out this situation by essentially letting the init system also own resource assignments, which would more tightly couple those components. This is probably where the big philosophical differences come in.
Services are defined in XML files called manifests, which specify dependencies (including filesystems and network connectivity), the user and group to run as, timeouts for start/stop, and a bunch of other stuff.
The cool part is that, while the manifest files are static, SMF doesn't actually use them directly. The service definitions get slurped into a DB, and you can change properties (such as the whether or not the service is enabled, the user to run as, and pretty much anything else the manifest author thought of) on the fly, without editing a manifest or mucking with symlinks.
SMF also starts services in parallel (Solaris/OpenSolaris boot really, really quickly), and services that die are automatically restarted (so long as they're dying again too quickly).
Debian already has dependency based boot based on magic comments at the top for their syvinit scripts. The program used is called insserv and is something they got from Suse.
For the most part it can get confusing for a non day to day system administrator when I am trying to get a program to "run on boot". Between rc.local, init.d, run levels, etc. sometimes it is just frustrating.