Systemd is inspired by Apple's launchd (which has an unfortunate license) and has a few really nice features:
- Many traditional init systems are based on a bunch of shell scripts with some metadata. Each service is started through a shell script that supports the start/stop/restart argument. While this makes the implementation very simple, it also makes it inefficient. To start a service the init system must create a new process (the shell script) which in turn invokes a bunch more processes (because almost anything you do in a shell script requires external commands) before finally invoking the service itself. This is expensive in terms of both CPU usage and disk I/O, and the latter really matters for boot time. Systemd accepts a bunch of service description files and handles the starting and stopping for you.
- Traditional init systems are about starting and stopping services. Systemd is also about keeping services running. For example if a daemon crashes, with most init systems you have to restart it manually or hook it to some external monitoring system. External monitoring systems usually rely on polling to check whether services are still alive. Systemd on the other hand just forks() the service, waitpids() on it, and gets notified by the kernel when the services crashes. No polling involved. Polling wastes CPU and reduces battery life. Polling also makes leaves a small time gap during which the service is temporarily dead but hasn't been restarted yet. This latter can be mitigated with a smaller polling interval but the smaller this interval the more CPU you use.
- Systemd supports on-demand starting of services. It starts a service as soon as a program needs it. This works by having systemd allocating server sockets and listening on them. When a client connects to a server socket, systemd will not accept() the client; instead systemd will figure out which service it belongs to, then starts that service, passing it the server socket. The service then accept()s the client. This is great for saving CPU, memory and disk I/O until it's really necessary. It saves battery life and reduces boot time. EDIT: It's not (x)inetd, see my reply.
Unfortunately most people slam GNOME and systemd for being NIH or crazy without understanding the reasons. I hope this post makes some people understand the rationale behind systemd.
Heh that is like people arguing that people should not drink petrol, and then you trying to counter that by saying how good petrol is for cars.
Systemd sounds great, more distros should use it or something like it. But why would something like gnome shell want to depend on it? Systemd starts programs at startup, gnome shell is a gui. I could almost understand something like GDM needing a dependency, (but would still consider such a dependency poor engineering and against the unix philosophy)
A decision like this, and other decisions gnome has been making lately will reduce its popularity.
What the hell, why is my post downvoted? I wrote a very informative post. If someone disagrees with me then come clean and give me a rational reason, not just clicking on the downvote button!
But to answer your question: no, it's not inetd. Inetd is very inefficient in terms of CPU and memory usage and has scalability issues thanks to the fact that it spawns a new process for every client. Systemd does not do that: it waits until someone connects to the socket, then starts the service and have the service handle all clients on the socket. Systemd then waits until the service has exited. The service can use I/O events or threads or whatever efficient mechanism to handle multiple clients on the server socket, all within a single process.
This in itself does not require Linux-specific features. However the GNOME discussion is about depending on systemd which happens to be Linux-specific at the time for other reasons, not about GNOME wanting to be Linux-only (which is sensationalist headline). One of the reasons systemd is Linux-only is because it uses cgroups, which I explained here: http://news.ycombinator.com/item?id=2565801
inetd does not need to spawn a new process for every client; that is what happens if you specify "nowait", but you can specify "wait" and it will pass the listening socket to the spawned process.
I can't speak for others, but I nearly downvoted you for the first sentence which was just a gratuitous snark. I ended up not downvoting you precisely because the rest of the post was informative.
The first sentence is not a snark, it is a clarification. The question why systemd was invented instead of just using launchd had been raised in the past. Distributions avoided launchd because of licensing.
Of these, some seem like they are linux-only features that are used, not linux-only features that are required (but I don't know specifics, maybe I'm wrong):
Yeah, I'm not going to lie, lots of the things in that list are trivial.
Lennart Poettering's position seems to be that it would be better for other systems to re-implement SystemD's interface than to port it, and in any case, he can't be bothered to do a port.
- Many traditional init systems are based on a bunch of shell scripts with some metadata. Each service is started through a shell script that supports the start/stop/restart argument. While this makes the implementation very simple, it also makes it inefficient. To start a service the init system must create a new process (the shell script) which in turn invokes a bunch more processes (because almost anything you do in a shell script requires external commands) before finally invoking the service itself. This is expensive in terms of both CPU usage and disk I/O, and the latter really matters for boot time. Systemd accepts a bunch of service description files and handles the starting and stopping for you.
- Traditional init systems are about starting and stopping services. Systemd is also about keeping services running. For example if a daemon crashes, with most init systems you have to restart it manually or hook it to some external monitoring system. External monitoring systems usually rely on polling to check whether services are still alive. Systemd on the other hand just forks() the service, waitpids() on it, and gets notified by the kernel when the services crashes. No polling involved. Polling wastes CPU and reduces battery life. Polling also makes leaves a small time gap during which the service is temporarily dead but hasn't been restarted yet. This latter can be mitigated with a smaller polling interval but the smaller this interval the more CPU you use.
- Systemd supports on-demand starting of services. It starts a service as soon as a program needs it. This works by having systemd allocating server sockets and listening on them. When a client connects to a server socket, systemd will not accept() the client; instead systemd will figure out which service it belongs to, then starts that service, passing it the server socket. The service then accept()s the client. This is great for saving CPU, memory and disk I/O until it's really necessary. It saves battery life and reduces boot time. EDIT: It's not (x)inetd, see my reply.
Unfortunately most people slam GNOME and systemd for being NIH or crazy without understanding the reasons. I hope this post makes some people understand the rationale behind systemd.