Remix clone Hacker News

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.

▲

o11c a day ago | parent [-]

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).

▲

netbsdusers a day ago | parent [-]

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

	▲	o11c a day ago \| parent [-]
		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".