Some months ago when I looked at the Devuan efforts I thought they’re directed at eradicating any traces of systemd and the Red Hat agenda from Debian. After all, the wounds were fresh and hatred still strong. However, the problem Devuan bravely tries to address is much deeper and echoes across the whole of the GNU/Linux ecosystem. Articles covering systemd merely graze the tip of the iceberg that is *software compatibility*.
GNU/Linux distributions power most of world’s servers, workstations, mainframes and supercomputers. In such mission critical environments it is absolutely mandatory that the computer is up and running most of the time. Update downtime should be minimized and process supervision for key services simplified (less resources needed for maintenance, less possibilities for bugs via human error, etc.). While systemd may seem like it addresses above problems, there are 2 main problems:
1. The simplified process supervision is only superficial. Systemd “seems” simpler, but in fact it does a lot more than a mere supervisor + init. Therefore, the surface for bugs is in reality far greater. In addition, process supervision is not a new concept and many alternative (and simpler!) suites exist.
2. Systemd breaks compatibility with former service scripts (from sysVinit) and has absolutely no intention of fixing this. The goal is unification and streamlining of the whole GNU/Linux ecosystem, not making things work.
The first point is an obvious bait for administrators who are tired of fighting with inflexible Shell scripts and overall hackery. The second point, however, should serve as a MAJOR deterrent to anyone looking for a reasonable process supervisor. There is plenty of intermittent options like OpenRC and sanely written go-to supervisors like s6, nosh or runit. Those are some low-hanging fruits, just ready to be picked…
Devuan is an important project, because it acts as a nucleator, not against systemd, but for preserving what Unix is all about – maintainability, efficiency and modular design. It tries to encourage people to care about the “Unix way” more and be aware that current mistakes will prove costly soon enough. Nowadays, we have several program packages that do what systemd offers, though in a much more elegant and non-intrusive fashion. They can be seamlessly merged with existing OS frameworks and used interchangeably.
Lands of Unix 
I can not agree with your two main points:
1. Is not as bad as you make it sound: By far the biggest chunk of systemd is not PID1 and running with severely limited privileges. Many of the services that are now part of systemd also replaces code from other projects that was running on sysv rc, too, usually with more privileges. Think udev, a logging daemon, ntp client, socket listener like inetd, network management, cron, etc.
2. Systemd is pretty compatible with sysv rc: That support is there, some distributions disable it though. Being incompatible with sysv rc is kind of the whole point after all:-)
I do agree that it would be nice to have some real alternative to systemd though! That project could definitely use some competition, just to keep those people on their toes.
Unfortunately IMHO Devuan is not that: I can only see a bunch of disgruntled admins there, that can not understand why their world has changed. There is nobody their that can actually write any real program to solve any real problem. That shows everywhere: From the LoginKit that was abandoned right after the lead author got a laptop paid for with Devuan donations, the constant broken state of core devuan infrastructure (their Debian sync service has hickups that e.g. makes samba uninstallable for month at a time) to the hilarious network manager of theirs to their udev replacement, which nicely documents that the author did not even understand the problem he claims solves. And that is ignoring that none of these are actively maintained at this time. The authors just lost interest.
So there is little surprise that devuan does not make any progress at all for month at a time (last discernable activity was 5 month ago when I checked yesterday).
Void Linux seems a way more promising project to me. They have competent developers over there, a much clearer defined scope, a vision that is not dominated by what they are *not*, and Void is not saddled with defected Debian trolls that infest the Devuan communication channels.
LikeLike
1. It is as bad as I make it sound, unfortunately :). I am aware that most of the systemd stuff has already been removed from PID1, though what’s left is still too much. PID1 should be as slim as possible and really contain just the init, nothing more. That’s the only way to make it fail-safe.
Furthermore, systemd absorbing all of the mentioned functionalities IS a problem. This should never happen! Because now udev and dbus are part of systemd, developers targeting those interfaces are forced to target systemd also. This leads to lock-in and prevents other init schemes and supervisors from getting any attention in the future. Projects as crucial as dbus or udev should never be absorbed.
2. Systemd and other supervisors are incompatible with System V scripts by definition. The problem is that the developers of systemd didn’t bother to provide any interfaces for System V scripts like runit or OpenRC have. The result was massive breakage across the whole GNU/Linux ecosystem. I’m sorry, but that’s simply unacceptable…
I do admit however that Devuan hasn’t seen much development activity in a while. They need experienced UNIX users and those are few in number. Regardless, I’m positive that Devuan will make a difference :).
I tried Void Linux just yesterday and unfortunately, it’s rough around the edges still. Too many things are broken in unexpected place to call it a stable distribution.
For now, the major obstacle to overcome is to provide non-systemd alternatives to commonly used libraries.
LikeLike
[…] most of the systemd stuff has already been removed from PID1 […]
Sorry, that makes no sense whatsoever. You either use systemd-PID1 or you use some other PID1. The systemd one was written from scratch, it never took over any other process meant to serve as PID1.
[…] PID1 should be as slim as possible […]
… but not slimmer:-)
What should and should not be in PID1 is a question of taste. Yes, keeping PID1 as simple as possible is a desireable goal, but having PID1 do nothing and just delegate to PID2 instead does not help either: Now your system is toast when PID1 or PID2 crash. So why not merge PID1 and PID2? Stability is probably not going to suffer.
Furthermore, systemd absorbing all of the mentioned functionalities IS a problem. This should never happen! Because now udev and dbus are part of systemd, […]
Let’s look at udev: Why do you think that project switching repositories is a problem? And the repository is the only thing that changed when udev became part of systemd. The code is still written by the same people!
The projects would depend on systemd *anyway*, systemd-PID1 does improve on the cgroups/namespace handling quite a lot. That is just damn convenient for developers to use and rely on!
Say what you will: Systemd is really good at listening to developers and at solving the problems they report. We will be stuck with systemd till a system comes along that is better at that. Where the code of dbus, udev and whatnot actually lives does not matter in my mind.
Systemd and other supervisors are incompatible with System V scripts by definition.
Debian uses a wild mix of native systemd services and old sysv-init scripts (or it did for month at a time, not sure how that developed). Compatibility of systemd with sysvrc init seems rather good to me.
The result was massive breakage across the whole GNU/Linux ecosystem. I’m sorry, but that’s simply unacceptable…
The wider Linux ecosystem does not seem to mind, looking at the widespread systemd adoption.
I do admit however that Devuan hasn’t seen much development activity in a while. They need experienced UNIX users and those are few in number.
Devuan needs more than experienced UNIX users! They need packagers, admins, developers and just about anything else! And they need an idea on where they want to go and how to get there. “We will support every (init system|device manager|…)” is just bullshit with the few resources they have.
Regardless, I’m positive that Devuan will make a difference🙂.
Their chances are dwindling away the longer they take to get a release out. People will either arrange themselves with systemd or move to greener pastures.
I tried Void Linux just yesterday and unfortunately, it’s rough around the edges still.
It sure is! But at least they do releases and have an idea what they actually want to do.
For now, the major obstacle to overcome is to provide non-systemd alternatives to commonly used libraries.
Devuan’s answer here is to just stick with the old, pre-systemd versions.
Quite frankly that is just postponing the inevitable: Without some alternative offer we can make to developers that provides them real benefits over using systemd (and be it just that their code is easier to port to BSDs or something), more and more code will rely on systemd. The longer systemd is the goto set of functionality that developers use, the more work it is to do Devuan or anything similar.
So far there is no effort whatsoever to woo developers away from the systemd APIs anywhere in the Linux ecosystem. In fact in Devuan there is a culture of name-calling developers that makes sure few will be willing to do anything to help devuan packagers in the long run. They are poisoning their own well there.
LikeLike
“Sorry, that makes no sense whatsoever. You either use systemd-PID1 or you use
some other PID1. The systemd one was written from scratch, it never took over any other process meant to serve as PID1.”
I never said it did. I merely said that the functionalities of systemd that used to sit in PID1 are no longer there.
“(…) Yes, keeping PID1 as simple as possible is a desirable goal, but having PID1 do nothing and just delegate to PID2 instead does not help either: Now your system is toast when PID1 or PID2 crash. So why not merge PID1 and PID2? Stability is probably not going to suffer.”
Stability will suffer, because PID1 special and the point is not to dump everything into a single PID, but to dispense across multiple processes/daemons that talk to each other. If one goes down, the others can signal that, but not die themselves. I recommend reading on runit or s6 in that respect.
“Where the code of dbus, udev and whatnot actually lives does not matter in my mind.”
In my mind either. However, the fact that multiple distributions require
systemd libraries for udev, dbus, etc. does. That’s what I was talking about
earlier.
“Debian uses a wild mix of native systemd services and old sysv-init scripts (or it did for month at a time, not sure how that developed). Compatibility of systemd with sysvrc init seems rather good to me.”
Letting init scripts run alongside systemd is not what I meant. I meant there being an integration of init scripts into the supervisor tree so that it’s easier to control the related daemons.
“The wider Linux ecosystem does not seem to mind, looking at the widespread systemd adoption.”
The widespread systemd adoption had a lot to do with politics also.
Nevertheless, at that time, systemd was the best one could use instead of
either Upstart, System V init scripts or even OpenRC.
“Devuan needs more than experienced UNIX users! They need packagers, admins, developers and just about anything else! And they need an idea on where they
want to go and how to get there. “We will support every (init system|device
manager|…)” is just bullshit with the few resources they have.
Regardless, I’m positive that Devuan will make a difference🙂.
Their chances are dwindling away the longer they take to get a release out.
People will either arrange themselves with systemd or move to greener
pastures.”
Yes, Devuan needs help. Re-stating that multiple times doesn’t provide that help, though.
“But at least they do releases and have an idea what they actually want to do.”
Devuan people also have an idea what to do – study GNU/Linux to provide an
alternative to System V init scripts and systemd at some point. It will obviously take time, though.
“Quite frankly that is just postponing the inevitable: Without some alternative offer we can make to developers that provides them real benefits over using systemd (and be it just that their code is easier to port to BSDs or something), more and more code will rely on systemd.(…)”
What do you suggest then? Stick our heads in the sand and wait pathetically until GNU/Linux becomes a systemd/Linux monoculture?
LikeLike
Sorry, my reply ended up in a new top level post:-(
LikeLike
I never said it did. I merely said that the functionalities of systemd that used to sit in PID1 are no longer there.
I do not understand what you mean here, sorry.
Stability will suffer, because PID1 special and the point is not to dump everything into a single PID, but to dispense across multiple processes/daemons that talk to each other. If one goes down, the others can signal that, but not die themselves.
PID1 is not *that* special:-)
Communication also introduces a lot of code (set up communication channel, marshal/demarshal/sanity check input/…). The systemd developers claim that it adds way more complexity to split up functionality for the benefits it offers.
I never tried to program any init system with the capabilities of systemd, so I have to trust them there. They did try, which makes them way more trustworthy than those armchair developers on the internet criticising them.
I recommend reading on runit or s6 in that respect.
I did and find the systemd concept convincing: PID1 watches the services and the hardware watchdog watches PID1. The alternatives have a gap between PID 1 and the service manager in another process. Nobody watches the watchmen there:-)
The widespread systemd adoption had a lot to do with politics also.
Of course there was politics involved: There are always politics when people interact with each other!
I did follow the Debian decision process and found that pretty transparent. And systemd definitely was not the side playing most political games.
Nevertheless, at that time, systemd was the best one could use instead of
either Upstart, System V init scripts or even OpenRC.
Has that changed? I don’t see anything out there that managed to catch up with systemd in the meantime.
Devuan people also have an idea what to do – study GNU/Linux to provide an alternative to System V init scripts and systemd at some point. It will obviously take time, though.
So devuan will leave sysv init behind? That was never clearly communicated AFAICT. There was some talk about OpenRC, some about alternative inits, some about sticking with sysv init scripts.
That is exactly what I meant when I said they have no idea what they want to do. Whenever someone makes any claim the two lead guys will just agree. “init system freedom” basically commits devuan to support any stupid init system out there (of course minus systemd, the freedom does not go that far:-).
Commit to everything and you commit to nothing in the end.
What do you suggest then? Stick our heads in the sand and wait pathetically until GNU/Linux becomes a systemd/Linux monoculture?
Do something! Waiting for some lazy idiots that an not even do a release in almost two years is not helping anyone.
An attitude of “developers are evil because they use systemd” is not going to help find support. You need developers and their support, driving them away is not helping anyone.
Find allies in other projects and pool resources. Everybody coming up with their own rather similar toys is not helping anyone.
Finally: Study systemd. Find out why it is adopted, which problems it solves for developers. Without that you can neither remove systemd from a distribution (without hurting your users by introducing new security gotchas) nor come up with compelling alternatives.
LikeLike
Thank you kindly for contributing to the discussion. I think your points are a bit of an eye-opener and I will definitely consider them in my pursuits ;).
I do not claim I fully understand how the init process on UNIX systems works, though after reading a lot on systemd and alternatives I see two points of potential agreement:
1. systemd is the “best” we have for now in terms of process supervision and inter-daemon communication.
2. Bearing that in mind, there should be space for independent inits and supervisors that may have advantages in some areas over systemd. Compatibility with BSDs being at least one, as you mentioned.
Runit and s6 are interesting descendants of daemontools, which might be of interest to people seeking non-systemd solutions. Neither of them is perfect and obviously requires polishing.
However, per design, systemd simply cannot be omnipotent either. Many of the recent bugs show that. In addition, it’s very hard to demonstrate the advantages it offers on paper. That would require a lot of real life cases with reliable quantification, etc.
Obviously, the perfect scenario would be comparing each of the supervisors side-by-side, though this may take some time…
LikeLike
1. systemd is the “best” we have for now in terms of process supervision and inter-daemon communication.
No. Systemd is the best in terms of process supervision on *Linux*. It very specifically limits itself to Linux – which is exactly why it does shine on that platform. Systemd leverages Linux kernel functionality to do its work.
Systemd does nothing for inter-daemon communication. It enforces dbus to be available, so other daemons can use that if they want.
However, per design, systemd simply cannot be omnipotent either. Many of the recent bugs show that.
Of course it is not perfect! It is software and thus full of bugs. It is written in C, too, that surely does not help with the bug count!
In addition, it’s very hard to demonstrate the advantages it offers on paper. That would require a lot of real life cases with reliable quantification, etc.
None of the other init systems wants to compete! They would need to use Linux specific functionality then, which most do not even consider since that would make them non-portable.
I frankly do not see why portability is important for an init system…
Note that systemd is not doing anything magic. It just implements a couple of idea that are in use for decades on other Unix systems. It also uses Linux kernel features internally and makes those easily available to its users.
Obviously, the perfect scenario would be comparing each of the supervisors side-by-side, though this may take some time…
You need cgroups to reliably manage processes on Linux. Without that a process can escape the supervisors control if it wants to by double forking. No portable service manager can keep its promise on a Linux system.
I think it is a bit chilling that one of the selling points of systemd is that it can reliably kill a service and all the processes that were spawned by it (even those that double forked). That is a problem that should have been solved decades ago!
LikeLike
1. Apart from dbus, systemd makes use of socket activation, which is not offered by other supervisors (at least not in the same form). That’s what I meant specifically. I’m sorry I did not make myself clear :). dbus, on the other hand, can be utilized by other supervisors and is platform agnostic (the versions that preceded systemd at least).
2. The Linux-specific vs portable is a bit of a conundrum, yes. I personally don’t know how useful a Linux supervisor would be on other platforms. The only thing I know is that BSDs still rely on init scripts and there are some attempts to move to a proper supervisor suite. If systemd cannot do this, other supervisors probably will :).
3. I forgot about the cgroups, my bad. That’s indeed a Linux-specific feature and indeed, if a supervisor is supposed to excel on a platform, it has to make use of platform-specific apparati.
I think systemd has many such “chilling” features. One other being complete session termination (with all processes killed) after user logout. This, fortunately, can be disabled :).
LikeLike
1) Systemd did not bring anything new to the table. All it did is take ideas that existed in other Unix platforms for literally decades and combine those with Linux kernel features – many of which are available for years.
Inetd did socket activation for decades, for any init system. Same for time based job starting, which used to be handled by cron. Systemd merged these, and now we have one system where any service can be started in exactly the same environment and with exactly the same syntax and features, independent of how that service is going to be triggered. Way nicer and way more powerful than ever before.
2) A init system is OS specific. So why bother making that portable?
Not counting the obvious “run some script at bootup”-approach (see Autoexec.bat or bsd style inits) the only exception is sysv-init here. But that is due to OSes evolving out of sysV Unix. And even there no two implementations of sysv-init were ever fully compatible with each other. It has always been a pain to write an init script for more than one distribution (not to mention for a different flavor of Unix).
So far nobody has expressed any desire to use systemd on any other platform but Linux. In fact no non-Linux OS has expressed interest in *any* of systemd, upstart, openrc, s6 or runit as far as I know, with the possible exception of Debian flavors using non-Linux kernels. Why bother keeping your code portable if nobody wants to port the stuff anyway?
Finally portability is something that can be added later if desired. Linus thought Linux could ever run on anything but Intel 386 CPUs when he started out with his project! And now look what at all the hardware running Linux. Porting a small user-space application from Linux to another Unix-oid OS is childs play compared to that!
3) Systemd does change things, that is for sure. But if you stop changing you are dead! And finally somebody is actually going forward and does things.
E.g. having /usr on a partition separate from /: That did not work reliably on any distribution for years. The distributions had fucked that up, they had bug reports about it for years and they had no idea how to address the issue in any form. Then systemd went ahead and declared that unsupported, took the flames (so the distributions did not have to) and now we are rid of that problem basically everywhere.
Or look at the example of KillUserProcesses you mentioned: I personally consider “there are no processes that belong to (non-system) users that are not logged in” to be the sane default and actually enforce that on all my systems. That change does not break tmux, screen, etc. provided either the application or the user tells the system about the need to run in a separate login session. That way the book keeping in the OS is done properly, which in turn has positive side effects on system security and system administration.
LikeLike
1) I think you’re spot on with this :). However, I believe the reason people
consider systemd “new” is the set of circumstances under which it was
introduced. The features are not new as you said, but it might be their
combination that also played a part.
2) Yes, I completely agree. The moment one starts to build something a bit more complex via Shell scripts, things go aloof. I see that no other
supervisor constraints this, because even runit and s6 use Shell-like
languages to start daemons. In the case of s6 it’s execline, not Shell, but
the principle is still there. I think the way daemon service/unit/run files
are generated needs to be severely streamlined. OpenRC run scripts seem to be a good start in that matter :).
It’s true that none of the non-Linux platforms expressed interest in Linux
supervisors we discussed thus far. However, it’s also true that per for
instance recent Release Notes of FreeBSD, there is interest in supervisors. It just might be that if the BSD world sees good use cases for one of the non-systemd supervisors, they might start considering it more openly. Hope that’s not merely wishful thinking! 😉
The problem is not only portability of the init itself, but also of the components that become intrinsically reliant on it. This lies more on the side
of developers, though :(.
3) I agree that systemd did a lot of very radical changes, which brought about controversy and straight up hate. Some of them were needed, I give you that.
The KillUserProcesses was big. Notice you had to introduce changes yourself in order to preserve tmux/screen sessions. Should the admins be always on their toes whenever systemd introduces something equally big? I think the “sane defaults” should be based on what people expect. After all, there is the years of
UNIX history and habits that shouldn’t be just thrown out of the window.
LikeLike
It is rare to have such a civilized discussion on the topic of systemd:-) Usually it goes down to name calling pretty fast. My experience with devuan people is pretty particularly bad here. I do count you as a devuan person, consisering your activity in their forums.
We even agree on 1. That is a first:-)
About 2, I do not expect any OS will express interest in any of the portable init Systems. They want something that plays to their OSes strength, just like linux has with systemd now.
Portability of init files is a problem, you are right there. But the situation did already improve thanks to systemd at that front: At least you can now share them between Linux distributions now! Quite a few upstream projects do ship systemd unit files by now. That is new: So far distributions had to write the init scripts themselves.
I do not consider KillUserProcesses to be big. Any usr can override it! No admin activity is needed at all (user activity is enough). I would argue people expect “no user, no process”. Some admins may not expect that.
I think admins are there to adapt the changing environment to their systems. It is their job to deal with change!
LikeLiked by 1 person
“It is rare to have such a civilized discussion on the topic of systemd:-) Usually it goes down to name calling pretty fast. My experience with devuan people is pretty particularly bad here.(…)”
I admit I was somewhat tempted, but your arguments are solid and they push me to think deeper about the issues at hand. I believe it’s a good thing :).
“About 2, I do not expect any OS will express interest in any of the portable init Systems. They want something that plays to their OSes strength, just like linux has with systemd now.”
Hmm..yes, this might be the case eventually.
“At least you can now share them between Linux distributions now! Quite a few upstream projects do ship systemd unit files by now. That is new: So far distributions had to write the init scripts themselves.”
Yes, that’s definitely a good move in the right direction! In addition, unit files are much easier to write, correct?
However, what do you think if the alternative init did provide service files for the most common services? That way the developers would not be expected to do that themselves and compatibility would be taken off their shoulders. Would you consider this feasible?
“(…)No admin activity is needed at all (user activity is enough). I would argue people expect “no user, no process”. Some admins may not expect that.”
And I have this grand view of a UNIX mainframe that handles jobs from various users all the time. They come and go to drop jobs and later retrieve their results. Though you’re of course right, the default can easily be changed. There was a bit more fuss over this in the GNU/Linux communities than needed, I think.
“I think admins are there to adapt the changing environment to their systems. It is their job to deal with change!”
Haha, exactly!
LikeLike
Systemd units are easier to write than init scripts. They do have their own complexity, mostly since they tend to be more fine grained than init scripts. E.g. you have several units working together to bring up the various bits and pieces of NFS. Getting the dependencies between them right is nontrivial. On the other hand writing an init script for NFS is nontrivial either.
Init files shipped with the init system itself is OK I think
It is not optimal: You will always have scripts for things not installed and no scripts for stuff that is. But I do not see what else to do, considering that Debian will not ship init scripts for S6, openRC and all the rest in the upstream packages and devuan adding those will probably not work out either.
Sure, mainframes process user processes all the time. So do systemd systems, they just require the necessary paperwork (somebidybis logged in) to be in place:-).
Overall I think you are barking up the wrong tree: The init system is boring, with systemd and without. Nobody cares for that, nowhere.
Systemd-PID1 does cgroup management in a really convenient and complete (even PID1 is in its own namespace nowadays). All the stuff that depends on systemd being PID1 has that dependency due to the namespace/cgroup management it does. That is what gets the developers excited, as it allows them to make things like a secure version of consolekit (logind).
Coming up with a compelling cgroup manager would do a lot more to reduce dependency of upstream code on systemd than playing with init systems. There are lots of alternative ways to start up a system, some better than others and some worse. But there is only systemd and cgmanager to manage cgroups. One of them is horrible:-)
LikeLike
cgroups are something entirely new to me. As far as I understood it’s a Linux kernel feature, rather than an element of systemd. Can they then not be implemented in a non-systemd way for other supervisors?
I think you’re right in the sense that the init process is boring. It’s been done so many times after all…
What I’m more interested in is a flexible supervisor that can be implemented on top of an init (or together with its own init) and be more modular than systemd.
LikeLike
Cgroups and namespaces are both Linux kernel features. They can be used to limit what a process can do and see and to group processes in a way the process can not escape from.
Both can be used with any init system and predate systemd. Any init system can use them and in fact openRC actually optionally enables them on Linux as far as I know. All you need to do is to write into some files in /sys to manage the cgroups configuration. Again: Systemd did not introduce any new stuff or ideas ever.
What systemd does is to use these kernel features consistently in PID1 and to apply them to everything started via systemd — even to PID1. So not even PID1 can starve other processes of resources anymore if it ever went rogue (not that it does do that regularly, it is a precaution, not a necessity to do this:-). Systemd further went ahead and came up with a convenient interface to interact with cgroups and namespaces via DBus. That interface is the reason why logind and basically everything else depends on systemd being PID1 has that dependency.
Now what makes cgroups/namespaces a controversial issue at this time is that the *kernel developers* (not the systemd developers, just to drive home that point) claim that managing cgroups is racy as it is done today. To fix these races they want to limit the management part to a single user-space process, with every other process just being able to read the current configuration from /sys. Only one writer, but many readers — All changes need to be done by the single management process, but everybody can see (part of) the configuration if they want to.
In the systemd setup that cgroup manager process is of course systemd-PID1. This is obviously problematic for distributions that do not want to use systemd: Developers will target the most widely used API. Of course most applications have no need to manage cgroups ever, but things like session managers, etc. do.
Unfortunately I am currently not even aware of any serious alternative to systemd-PID1 in that role. Cgmanager from google comes closest, but that is supposedly pretty ugly to use and not that actively maintained anymore.
LikeLiked by 1 person
Thank you very much for this extremely insightful comment! 🙂 I now have a lot to read and think about.
If you ever see something terribly wrong, missing or worth mentioning in my posts, please do comment also. I would really appreciate your feedback!
LikeLike
You are more than welcome.
I do want to see competition to systemd after all. But I want to see *qualified* competition and not some clueless newbies trying their hands at their first C programs.
LikeLike
Well, unfortunately I might be a “clueless newbie” then. I don’t know enough about C to properly implement missing features in any of the existing supervisors, but I do know how to integrate said supervisors into a distribution. For C related stuff I would probably have to rely on the original authors of said supervisors and…perhaps you if you want to chip in ;-).
LikeLike
No slight was intended, at least not against you! I’ll keep that for when you ask people to install your first ever C program with the SUID bit set:-)
I did follow Devuan closely ever since its inception. Unfortunately in some places discussions were so utterly stupid and uninformed that I could not keep my mouth shut when I should have. By now I am pretty well blocked on all their communication channels. That does save me a lot of time though that I would otherwise spent on fighting stupidity on the internet:-)
In fact I would not have replied to your blog post at all had I realized you were active in the Devuan forum. I only made that connection after my first reply:-/
LikeLike
FYI: Systemd can detect locked up processes like dhclient, provided they are adapted to systemd. The services that link to libsystemd0 probably are ready for this kind of monitoring:
What systemd does is it sends regular requests to the process and if there is no reply in a certain time, then the process is considered frozen and gets restarted (or whatever the user configured).
I am not aware of any way to implement anything like that with sysv rc, but other inits probably could do the same kind of monitoring.
LikeLiked by 1 person
That’s actually a very good point! I went through the documentation for s6 and runit and couldn’t find specifics regarding blocked/frozen processes. There is plenty on restarting dead processes, but not much about polling mechanics. I guess some code could be implemented in either ./run or ./finish, but even then it’s still not init-wide.
LikeLike
The problem is that the service process needs to be modified to support this polling mechanism.
Systemd is pushing for that to happen. You could in theory piggy-back on that effort, but you would need libsystemd0 (actually I am not sure which lib the code is in, but that is the most likely place) to be available to services. So that is probably not an option for devuan. It is the same code that also is used to tell systemd that a service is fully up bu the way — according to devuan gospel a totally broken and useless mechanism. A sure sign that nobody there ever wrote a unix daemon;-)
Note that this will catch most frozen processes, but not all. At least in theory a process can stop responding to its clients and still kick the watchdog.
LikeLiked by 1 person