3 ms·

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/ https://lwn.net/Articles/520892/

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/ https://lwn.net/Articles/520892/ it's also discussed in the official debian debate https://wiki.debian.org/Debate/initsystem/systemd 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

rcxdude 13y ago
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.
- zanny 13y ago
  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.
  - dalias 13y ago
    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).
  - rcxdude 13y ago
    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.

rcxdude 13y ago

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.

zanny 13y ago
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.
- dalias 13y ago
  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).
- rcxdude 13y ago
  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.