Hacker News Reader

Comment by rjzzleep | Hacker News Reader

it seems like the pid 1 issue has been discussed quite a few times in the past. see also here https://lwn.net/Articles/520892/

it's also discussed in the official debian debate https://wiki.debian.org/Debate/initsystem/systemd

can anyone explain to me why they haven't just changed systemd to do less work in pid 1?

i've used systemd on my archlinux laptop for quite a while and was happy with how much faster the system boots. but i also found it to be too huge and too intertwined for basic maintenance tasks. but ofc that is just a personal opinion. suddenly i have to have a repertoire of systemd commands to do things i used to be able to do with basic unix tools

View on HN

I don't know. Given what I know about how cgroups and systemd works, I don't think there's any particular issue with having a thin shim and starting systemd as PID 2, and so getting some of the reliability gains this article talks about. But I don't have all that much knowledge of the details and there may be good technical reasons why that is a bad idea (the man page notes that it is possible via a command line flag, but that it is not supported and only intended for testing). There are some issues surrounding cgroups moving to a single-userspace-arbitrator model, but I don't know what requires this to be PID 1.

The article remarks its pid 1 to catch "bad" services that disown their parents and get defaulted to pid 1.

But I figure if they switched the bulk of systemd to pid 2, any negligent services would get complained about until they were fixed.

Almost all daemons have a command line or config file option to skip "daemonizing" so that the parent can watch the PID correctly. For the few that don't, you can fix them, hack them (e.g. LD_PRELOAD wrappers to shutdown their bogus double-forking), seccomp-ptrace them, or simply wrap them with a legacy-style monitor that reads the pid file and forwards signals it receives to the real pid (this last option of course doesn't fix the race conditions inherent in such usage).

This is something systemd can already handle. Linux has APIs to change the 'reaper' process (PR_SET_CHILD_SUBREAPER) so that orphaned processes move to a non PID 1 process.

Reply on news.ycombinator.com