Uselessd: A Stripped Down Version of Systemd
uselessd.darknedgy.net
uselessd.darknedgy.net
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
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.
More here: http://0pointer.de/blog/projects/why.html
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.
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.
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.
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.
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).
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.
Poettering makes frequent references to it whenever he talks about his projects (Pulseaudio, Avahi, Systemd).
(Just like the *-women plants)
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.
EDIT: Proof it's me: https://forums.darknedgy.net/viewtopic.php?pid=78186#p78186
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?
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.
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 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.
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.
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?
Because systemd always sounded like it solved some init problems but then sprawled over so many other systems that it seems invasive and monolithic.
KISS.
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.
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.
EDIT: We're back.
In the meantime, our BitBucket repo: https://bitbucket.org/bcsd/uselessd
Provide alternatives. Do not complain that hairball of bash script works (if nobody modifies it).
Your opinion is DEPRECIATED
You need to be banned from the mailing lists, you're using TRIGGERING WORDS.
Harraser.
1. http://www.phoronix.com/scan.php?page=news_item&px=MTc5MzA
> ...Fuck.
I loled