←back to thread

InitWare, a portable systemd fork running on BSDs and Linux

(github.com)
167 points sunshine-o | 2 comments | 03 Apr 25 12:11 UTC | HN request time: 0.707s | source
Show context
travisgriggs ◴[03 Apr 25 14:02 UTC] No.43569845[source]▶
This actually is kind of cool imo. There are things I like about systemd, and things I don’t. And this seems to fit much more closely around the things liked. Wish I had the time to play more with it on Linux. Would love to see Debian switch to something like this. Always felt like Debian was stuck between “all in” or “go without”. This would have been a nice middle ground choice to have had back in those days.
replies(3): >>43570430 #>>43571106 #>>43572018 #
ape4 ◴[03 Apr 25 14:41 UTC] No.43570430[source]▶
Yeah, I thought systemd relied very heavily on Linux-native things like cgroups.
replies(3): >>43570843 #>>43572066 #>>43576550 #
netbsdusers ◴[03 Apr 25 16:28 UTC] No.43572066[source]▶
Systemd uses groups for two things: for tracking processes other than direct children of the service manager, and for imposing resource limitations. Both can be done with other mechanisms, like kqueue's EVFILT_PROC and login classes respectively. But my experience in any case was that hacking up systemd to build and run under BSD it didn't need cgroups at all for basic running. Supervision of `Type=simple` and `oneshot` services worked fine. It wasn't particularly surprising to see this as cgroups really aren't ideal as a tracking mechanism - under cgroups v1, you only had a "cgroup empty" notification available as far as tracking the lifetime of processes within a cgroup, and even that was unreliable and could be left undelivered! So systemd used them to augment a more traditional process supervisor. That's why Pottering insisted on having it be PID 1, and got subreapers added to Linux for the per user systemd instances so that they could get the more traditional SIGCHLD based notification of process exits.
replies(1): >>43575481 #
o11c ◴[03 Apr 25 21:12 UTC] No.43575481[source]▶
Okay, but ... if you only get something that seems to work, but isn't actually reliable, what's the point?

You seem to be wrong about cgroup v1; freezing works and is sufficient to reliably kill all children. Half-killed services was one of those really annoying problems back in the dark ages of sysvinit (not the most common problem, but perhaps the hardest to detect or deal with when it did come up).

replies(1): >>43576303 #
1. netbsdusers ◴[03 Apr 25 22:36 UTC] No.43576303[source]▶
I'm saying that it did work perfectly fine and reliably for the common case of types oneshot and simple services. To expect it to work for type Forking services would be absurd since no mechanism would exist to even try to keep track of them. It's just a point to illustrate that systemd is not as intimately and irretrievably integrated with Linux features as some imagine.

Freezers were never used by systemd as part of its process tracking mechanism. And cgroup emptiness notification was unreliable under cgroups v1. So that's not wrong. It used some horrible mechanism where a binary is launched (!) when the cgroup becomes empty. And that can fail to happen under situations of low memory availability.

Related read is Jonathan de Boyne Pollard on cgroups:https://jdebp.uk/FGA/linux-control-groups-are-not-jobs.html

replies(1): >>43577200 #
2. o11c ◴[04 Apr 25 00:48 UTC] No.43577200[source]▶
My point is that a lot of apparently "simple" services do in fact call fork internally. Just a few things I've seen:

* fork to periodically make a snapshot of server state, to avoid slowing down the main server

* spawn an external gzip to compress a log file

* spawn a handler for some file format

* spawn a daemon to actually handle some resource, which might be used by other processes too (this really should be a separate managed service, but in the anti-systemd world this is often not the case)

If everything is working fine, you'll only waste a bit of server RAM for a few seconds if you fail to kill the children alongside the parent. But the circumstances in which you want to restart the service are often not "everything is working fine".