3 ms·

I don't know why you think cgroups has anything to do with the /usr split. systemd uses cgroups to tag processes with metadata about services, and to provide r

by Jasper_ 13y ago

I don't know why you think cgroups has anything to do with the /usr split. systemd uses cgroups to tag processes with metadata about services, and to provide resource limits. If you added a stub cgroups, then resource limits wouldn't apply, and you might run into issues with services not fully shutting down as you do right now with the POSIX service management. It's entirely possible, but you wouldn't get any of the upsides of systemd.

VLM 13y ago
I don't have that belief. My interpretation of the opposition against systemd revolves primarily around: 1) /usr split 2) Can't run on kfreebsd and hurd because they don't speak cgroups so either "we" can't run systemd or need to drop ports or need to support two init forever. You can eliminate #1 with some sysadmin work. A stub cgroups compatible API emulator type thing for kfreebsd and hurd would eliminate complaint #2 if the overall result were not much worse than existing sysvinit. One interesting solution is there is no particular reason to flick the power switch on kfreebsd over and over as quickly as possible. So one incredibly non-optimized way to "fake" cgroups process monitoring on kfreebsd would be to replace actual cgroup process monitoring with something ridiculous like "sleep 30". In 30 seconds, anything will have started or stopped, correct? Obviously a dev roadmap would be to replace/emulate/port real cgroup-like support, once people get tired of all cgroups api calls being replaced with "sleep 30". I can't be the first one to come up with this "great" idea.
- Jasper_ 13y ago
  First of all, systemd does not depend on anything relating to how /usr is mounted. Other components don't work properly with it; it simply detects the case and sends a warning. systemd itself will continue to work fine, but components that systemd launches will not. It's just a messenger. I also want to note that cgroups is not the only Linux-specific interface that's necessary for systemd. There's lots of them, and if you stub all of them out, then you've achieved portability with none of the benefits, and have potentially introduced a lot of bugs. You simply make systemd runnable, but unusable. I think you have the wrong impression of cgroups entirely, though. It does not do "process monitoring". Think of it more like a hierarchical processes tree. With a traditional hierarchical filesystem, to recursively delete everything in a folder, you use a combination of readdir and unlink. In cgroups, it's similar: you put processes in a "cgroup", and to kill everything inside a "cgroup", you iterate over everything and call kill. And much like in some filesystems you can say "make sure this subtree doesn't go above 1GB of storage", you can apply similar resource limits to cgroups: "make sure this subtree doesn't go over 2GB of memory and 25% CPU time", etc. A stub interface that doesn't iterate over any of the processes won't really do you much, and thus when you try to stop a service, it won't get shut down.

by Jasper_ 13y ago

VLM 13y ago

I don't have that belief. My interpretation of the opposition against systemd revolves primarily around: 1) /usr split 2) Can't run on kfreebsd and hurd because they don't speak cgroups so either "we" can't run systemd or need to drop ports or need to support two init forever. You can eliminate #1 with some sysadmin work. A stub cgroups compatible API emulator type thing for kfreebsd and hurd would eliminate complaint #2 if the overall result were not much worse than existing sysvinit. One interesting solution is there is no particular reason to flick the power switch on kfreebsd over and over as quickly as possible. So one incredibly non-optimized way to "fake" cgroups process monitoring on kfreebsd would be to replace actual cgroup process monitoring with something ridiculous like "sleep 30". In 30 seconds, anything will have started or stopped, correct? Obviously a dev roadmap would be to replace/emulate/port real cgroup-like support, once people get tired of all cgroups api calls being replaced with "sleep 30". I can't be the first one to come up with this "great" idea.

Jasper_ 13y ago
First of all, systemd does not depend on anything relating to how /usr is mounted. Other components don't work properly with it; it simply detects the case and sends a warning. systemd itself will continue to work fine, but components that systemd launches will not. It's just a messenger. I also want to note that cgroups is not the only Linux-specific interface that's necessary for systemd. There's lots of them, and if you stub all of them out, then you've achieved portability with none of the benefits, and have potentially introduced a lot of bugs. You simply make systemd runnable, but unusable. I think you have the wrong impression of cgroups entirely, though. It does not do "process monitoring". Think of it more like a hierarchical processes tree. With a traditional hierarchical filesystem, to recursively delete everything in a folder, you use a combination of readdir and unlink. In cgroups, it's similar: you put processes in a "cgroup", and to kill everything inside a "cgroup", you iterate over everything and call kill. And much like in some filesystems you can say "make sure this subtree doesn't go above 1GB of storage", you can apply similar resource limits to cgroups: "make sure this subtree doesn't go over 2GB of memory and 25% CPU time", etc. A stub interface that doesn't iterate over any of the processes won't really do you much, and thus when you try to stop a service, it won't get shut down.