Does anybody understand what audience systemd was meant to address, and what problems it solves for those people?
I'm a recovering sysadmin, so these days I only maintain a few personal boxes. Perhaps because of that, I'm having a hard time appreciating systemd. Having reluctantly dealt for the last couple of years with upstart, redoing init creates an awful lot of work and confusion, and I personally haven't experienced much benefit.
Perhaps systemd is better, but everything I've heard about it makes me fear the second-system effect [1] is in full force.
I think pretty much everyone agrees that SysV init scripts are not the path forward. For example, Debian switched to systemd, and I'm pretty sure that the options were Upstart or systemd -- nobody really wanted to stay with init scripts.
Main problems as I understand them:
- Duplication. init scripts don't even restart daemons if they crash; or if they do you have to duplicate the restart logic in every init script. IMO distros generally do a poor job with their init scripts. They are heavily duplicated and thu inconsistent.
- Dynamic configuration. The runlevel thing is not expressive enough for dynamic desktop and mobile systems where devices come and go. Service dependency metadata is more expressive and natural. This was a main design goal of Upstart.
- Speed. Computers and devices do more now. systemd socket activation is actually a fantastic design IMO (even though I don't like other things about systemd). This lets you parallelize service startup to a much greater extent. Apple's launchd and Solaris SMF did similar things at around the same time.
In the 2000's, all Unix vendors independently decided that init needs to be overhauled, so the problems being solved are real.
Upstart is much better than SysV initscripts, but introduces some other problems. Systemd has a better design.
The main problem with SysV is that every script needs to do everything: It is, after all, just a hook for the OS to call on startup (as well as a useful, but not necessarily mandatory, way for users to interact with the service).
So every script needs startup config (Debian: /etc/default), PID file management (start-stop-daemon), daemonizing (ditto), startup log management (ie., tracking what happens until the program can start logging on its own), limits (ulimit is per session, so every script has to do this to avoid inheriting root's limits).
Plus, you don't get: Dependency management; automatic respawning on failure; CPU and memory resource alotment; ability to list and inspect declared services vs. everything else that's running; handling of orphaned forked child children; etc.
Systemd has been accused of being monolithic, but it seems highly modular to me, and more so than Upstart.
Actually, you do get (limited) dependency management through insserv, which was standardized by LSB and its set of initscript headers. Most dpkg and RPM-based distros used them.
Automatic respawning is a job for a process supervisor, not a process manager or initd. It's a separate duty altogether. So is resource limiting, which is probably better serviced through separate tools that wrap around syscalls.
I disagree about respawning, but it probably comes from a difference in opinion about what the scope of a "process manager or initd" should be.
To me, starting a service expresses the intent: This service should be running. What the underlying process is is of no concern; a service is an abstraction of an OS process, not the process itself. The service's "target state" drives what to do with the process. I want to the service to be running, irrespective of what the underlying process is, which means that a process dying just implies it must be started again.
This functionality belongs in the init system first because it's closest to the source, secondly because it's such a common requirement that it belongs there. Sure, one can argue the technical design; respawning can be a separate subsystem forked from the init, for example. But it should be an integral feature of the init system, not something I have to get from a third party. To paraphrase Jobs, it's a feature, not a product.
This conflation of "target state" and "actual state" is something that so many apps get wrong. For example, consider an FTP client or an IM client: If I connect to a remote server and the connection fails, the app should not require me to manually connect again. I, as a user, has expressed the intent that I wanted to be connected. That's my target state. Whether that state is reachable is the concern of the underlying connection manager. The underlying connection is just an implementation detail. Imagine if the lights and all your electrical appliances didn't automatically come back on after the power went out.
In other words, high-level abstractions should always attempt to be seamless.
Most people don't make a distinction, but I feel that is important to note these.
Strictly speaking, init(8)'s sole responsibility is to reap children, set the session and process group IDs, and optionally exec the actual process manager. In practice, this is bare bones, but strictly that's all that's required.
A process manager then usually provides an abstraction around processes (usually PIDs) called a "service", implementing a minimum of start/stop/restart/status. Status is most primitively done using a PID file. Other extensions like conditional restart can be added.
A process supervisor then ensures that processes are automatically restarted, that inotify(7) triggers are added, that system load is monitored, applying resource limits, emailing an admin upon state change, etc.
Such a trichotomy is rarely expressed, but a hypothetical example that would likely work would be sinit + svc + perp.
Autorestart should be expressly enabled by the sysadmin's choice and disabled by default, due to the possibility of buggy daemons improperly backing up their state, as well as edge cases that may be present in the admin's particular environment.
The problem for me with such a strict view is the special status of pid 1. You can not have a reliable process manager without either putting it in pid 1, or having restart logic in pid 1, since a process manager outside of pid 1 can be killed without taking down the system, and thus can die unnoticed unless the init includes restart logic.
You also have a second problem: How do you log failures reliably? Your process manager can not do that, or be responsible for spawning something to do that if it itself is pid 1 - it could be brutally murdered the instant it spawns the next process, or at any random time, unable to pass on any temporarily collected data while waiting on a suitable place to store said data.
There's a lot of thinking behind the systemd architecture that actually make substantial advances over what we used to have, and that solves issues that are not at all addressed by most other init systems. Your suggested sinit + svc + perp for example would suffer from both the dead process manager problem and the log problem. They are real - I've run into that more than once.
While I'm not in love with, or convinced by, how much stuff they've added to it, also keep in mind that systemd is not just a pid 1 replacement. The systemd project includes multiple components, only the core of which runs as pid 1.
Maybe it'd be nice and useful to see that decomposed with clear API's connecting them, but for now they're developed and shipped together, and I understand why they don't particularly want to have to deal with that, but seeing systemd-the-project as just an init replacement is not really the case (though pid 1 in a systemd install still contains more than you suggests it should).
You can trap virtually all signals beyond SIGKILL.
Keep in mind I'm not advocating a strict separation, it does make sense to intertwine to an extent for practical purposes. I'm mostly trying to say that they're separate stages, and should not be completely equated for each other, lest some undesirable design properties emerge.
Despite your suggestion that it is not for an initd to do process respawning, all init's I've ever used (since '93 or so) have the logic built in anyway. It's just that making use of it restricts you to /etc/inittab for your configuration.
Introduce tons of security exceptions? Do an end run around linking restrictions of gpl libs via IPC calls instead? Destroy what hobbyists have built and gain control? Cause discord and strife in our communities?
I'm the person who goes by The Initfinder General. Feel free to ask and be elucidated about uselessd and my general outlook on systemd/the state of Linux/Unix, if you so wish.
Was glad to see this; thanks! Systemd has made my Arch system overall much easier to administer, but the monolithism makes me nervous. It'll be interesting to see how things look once they've been broken up a bit.
I'm curious: are you trying to rescue a kernel of value from the systemd project where it improves on existing systems, or is this mostly a proof that it didn't need to be built so monolithically in the first place?
It's a little bit of both, coupled with the fact that I simply wanted a challenge, being a bored sap and all. This is probably the first remotely noteworthy thing I've done.
The end goal is to drive systemd into a direction that focuses succinctly on process management, having a portable base that can be transposed to other operating systems. Still quite some way to go, but hopefully it'll be done some day. But yeah, supplying systemd's core features for people who would like to have a conservatively developed and focused service manager that won't suddenly swallow the windowing system one day, is a key goal. Captures the gist of it.
Eventually I might transfer control to someone else and focus on my own interests. The eudev project lead has expressed some interest in us.
When the original programmers felt their program was mostly done and stepped away, others came in, a new breed, and diverted the trajectory of the projects.
Well engineered software projects eventually are completed. And then people shouting that anything not actively "maintained" is "depreciated" come in and attempt and succede in using software for political gain or control.
Most of the "Debian Developers" are not the same sort of people that started debian. They are often not programmers.
We who actually write software are looked down by them. The people who use software are looked down upon by them. They are now a middle man, using their position for control, rather than for helping. Like a bad government.
The Debian social contract even says the distro is for the sake of the users.
I'm one of those people who find most systemd opposition rather unconvincing, but good luck to you anyway.
I was surprised by the fact that you'd actually removed the mount and device unit logic from your fork. In my view, the init/service manager (with its dependency resolver) is the correct place for something like that because services depend on devices and mounted filesystems being available. How should those things be handled, if not there? Udev-triggered units and systemd generators seem to me a very clean way of handling the problem while maintaining backwards compatibility with /etc/fstab and other configuration sources.
systemd's purpose is to deprecate fstab(5) entirely through GPT partition discovery.
These things can already be accomplished through a device node manager, such as (e)udev. We just no longer handle maintaining it, because it doesn't belong here.
I don't see deprecating fstab as a bad thing, if it's possible. Less static configuration is pretty much universally good. It's also pretty much zero burden on systemd to maintain fstab compatibility indefinitely.
However, I was asking for specifics. Accomplished how, exactly?
udev can generate an event and run a shellscript or something when devices become available, but... then what? What processes the event and ensures correct behaviour for dependent services?
Let's say that upstream systemd adds further features to the core init code (eg. additional unit file syntax). Are you going to backport this code to uselessd? Or rewrite it? Or ignore new features?
Right now we're at a stage where we're not all that focused on adding completely new features, but cleaning up what exists. In general, whether or not we include a new unit option depends on how we gauge its usefulness.
This is the kind of thing I want to see when people criticize systemd: an example of what they'd do differently (other than just "there's nothing wrong with having a million lines of copypasted bash in init.d, I'll stick to unsupervised several-minute boot times tyvm"). Bravo.
It's not necessary for something to be a single binary for someone to call it (and for it to be) "monolithic".
Each utility in GNU coreutils is useful indipendently from the others. If each systemd binary is (almost) useless outside of systemd, systemd may not be a monolithic application, but it may still be a monolithic system.
It's more a matter of coupling than a raw number of binaries included.
Yo bro, a bunch of subroutines put together to form a program aint monolithic bro, you can use them seperate bro. They just happen to be used together bro!
I must be especially dense today, but when I follow the link, I see only the title "usysd", links for Edit, Recent Changes, Preferences, and Discussion, but no other content. What am I doing wrong?
We've been under attack since shortly after we got covered on Phoronix. Started off with IRC bot spam, but looks like they got the wiki, as well. We're working on undoing it. Good thing ikiwiki is versioned.
It's a shame that software forks can summon such derision, but it looks like init systems are serious business. Oh well.
The same person is also spamming the #systemd channel on freenode. Pathetic display altogether.
Thanks. I realize startup systems are a controversial, but they hardly warrant this. My only interest in them is "which one is best to teach students in a beginning Linux admin course"?
I find the systemd debate vaguely interesting but not especially relevant to me, however I must applaud the effort of these guys. They were dissatisfied with ongoing trends and decided to work on an alternative. Kudos, good sirs, kudos.
Legendary. I'd love to see this installable as a .deb / apt repo / ansible and puppet modules one day. Let's make fixing this mess as easy as possible for the masses.
Coup. The tech committee is made up of current or former redhat and canonical employees. This is a social problem and needs a social solution. They took our distribution from us. They came from the same place as the various womens groups who invaded a few years ago and kicked out male programmers who opposed them.
I'm a recovering sysadmin, so these days I only maintain a few personal boxes. Perhaps because of that, I'm having a hard time appreciating systemd. Having reluctantly dealt for the last couple of years with upstart, redoing init creates an awful lot of work and confusion, and I personally haven't experienced much benefit.
Perhaps systemd is better, but everything I've heard about it makes me fear the second-system effect [1] is in full force.
[1] http://www.catb.org/jargon/html/S/second-system-effect.html