LWN: Comments on "Init system support in Debian"

NO TO SYSVINIT - or initscripts, rather!

nopsled — Wed, 13 Mar 2019 16:30:59 +0000

Have you seen https://www.freebsd.org/cgi/man.cgi?query=procctl&sek...

It would be nice if Linux had the PROC_REAP_KILL stuff. I think one could improve the FreeBSD interface a tad bit when incorporating it, but the concept looks sound.

systemd ofcourse has one supervisor per context (system or user), but this will be especially useful for supervisors that have one monitor per service (s6, runit style), and that these can be nested supervisors (so an option to not cross subreaper boundaries where each supervisor is a subreaper, or a way to kill inherited children only, and a way to kill direct children only, and OR the flags to do both). You could get creative, but if done right, this could solve a lot of woes with process management.

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Tue, 13 Nov 2018 00:21:28 +0000

Correct. You can still use a thin tree only for processing tracking.

NO TO SYSVINIT - or initscripts, rather!

nix — Tue, 13 Nov 2018 00:18:21 +0000

Oh, so the only restriction with v2 is that *controllers* can only appear on one unified tree? You can have lots of other trees for the sole purpose of defining relationships between processes?

That's... useful. As in, I think I'll have a use for it in my own work in the next week. :) I wish I'd realised v2 worked this way years ago!

Init system support in Debian

dkg — Mon, 12 Nov 2018 20:13:18 +0000

As a debian package maintainer, i'll speak up and say that i am one of the people guilty of starting to drop sysvinit-style initscripts from my packages. This makes me a bit sad because i really would like to support non-Linux kernels in Debian better, and systemd is Linux-only, of course.

I am not doing this out of antipathy toward sysvinit or its users; i'm doing it because i can't responsibly maintain them. even if i ran systems that had sysvinit as pid 1 that i could use for testing, systemd offers so many better ways to ship tuned, constrained unit files that for moderately complex services (ones that need customized permissions or OS constraints, for example, or that use socket activation), i can't reliably assert that:

the necessary dependencies will be handled correctly
any supporting data (e.g., /run/foo/cache or /var/lib/foo) will be correctly accessible
the kernel capabilities will be appropriately scoped
the daemon will be restarted reliably on failure
local system administrator edits or configuration will be reliably preserved (e.g. if i add /etc/default/foo to make /etc/init.d/foo configurable, does that mean i now have to source /etc/default/foo from somewhere in my systemd unit file as well, or is it only supposed to affect sysvinit systems?)
etc…

shipping a sysvinit file responsibly means i need to help people use it, and test and analyze the ways that it fails. I have limited cycles, and i don't want to maintain a lot more code, especially if there is some other codepath that is already established and i can relatively simply express what i want common services to do in a declarative manner. And i definitely don't want local admins who have the package installed using sysvinit having radically different active system semantics. for example, it would be pretty bad if a daemon runs as root under sysvinit, but as user foo under systemd.

Consequently, i have opened bugs asking for help with sysvinit maintenance (e.g. #833854 and #855653), but have gotten very little concrete help in making them work reliably.

If i can't offer something that is reliable, i think i'm doing debian a disservice in shipping it. Certainly, i'd never complain if an administrator wants to write their own initscripts (for sysvinit) or servicedirs (for runit) or any other system integration. And i don't want to accidentally clobber a locally-customized sysvinit script either! But if anyone wants to step up to offer to co-maintain that part of the package so that it has comparable support to the systemd unit files, i'd welcome it.

but i'm going to focus my Debian package maintenance time on things that seem more useful and efficient and widely applicable to the Debian ecosystem. Today, that's systemd.

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Mon, 12 Nov 2018 19:54:06 +0000

You can still have multiple trees. The central tree with controllers attached and multiple v1-like trees without controllers. This is enough for systemd to manage the processes.

NO TO SYSVINIT - or initscripts, rather!

nix — Mon, 12 Nov 2018 17:22:26 +0000

I thought that in these days of cgroupsv2 there was a single unified tree, which systemd insists on managing?

NO TO SYSVINIT - or initscripts, rather!

anselm — Mon, 12 Nov 2018 09:39:08 +0000

If sysvinit was extended to, say, 128 run levels to handle dependencies, actually used as intended, and possibly extended to facilitate enabling/disabling/activating/deactivating daemons without needing to edit inittab, sysvinit would do everything a lot of people need without a lot of complexity.

Sysvinit can actually deal with more runlevels than the customary six. It's just that people seldom bother to define more of them.

That still wouldn't give you the consistency and convenience that systemd provides. Remember that much of the advantage that systemd confers, from the POV of system management, is in configuration, e.g., the obvious division between system-provided and locally-provided configuration settings which makes it easier to install a new upstream version of a software package without stomping on local customisations. You could obviously come up with a management layer for sysvinit that generates the real /etc/inittab file from a set of snippets in various directories, but the simple fact is that that hasn't yet been done, and now that systemd exists (and can be pared way down if required) the need for it is much less than it may have been earlier.

NO TO SYSVINIT - or initscripts, rather!

fest3er — Mon, 12 Nov 2018 02:44:14 +0000

"The problem here is that SysV (and its ilk) doesn't really have a parent that can be used to manage its children. For this to work you need a specialized persistent process that stays up at all time, because if it dies all of its children will also be killed."

I'll put forth that sysvinit *is* the parent that manages its children. It simply has never been used that way. Instead, the old method of using RC scripts (did this come fom Berzerkely?) was used (or continued). The very useful part of sysvinit (most of what's in inittab) was relegated to the status of a curious-looking red-headed stepchild useful only for running getty.

If sysvinit was extended to, say, 128 run levels to handle dependencies, actually used as intended, and possibly extended to facilitate enabling/disabling/activating/deactivating daemons without needing to edit inittab, sysvinit would do everything a lot of people need without a lot of complexity.

NO TO SYSVINIT - or initscripts, rather!

mpr22 — Sun, 11 Nov 2018 11:24:43 +0000

That comparison is not nearly as valid as you seem to want it to be, because the v239 source tarball has broader scope than the v44.

Most trivially, v239 includes udev (whose tarball at the time of the merger in v183 was about 70% the size of the systemd tarball) and the udev HWDB (which was merged later, and is itself pretty huge).

NO TO SYSVINIT - or initscripts, rather!

ms_43 — Sun, 11 Nov 2018 10:13:01 +0000

logind was part of the systemd project since its inception[1], and DBus (the user-space daemon) has never been[2] part of the systemd project.

There was an opportunity to contribute the necessary maintenance and bug fixes to ConsoleKit to keep it working, but instead the anti-systemd camp decided to troll the Debian technical committee decision process. I'm very happy that this turned out not to be a successful strategy.

[1] https://github.com/systemd/systemd/compare/v29...v30
[2] https://packages.debian.org/sid/dbus

Thanks!

HelloWorld — Sat, 10 Nov 2018 09:42:03 +0000

> To all of you (on any of both sides)
"Both sides"? Is that you, Donald?

Init system support in Debian

Wol — Thu, 08 Nov 2018 13:48:01 +0000

> More importantly, so that those of us sick of the whining can point and laugh when the simple solution doesn't work out. Every frickin sysadmin and engineer always think they can do better. Very rarely are they right - they usually simply don't understand the problem and at best can create a 'solution' that handles a tiny subset of the problems the technology they want to replace dealt with.

The problem is those people who want (or need, let's face it, a lot of us DON'T need a big complicated init) a simple init usually aren't the people with the skill to understand the problem.

Those of us who need a complicated init will design an init to suit our needs, and those of us who want a simple init will have to put up with it because we don't have the skills to do it ourselves.

It's like distros - your average distro is a jack-of-all-trades and any one user probably would describe 90% of it as unwanted crap. Problem is, my unwanted crap is your can't live without application, and vice versa.

So you need an expert in the complicated system to strip out the 90%, to make a dedicated single purpose distro or init system.

Cheers,
Wol

Init system support in Debian

Wol — Thu, 08 Nov 2018 13:36:53 +0000

As somebody who runs gentoo - this system I'm typing on is gentoo - I would beg to differ.

I tried to install gentoo/systemd on my laptop. I gave up - it's now running my second-choice distro, SUSE.

I am left with the *very* strong impression that there are several anti-systemd developers at the core of gentoo. And it shows in that there are a fair few references *to* systemd documentation, but *no pointers*, and the documentation is (apparently deliberately) quite hard to find.

So yes, I think gentoo is, sadly, one of the anti-systemd distros, even if it is quite easy (allegedly, I couldn't) to get a systemd version running.

Cheers,
Wol

Thanks!

oldtomas — Thu, 08 Nov 2018 09:43:59 +0000

Thanks for this article: it gives some perspective on how a community might find a way to resolve a seemingly insoluble conflict.

Skimming the comment section is a sad experience and still reveals how deep that conflict is. The tendency to denigrate the "other side" seems still... irresistible.

Luckily, the tone within Debian has (mostly) reached a cooperative, almost friendly level.

To all of you (on any of both sides): re-read the Russ Allbery quotes up there in the article. This is the example to follow (it has been from the hottest phase in the systemd "war", btw).

NO TO SYSVINIT - or initscripts, rather!

pizza — Wed, 07 Nov 2018 17:47:12 +0000

> systemd is nothing but daemontools reimplemented once again,.

That's like saying that Linux is just a reimplementation of UNIX.

(Along with the implication that there nothing new, different, or otherwise improved between the two)

NO TO SYSVINIT - or initscripts, rather!

rweikusat2 — Wed, 07 Nov 2018 17:04:03 +0000

As I already wrote: systemd is nothing but daemontools reimplemented once again, just based on a somewhat different set of assumptions about the technical issues such a system should handle. Like C string libraries, init systems are essentially rites-de-passage programming: Given enough time, everybody will have implemented one which solved (or sort-of solved) a particular problem the concept could be applied to (more or less forcibly).

But this again starts to drift from a technically interesting topic (technically interesting to me at least) towards marketing statements ("This shoesine is brilliant!") ... :-)

NO TO SYSVINIT - or initscripts, rather!

anselm — Wed, 07 Nov 2018 01:13:48 +0000

That would be to the point if the claim was that systemd is good because it is popular. A more likely proposition, however, is the converse: that systemd is popular because – at least in the eyes of the developers in most mainstream Linux distributions who decide what init system to default to – it is good.

NO TO SYSVINIT - or initscripts, rather!

ras — Tue, 06 Nov 2018 23:58:04 +0000

> The total size was less than 1.5Mb for systemd and dropbear.

How did you pull that off? On Debian stretch systemd + libsystemd-shared-232.so alone are 3.3MB.

Hmmm. Looking at the debian archives the systemd v44 .orig.tar.gz ball dates from 6 years ago, and is 860K. systemd v239 .orig.tar.gz is 6.8MB. Have you noticed a 8 fold increase in functionality?

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Tue, 06 Nov 2018 23:41:15 +0000

I acutally did an embedded system with systemd and musl about 5 years ago. It didn't have busybox but did have a Dropbear SSH daemon. The total size was less than 1.5Mb for systemd and dropbear.

NO TO SYSVINIT - or initscripts, rather!

ras — Tue, 06 Nov 2018 23:18:28 +0000

> But then you need bash/dash and a ton of other utilities (sed, awk, ...)

True, but these are usually there anyway, and on the systemd side of the ledger I didn't count libc or systemd's other 20 shared dependencies.

The Debian installed size is so much easier. Looking on an old machine, the installed size of sysV init and ancillary stuff is about 900KB. Adding inetd and cron increases it by 0.4MB. 1/10th the size does seem about right.

This stuff is not that hard. I wrote an "house keeping" system for a container as a dash script. It booted, started and stopped services, provided timers, did scheduled backups, rotated log files, maintained a status web page for monitoring and provided a framework for building containers using it. It was 3K lines and would do a fine job of managing my laptop.

Not all init system's can be simple. An init system for clusters like kubernetes is complex for reasons. But for a single machine with a couple of tasks, it's damned hard to see what added value systemd's complexity brings.

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Tue, 06 Nov 2018 22:39:35 +0000

> But if you insist on using systemd + libsystemd-shared's binary size, it's 2.5MB versus 34K for a sysV init I have lying around.
But then you need bash/dash and a ton of other utilities (sed, awk, ...) for the initscripts. You can mostly get away with busybox these days, which is around 2MB.

NO TO SYSVINIT - or initscripts, rather!

ras — Tue, 06 Nov 2018 22:36:29 +0000

> It's more like 1 MB

I was referring to the installed size reported by Debian. If you are going to use size, you should at least include the additional 1.5MB in libsystemd-shared-232.so. If you want just count binary size, you should probably be include everything in /lib/systemd, which is over 5MB. That misses a bit of it installed elsewhere of course. The single figure is maybe less accurate, but is a damned sight easier to come by and I doubt it effects the error margin overly.

But if you insist on using systemd + libsystemd-shared's binary size, it's 2.5MB versus 34K for a sysV init I have lying around.

> Hope this helps.

Not really. You''re talking to someone who has an accepted pull request for the systemd documentation. You are, right there is a *lot* of documentation, and it's very good. But don't underestimate the value of only something that does a similar job that only needs a few pages of documentation.

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Tue, 06 Nov 2018 21:51:06 +0000

Again, I'm not saying that systemd invented anything new. It just combined multiple obvious ideas in a brilliant way.

I'm not aware of any other init system that does this, even to this day. There were scattered bits and pieces here and there, but not a coherent design.

NO TO SYSVINIT - or initscripts, rather!

rweikusat2 — Tue, 06 Nov 2018 20:42:43 +0000

Cgroups were created to aggregate groups of processes for control/ management purposes. It's not particularly brilliant when something which is intentionally not portable beyond Linux uses them for this exact purpose, especially considering that there were even technical precedents in userspace: The lxc version I originally used in 2010 was 0.7.3 and it had been in development for some years at that time already. There's also an intentional design choice here: Cgroups are used to solve the problem of controlling misbehaving or intentionally hostile other processes, ie, programs written such that they cannot be managed with traditional UNIX facilities built around the notion of cooperating processes. I doubt this was ever a design objective for daemontools. It's certainly not a problem I have encountered in practice so far (my efforts in this respect being strictly restricted to providing process management facilities I demonstrably need).

Socket activation with the intent to reduce system boot time and provide better overall system performance saw the light of the day with the 4.3BSD inetd.

Fully asynchronous, that is, event-driven servers have also existed for a long time. Dan Kegel's original C10K paper mentioned the concept. The (older) racoon IKEv1 daemon also works in this way. This is again a design choice: Manage more than one process with the same process management process and accomodate buggy or intentionally hostile "other software". One could argue that buggy other software should rather be fixed and that one shouldn't be using intentionally hostile one.

The sysvinit program actually supports (some very limited form) of process management: It's possible to define per-runlevel commands which will be started automatically whenever a runlevel is entered and restarted if they ever terminate. Traditionally, this is unused except for gettys (to support user logins on all kinds of text terminals, virtual, physical, serial console etc). But the initscripts/ runlevel management system is completely independent of that: All init knows about this is that it's supposed to execute the command /etc/init.d/rc with the runlevel number as argument (both configurable). This means it's possible to use the sysinit program (or any other kind of "init init" which restricts itself to this role) together with any other process management program/ tool. Eg, the one I'm using is just a command which is executed during service start. Basically, it will execute another command with certain arguments in a subprocess. Should this other command terminate, it will be respawned. Further, the command creates an AF_UNIX stream socket for external process control. This can be used to query the status of the managed command, to initiate a stop or restart and to send abitrary signals to it.

If the process serving as init ever terminates, the kernel will panic. But ordinarily, death of a parent process doesn't affect its children. They'll be inherited by the init process which will eventually collect their exit status to prevent them from turning into zombies. Otherwise, backgrounding a program by forking and terminating the parent process wouldn't be possible.

NO TO SYSVINIT - or initscripts, rather!

rweikusat2 — Tue, 06 Nov 2018 17:44:42 +0000

I'm totally serious about not getting dragged into this kind of discussion, minus pointing out that "appeal to popularity" (ad populum) is a well-known term.

NO TO SYSVINIT - or initscripts, rather!

lkundrak — Tue, 06 Nov 2018 10:37:38 +0000

> I don't have a clue what that 10MB of code in systemd could possibly be doing

It's more like 1 MB:

$ size /usr/lib/systemd/systemd
   text	   data	    bss	    dec	    hex	filename
1238373	 259368	    416	1498157	 16dc2d	/usr/lib/systemd/systemd

If you also count other tools from the systemd repository then their file name usually gives a good clue about what the tool does. See: systemd-resolved -- a resolver. systemd-timedated -- manages time and date. systemd-hostnamed -- manages host name. Et cetera.

Also, both the init daemon and the supplementary tools are thoroughly documented. If you're really curious I wholeheartedly recommend trying out the man utility. It could turn out useful in your "administering a pile of servers" endeavour.

In an unlikely case the documentation won't be sufficient, you should know that the source is available for free and is perhaps one of more reasonable C programs that you'll find running on a typical Linux system.

Hope this helps.

NO TO SYSVINIT - or initscripts, rather!

ras — Tue, 06 Nov 2018 08:41:09 +0000

> is reasonable to ask what the other init system replacements “did wrong”

As a Debian Developer watching on when this happened, what they "did wrong" had nothing to do with the merits of the init system. ConsoleKit and a few other things were bit rotting badly at the time, and logind, dbus and a few other things got moved into the same source ball as systemd. I remember wondering consolekit and logind did that was so important - it turned out the most important thing is gnome needed something to give the local user (ie the one running the X server) permission to access local resources (like the sound card, and the keyboard), and gnome decided to use what systemd provided. (As I recall gnome didn't have a whole pile of alternatives to choose from.)

Gnome was Debian's default Window manager, so it was game over.

I use lxde on my laptop, and administer a whole pile of servers. Systemd works, but what has to happen is so trivial I don't have a clue what that 10MB of code in systemd could possibly be doing. I'm pretty sure I would of been happier with something much simpler. In fact I needed to boot a Debian chroot on a system without systemd once, and as this article points out the sysv scripts are indeed bit rotting so I wrote a shell script to interpret systemd's .service files for a headless server. It was under 300 lines. It makes the 1/2 a million lines in systemd a bit of a puzzle.

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Mon, 05 Nov 2018 23:28:54 +0000

It will be able to do it, just without any resource controllers. And you can have a separate cgroups tree with controllers attached.

NO TO SYSVINIT - or initscripts, rather!

luto — Mon, 05 Nov 2018 23:24:33 +0000

But what if I actually *want* systemd to manage my services?

NO TO SYSVINIT - or initscripts, rather!

anselm — Mon, 05 Nov 2018 23:19:43 +0000

The subreapers would give you the opportunity to track processes that exit, but you'd still need to use cgroups to do resource control.

NO TO SYSVINIT - or initscripts, rather!

anselm — Mon, 05 Nov 2018 23:17:45 +0000

For the record, I agree that there have been enough flame wars about systemd. But it is important to get one's basic facts right, including that (a) systemd was not started as a Red Hat project, and certainly by now includes active developers from many parts of the community, and (b) other distributions (whose developers, on the whole, aren't gullible incompetents either) adopted systemd because they felt it was technically the Right Thing to do, not because they were somehow (how exactly?) coerced to do so by Red Hat. Remember that Debian in particular did not take the decision to default to systemd at all lightly.

The fact that most major Linux distributions did adopt systemd as their default init system differentiates systemd from all of the other init system replacements (except Upstart), and as such it is reasonable to ask what the other init system replacements “did wrong” if they're as clearly superior to systemd as their proponents claim but yet, unlike systemd, didn't manage to convince multiple mainstream Linux distributions of their merits. It's easy to blame “politics and other social mechanics” but we should not altogether discount the fact that systemd, too, includes a good dash of clever engineering.

In any case, no matter what people think about systemd, it's not going away anytime soon. It is certainly not going away unless somebody comes up with something that the major distributions consider obviously better than systemd, and by now that is a pretty high bar to clear (especially since being “only” an init system replacement is no longer enough; to compete successfully with systemd there needs to be some proposition for the overall basic-plumbing aspect of things). It's still not entirely inconceivable, but somebody will eventually have to start writing code, rather than LWN comments about how terrible systemd is.

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Mon, 05 Nov 2018 23:17:25 +0000

I think you can simply use systemd without any controllers in a separate tree and manage your tree with controllers yourself.

Saving kernel size is a valid concern but I'm not sure how much you're going to save if you disable all cgroups controllers.

NO TO SYSVINIT - or initscripts, rather!

luto — Mon, 05 Nov 2018 23:12:37 +0000

To avoid using cgroups! This has two major benefits. First, if I want to save resources, I can run on a kernel without cgroups. Second, and more importantly, it would let me use systemd without using systemd as a cgroup controller, which would mean that I could arrange other cgroup policies that have nothing to do with systemd.

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Mon, 05 Nov 2018 23:02:56 +0000

I guess you can replicate cgroups process group functionality using subreapers. But why?

NO TO SYSVINIT - or initscripts, rather!

rweikusat2 — Mon, 05 Nov 2018 22:12:45 +0000

> You conveniently neglected to quote an important part of my sentence, namely

[...]

I've ignored that on purpose because while I'm somewhat interested in discussing the technology, I have zero interest to engage in a discussion of the surrounding politics and other social mechanics as that's bound to degrade into an entirely pointless flamewar of a very familiar shape quickly.

NO TO SYSVINIT - or initscripts, rather!

luto — Mon, 05 Nov 2018 21:28:12 +0000

I would personally rather see systemd use subreapers for this. If needed, the kernel could gain whatever mechanisms were needed.

NO TO SYSVINIT - or initscripts, rather!

anselm — Mon, 05 Nov 2018 21:23:21 +0000

You conveniently neglected to quote an important part of my sentence, namely

to come up with a set of reusable “support tools written in C” that init systems could avail themselves of, and make these popular across distributions, but nobody except Lennart Poettering and Kay Sievers actually condescended to doing that

As you say, init replacements are a dime a dozen, but none of them really achieved a lot of traction (with the possible exception of Canonical's Upstart). It is to Lennart's and Kay's credit that they managed to come up with something so convincing that virtually all major Linux distributions have rallied around it, and the resulting network effects are a major win for the platform.

(In the non-open-source area, practically every provider of proprietary Unix had come up with its own replacement for sysvinit even before systemd got started – Linux used to be the last holdout of sysvinit – but that is neither here nor there.)

NO TO SYSVINIT - or initscripts, rather!

Cyberax — Mon, 05 Nov 2018 20:18:53 +0000

> Control groups have existed since at least 2004 and their very purpose is "aggregating/ partitioning sets of tasks". It's not particularly brilliant to use them for this.
I don't remember other init systems doing this, though. It's brilliantly simple like many other inventions.

Socket activation and fully asynchronous design are also new.

> For the usual case that this is not the case, normal parent-child relationship and ensuring that managed processes don't background themselves are entirely sufficient. The lxc-project has been using them for containers since before systemd existed (Wikipedia puts its beginnings at 2010. In 2010, I was using lxc as base for virtualized IPsec VPN servers for mobile clients).
Uhm, systemd was released in 2010. At best this is an example of convergent evolution.

> Hence, the parent can reliably send signals to it and can provide an interface enabling other software to do so. It can also provide "only one running instance" feature reliably and can set resource limits for processes which either aren't privlileged or at least don't actively sabotage management.
The problem here is that SysV (and its ilk) doesn't really have a parent that can be used to manage its children. For this to work you need a specialized persistent process that stays up at all time, because if it dies all of its children will also be killed.

The earliest example of such process is DJB's daemontools. It follows the same ideology as systemd, it has declarative service description and it uses traditional UNIX process groups to track processes. It doesn't have dependencies or socket activation, though. It's also not asynchronous so a badly-written script can lock it up.

Upstart attempted to do better but its design honestly sucks. It also uses hacks like ptrace() to detect double-forking daemons.

NO TO SYSVINIT - or initscripts, rather!

rweikusat2 — Mon, 05 Nov 2018 20:09:42 +0000

> In theory it would of course be perfectly possible to come up with a set of reusable “support tools written in C” that init systems
> could avail themselves of, [...] but nobody except Lennart Poettering and Kay Sievers actually condescended to doing that in
> practice.

The set of "open source developers" on this planet is a proper subset of the set of developers.

NO TO SYSVINIT - or initscripts, rather!

rweikusat2 — Mon, 05 Nov 2018 20:07:57 +0000

Control groups have existed since at least 2004 and their very purpose is "aggregating/ partitioning sets of tasks". It's not particularly brilliant to use them for this. They're also not really needed unless one has to deal with misbehaving or even actively hostile software[*]. For the usual case that this is not the case, normal parent-child relationship and ensuring that managed processes don't background themselves are entirely sufficient. The lxc-project has been using them for containers since before systemd existed (Wikipedia puts its beginnings at 2010. In 2010, I was using lxc as base for virtualized IPsec VPN servers for mobile clients).

"PID files" are a grotty, traditional UNIX hack to prevent multiple instances of a program from running (a very dubious practice to begin with) and to enable some measure of process control by sending signals to the process whose pid is recorded in a pid file (which may or may not be the process actually supposed to get these signals). A well-behaved program won't 'escape' (or at least can be asked to avoid doing so) from its parent. Hence, the parent can reliably send signals to it and can provide an interface enabling other software to do so. It can also provide "only one running instance" feature reliably and can set resource limits for processes which either aren't privlileged or at least don't actively sabotage management.

[*] So far, I haven't encountered the case of a program which actively resisted management. Hence, I had no reason to create a tool for supporting this.