4 ms·

Any init system needs to be pid 1 [1] This blog post does not identify the subtle argument that upstart maintainers made against systemd at pid -1 : it also br

Any init system needs to be pid 1 [1] This blog post does not identify the subtle argument that upstart maintainers made against systemd at pid -1 : it also brings along with all the other services (like logind) that frameworks like Gnome depend on. So, if Gnome wants to depend on logind and logind depends on systemd (post systemd rev-205), this means that Gnome is irrevocably coupled to systemd which must run as PID-1 [2]. This means it becomes hard for upstart to be used with Gnome. There has been no doubt whatsover that an init system needs to run as PID-1. [1] http://en.wikipedia.org/wiki/Process_identifier#Unix-like http://en.wikipedia.org/wiki/Process_identifier#Unix-like [2] I must add here that Gnome does include a fallback path to not depend on systemd components.

vidarh 13y ago
A part of any init system needs to be pid 1. The question is how much of it, and whether or not Systemd piles too much stuff into pid 1 that could instead be farmed out to separate processes, handled by separate binaries, that could be more easily upgraded or replaced. (I don't know; I've not looked at Systemd enough to have an opinion)
- sandGorgon 13y ago
  they are separate binaries - however all of them depend on systemd (post rev 205) and cannot be run independently. this is because all of systemd's services rely strongly on cgroups for resource control and upstream kernel wants a single reader/writer for the cgroups API (the current filesystem model is going away). systemd is just following lockstep with what kernel wants and is becoming that API. There has been a lot of FUD around the "PID 1" disaster, but invariably every init system will have to have a single point cgroup writer. Systemd is just ahead of the curve.
  - ithkuil 13y ago
    http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html http://lists.freedesktop.org/archives/systemd-devel/2013-Jun... Anyone has more information about this from the kernel perspective ? Will systemd be the only API ? Sounds strange.
    - sandGorgon 13y ago
      This is a reasonable evaluation of the status - https://lwn.net/Articles/575672/ https://lwn.net/Articles/575672/ Basically, if you use systemd as the init system, then yes - it is the only API [1] . If you dont want to use systemd then there are alternate implementations of the cgroup API (e.g. cgmanager - http://cgmanager.linuxcontainers.org/ http://cgmanager.linuxcontainers.org/ ). IMHO, they are both incompatible with each other. Lennart has a reasonable justification of why systemd is implementing it's own API [2] [1] https://lwn.net/Articles/557111/ https://lwn.net/Articles/557111/ [2] https://lwn.net/Articles/557140/ https://lwn.net/Articles/557140/
abofh 13y ago
PID1 also comes with powers over capabilities and (in some cases) cgroups. You can do much of that with FSCaps, etc - but to control the bounding set, you have to be pid1. So - if you want init to be able to limit what processes can do, you will be pid1.

vidarh 13y ago

A part of any init system needs to be pid 1. The question is how much of it, and whether or not Systemd piles too much stuff into pid 1 that could instead be farmed out to separate processes, handled by separate binaries, that could be more easily upgraded or replaced. (I don't know; I've not looked at Systemd enough to have an opinion)

sandGorgon 13y ago
they are separate binaries - however all of them depend on systemd (post rev 205) and cannot be run independently. this is because all of systemd's services rely strongly on cgroups for resource control and upstream kernel wants a single reader/writer for the cgroups API (the current filesystem model is going away). systemd is just following lockstep with what kernel wants and is becoming that API. There has been a lot of FUD around the "PID 1" disaster, but invariably every init system will have to have a single point cgroup writer. Systemd is just ahead of the curve.
- ithkuil 13y ago
  http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html http://lists.freedesktop.org/archives/systemd-devel/2013-Jun... Anyone has more information about this from the kernel perspective ? Will systemd be the only API ? Sounds strange.
  - sandGorgon 13y ago
    This is a reasonable evaluation of the status - https://lwn.net/Articles/575672/ https://lwn.net/Articles/575672/ Basically, if you use systemd as the init system, then yes - it is the only API [1] . If you dont want to use systemd then there are alternate implementations of the cgroup API (e.g. cgmanager - http://cgmanager.linuxcontainers.org/ http://cgmanager.linuxcontainers.org/ ). IMHO, they are both incompatible with each other. Lennart has a reasonable justification of why systemd is implementing it's own API [2] [1] https://lwn.net/Articles/557111/ https://lwn.net/Articles/557111/ [2] https://lwn.net/Articles/557140/ https://lwn.net/Articles/557140/

abofh 13y ago

PID1 also comes with powers over capabilities and (in some cases) cgroups. You can do much of that with FSCaps, etc - but to control the bounding set, you have to be pid1. So - if you want init to be able to limit what processes can do, you will be pid1.