Broken by design: systemd
ewontfix.com
Broken by design: systemd
1–10 of 48 posts
Re: Broken by design: systemd
#2it 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
Re: Broken by design: systemd
#3it 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…
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.
Re: Broken by design: systemd
#4systemd is like a second kernel in user-space.
Re: Broken by design: systemd
#5systemd is like a second kernel in user-space.
and,
launchd is like a second mach kernel at a higher level. https://developer.apple.com/library/mac/documentation/Darwin...
Re: Broken by design: systemd
#6I've used systemd on Arch Linux for about a year now. It wasn't the end of the world, I can deal with it, but it's not fun.
I'm bothered by seemingly built-in units that have no corresponding unit files, which all default to enabled, including units for bootsplash stuff ("plymouth") that isn't used on arch linux. I'm very annoyed by mounts and such that don't even have units, files or otherwise, such as the "pstore" filesystem or autofs4. I'm super annoyed that since an upgrade half a year ago, the configuration option to disable use of some cgroup controllers was removed, and now any cgroup controllers supported by the kernel are used unconditionally.
I have good reasons for not using some of these things, but even more than that, one of the main reasons I like to use Arch Linux is that I like to add what I need, rather than try to make sense of and clean up the clutter of a typical operating system later. The lack of control and default-everything-on of systemd is really very annoying, and I'm bothered by the strategies mentioned in this article by which systemd makes itself the one and only practical modern init system for linux.
Re: Broken by design: systemd
#7it 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…
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…
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.
Re: Broken by design: systemd
#8systemd is like a second kernel in user-space.
Which should be good. If the OPs arguments about how dangerous it is to empower and stuff a lot of functionality into pid 1, think of how running in kernel mode on a cpu gives you power when your code is in the kernel proper.
So moving functionality out of kernel mode and into user mode is great. The only steps after that are moving as much functionality as possible to the user, and then to nobody. We do trend towards minimum permissions for the sake of security for a reason.
Re: Broken by design: systemd
#9I've used systemd on Arch Linux for about a year now. It wasn't the end of the world, I can deal with it, but it's not fun. I'm bothered by seemingly built-in units that have no corresponding unit files, which all default to enabled, including units for bootsplash stuff ("plymouth") that isn't used on arch linux. I'm very annoyed by mounts and such that don't even have units, files or otherwise, such as the "pstore"…
It seems to me that there is concerted effort to discredit alternative init implementations.
Example: https://en.wikipedia.org/w/index.php?title=Daemontools&actio...
I can't imagine what agency with a history of undermining technical standards could possibly be involved.
Re: Broken by design: systemd
#10Earlier quoted context omitted.
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…
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).