4 ms·

Yes, not charting out your module boundaries and just bundling the system and service state along with parsing and cgroup management in the same process is rela

Yes, not charting out your module boundaries and just bundling the system and service state along with parsing and cgroup management in the same process is relatively unwise. Even Solaris SMF got it right by keeping init(8) small amidst the otherwise highly impressive feature set of the main service management, using contracts (the equivalent to cgroups, which actually predate them) outside PID 1. So the same can be done on Linux. At least one system, OpenRC, has explicit support in such a manner. (I take it you haven't read the architectural critique? Most pro-systemd arguments fall flat on their face in any event.)

sandGorgon 11y ago
systemd is NOT making the change to manage cgroups from PID1. Kernel is - systemd is just the first (and currently the only) one to comply with this change. Legacy cgroup API is going away. It is the same case for the /usr merge [1]. systemd is not forcing the change, but it is complying with the changes required and is getting blamed for it. [1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...
- vezzy-fnord 11y ago
  Incorrect. The kernel mandates a single writer. It doesn't enforce any particular PID.
  - jo909 11y ago
    You are right, but the cgroup manager should still be something that starts very very early, so you can start components that make use of it. If literally everything your init system starts should automatically use cgroups, you have to start it with the init system or as the first thing the init system will start.
    - simoncion 11y ago
      Remember that vezzy-fnord was responding to a comment that made the following erroneous statement: > systemd is NOT making the change to manage cgroups from PID1. Kernel is... I've heard systemd proponents assert that both udev and the cgroup manager must live in either kernel space or in PID 1, because to do otherwise would expose systemd to races or something while PID 1 started udev and/or the cgroup manager. These are also erroneous statements. It's rather important to correct such statements, as we're dealing with a (sadly) highly politicized technical topic.
      - sandGorgon 11y ago
        you are correct - I had conflated the PID1 argument with cgroup daemon, because as far as I stand.. it doesnt make a difference to me. There have been alternative managers like cgmanager [1] that lxc is bringing - which (surprisingly) work well with systemd as well [2] . Probably another reason not be scared of systemd ;) [1] https://linuxcontainers.org/cgmanager/introduction/ https://linuxcontainers.org/cgmanager/introduction/ [2] http://unix.stackexchange.com/questions/170998/how-to-create-user-cgroups-with-systemd http://unix.stackexchange.com/questions/170998/how-to-create...
        simoncion 11y ago
        > There have been alternative managers like cgmanager [1] that lxc is bringing - which (surprisingly) work well with systemd as well... Given that vezzy-fnord told you: [0] > The kernel mandates a single [cgroup] writer. you must have come to the understanding that the way cgmanager gets its work done on a systemd system is to pass control group management requests through to systemd's control group manager. Because the ultimate plan is to have a single CG manager, either cgmanager, or systemd's control group manager handles the CG management requests. There's no other way it can work. Because the systemd project is heavily vertically integrated, the odds that cgmanager uses its own CG manager are near-zero. > you are correct - I had conflated the PID1 argument ... because as far as I stand.. it doesnt make a difference to me. Yep. Your arguments and assertions have been almost exclusively soft and non-technical. Here's some advice: When people are making comments about technical topics, don't join in the conversation unless your level of understanding on the topic is just about as deep as that of those who are speaking. [1] > Probably another reason not be scared of systemd ;) Given the timestamp on this comment, it seems unlikely that you've not had the opportunity to read my reply [2] to one of your much earlier comments. Given that I lay out five solid non-fear-based arguments for why one might be worried about the systemd project, your assertion that I shouldn't be "scared of systemd" is extremely dismissive. [0] https://news.ycombinator.com/item?id=10486471 https://news.ycombinator.com/item?id=10486471 [1] Unless -of course- you're joining the conversation to learn more about the topic. In that case, refrain from making uninformed assertions, ask clarifying questions about things you are unsure about, and make the limits of your knowledge clear up front. [2] https://news.ycombinator.com/item?id=10488921 https://news.ycombinator.com/item?id=10488921
the_why_of_y 11y ago
This question has always appeared to me as academic, with little or no real-world relevance. If your service manager process were to crash, what are you going to do about it? If you restart the service manager, it won't know what state the system is in, which services are running and which are not, which services were running at the time when it crashed but then stopped just before it restarted, etc. How are you going to do that in a race-free and reliable way that is actually better in practice than the alternative (reboot)? And if your service manager is a single point of failure, it doesn't matter much which PID it's running it, it has to be perfectly reliable anyway (just like the kernel).
- vezzy-fnord 11y ago
  There's been a lot of research in fault recovery through message logging and checkpoint-based methods that could be applied here, e.g. [1]. Of course, you use "academic" as a snarl world, so I don't think anything will convince you. The idea that the service manager would not be able to know the system and service states is completely false. Solaris SMF is a design that does, via its use of the configuration repository. Simpler designs can then deduce enough metadata from the persistent configuration in the supervisor tree. There's many possible approaches. The idea that such fault recovery is implausible is a naive one that only one unfamiliar with the research literature could espouse. If we take your logic to its conclusion, we should just run everything in ring 0 with a single unisolated address space, because hey, anything can fail. Component modularization and communication boundary enforcement is the first step to fault isolation, which is the first step to fault tolerance. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.4299&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52....
  - the_why_of_y 11y ago
    That's very interesting, I didn't know SMF could do that. Let's see... init(1) is apparently restarted by the Solaris kernel automatically, which is different from Linux, no automatic kernel panic. https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/init/init.c https://github.com/illumos/illumos-gate/blob/master/usr/src/... * State File and Restartability * Premature exit by init(1M) is handled as a special case by the kernel: * init(1M) will be immediately re-executed, retaining its original PID. (PID * 1 in the global zone.) To track the processes it has previously spawned, * as well as other mutable state, init(1M) regularly updates a state file * such that its subsequent invocations have knowledge of its various * dependent processes and duties. Then init(1) and SMF's svc.startd(1) seem to have a bit of a relationship: * Process Contracts * We start svc.startd(1M) in a contract and transfer inherited contracts when * restarting it. Everything else is started using the legacy contract * template, and the created contracts are abandoned when they become empty. So init(1) creates the initial contract for svc.startd(1), then the latter creates nested contracts below that. (Aside: doing the equivalent cgroup manipulation on Linux would run afoul of the notorious one-writer rule.) If svc.startd(1) crashes, init(1) will restart it inside the existing contract of the crashed instance, so it can find its spawned services (in nested contracts), as well as its companion svc.configd(1). Now during startup, svc.startd(1) calls ct_event_reset(3), and this is really the interesting bit here: https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/svc/startd/fork.c#L526 https://github.com/illumos/illumos-gate/blob/master/usr/src/... The ct_event_reset() function resets the location of the listener to the beginning of the queue. This function can be used to re-read events, or read events that were sent before the event endpoint was opened. Informative and acknowledged critical events, however, might have been removed from the queue. I'm willing to entertain the idea that with this feature, SMF can properly track the state of the services that its previous incarnation launched, even if it crashed in the middle of handling an event. With any luck it will also handle the situation if a supervised process exits after the service manager crashes, and before it is restarted, as the contact should buffer the event in the kernel until it is read. Notably this is a Solaris specific kernel feature of the contract(4) filesystem; does Linux have anything equivalent in cgroups or somewhere? The other SMF process, svc.configd, uses an SQLite database (actually 2, a persistent one and a tmpfs one for runtime state), so it's plausible that it's properly transactional. > If we take your logic to its conclusion, we should just run everything in ring 0 with a single unisolated address space, because hey, anything can fail. That is an entirely erroneous extrapolation, as I never claimed any other single point of failure [in user-space] than the service manager.

sandGorgon 11y ago

systemd is NOT making the change to manage cgroups from PID1. Kernel is - systemd is just the first (and currently the only) one to comply with this change. Legacy cgroup API is going away. It is the same case for the /usr merge [1]. systemd is not forcing the change, but it is complying with the changes required and is getting blamed for it. [1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...

vezzy-fnord 11y ago
Incorrect. The kernel mandates a single writer. It doesn't enforce any particular PID.
- jo909 11y ago
  You are right, but the cgroup manager should still be something that starts very very early, so you can start components that make use of it. If literally everything your init system starts should automatically use cgroups, you have to start it with the init system or as the first thing the init system will start.
  - simoncion 11y ago
    Remember that vezzy-fnord was responding to a comment that made the following erroneous statement: > systemd is NOT making the change to manage cgroups from PID1. Kernel is... I've heard systemd proponents assert that both udev and the cgroup manager must live in either kernel space or in PID 1, because to do otherwise would expose systemd to races or something while PID 1 started udev and/or the cgroup manager. These are also erroneous statements. It's rather important to correct such statements, as we're dealing with a (sadly) highly politicized technical topic.
    - sandGorgon 11y ago
      you are correct - I had conflated the PID1 argument with cgroup daemon, because as far as I stand.. it doesnt make a difference to me. There have been alternative managers like cgmanager [1] that lxc is bringing - which (surprisingly) work well with systemd as well [2] . Probably another reason not be scared of systemd ;) [1] https://linuxcontainers.org/cgmanager/introduction/ https://linuxcontainers.org/cgmanager/introduction/ [2] http://unix.stackexchange.com/questions/170998/how-to-create-user-cgroups-with-systemd http://unix.stackexchange.com/questions/170998/how-to-create...
      - simoncion 11y ago
        > There have been alternative managers like cgmanager [1] that lxc is bringing - which (surprisingly) work well with systemd as well... Given that vezzy-fnord told you: [0] > The kernel mandates a single [cgroup] writer. you must have come to the understanding that the way cgmanager gets its work done on a systemd system is to pass control group management requests through to systemd's control group manager. Because the ultimate plan is to have a single CG manager, either cgmanager, or systemd's control group manager handles the CG management requests. There's no other way it can work. Because the systemd project is heavily vertically integrated, the odds that cgmanager uses its own CG manager are near-zero. > you are correct - I had conflated the PID1 argument ... because as far as I stand.. it doesnt make a difference to me. Yep. Your arguments and assertions have been almost exclusively soft and non-technical. Here's some advice: When people are making comments about technical topics, don't join in the conversation unless your level of understanding on the topic is just about as deep as that of those who are speaking. [1] > Probably another reason not be scared of systemd ;) Given the timestamp on this comment, it seems unlikely that you've not had the opportunity to read my reply [2] to one of your much earlier comments. Given that I lay out five solid non-fear-based arguments for why one might be worried about the systemd project, your assertion that I shouldn't be "scared of systemd" is extremely dismissive. [0] https://news.ycombinator.com/item?id=10486471 https://news.ycombinator.com/item?id=10486471 [1] Unless -of course- you're joining the conversation to learn more about the topic. In that case, refrain from making uninformed assertions, ask clarifying questions about things you are unsure about, and make the limits of your knowledge clear up front. [2] https://news.ycombinator.com/item?id=10488921 https://news.ycombinator.com/item?id=10488921

the_why_of_y 11y ago

This question has always appeared to me as academic, with little or no real-world relevance. If your service manager process were to crash, what are you going to do about it? If you restart the service manager, it won't know what state the system is in, which services are running and which are not, which services were running at the time when it crashed but then stopped just before it restarted, etc. How are you going to do that in a race-free and reliable way that is actually better in practice than the alternative (reboot)? And if your service manager is a single point of failure, it doesn't matter much which PID it's running it, it has to be perfectly reliable anyway (just like the kernel).

vezzy-fnord 11y ago
There's been a lot of research in fault recovery through message logging and checkpoint-based methods that could be applied here, e.g. [1]. Of course, you use "academic" as a snarl world, so I don't think anything will convince you. The idea that the service manager would not be able to know the system and service states is completely false. Solaris SMF is a design that does, via its use of the configuration repository. Simpler designs can then deduce enough metadata from the persistent configuration in the supervisor tree. There's many possible approaches. The idea that such fault recovery is implausible is a naive one that only one unfamiliar with the research literature could espouse. If we take your logic to its conclusion, we should just run everything in ring 0 with a single unisolated address space, because hey, anything can fail. Component modularization and communication boundary enforcement is the first step to fault isolation, which is the first step to fault tolerance. [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.4299&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52....
- the_why_of_y 11y ago
  That's very interesting, I didn't know SMF could do that. Let's see... init(1) is apparently restarted by the Solaris kernel automatically, which is different from Linux, no automatic kernel panic. https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/init/init.c https://github.com/illumos/illumos-gate/blob/master/usr/src/... * State File and Restartability * Premature exit by init(1M) is handled as a special case by the kernel: * init(1M) will be immediately re-executed, retaining its original PID. (PID * 1 in the global zone.) To track the processes it has previously spawned, * as well as other mutable state, init(1M) regularly updates a state file * such that its subsequent invocations have knowledge of its various * dependent processes and duties. Then init(1) and SMF's svc.startd(1) seem to have a bit of a relationship: * Process Contracts * We start svc.startd(1M) in a contract and transfer inherited contracts when * restarting it. Everything else is started using the legacy contract * template, and the created contracts are abandoned when they become empty. So init(1) creates the initial contract for svc.startd(1), then the latter creates nested contracts below that. (Aside: doing the equivalent cgroup manipulation on Linux would run afoul of the notorious one-writer rule.) If svc.startd(1) crashes, init(1) will restart it inside the existing contract of the crashed instance, so it can find its spawned services (in nested contracts), as well as its companion svc.configd(1). Now during startup, svc.startd(1) calls ct_event_reset(3), and this is really the interesting bit here: https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/svc/startd/fork.c#L526 https://github.com/illumos/illumos-gate/blob/master/usr/src/... The ct_event_reset() function resets the location of the listener to the beginning of the queue. This function can be used to re-read events, or read events that were sent before the event endpoint was opened. Informative and acknowledged critical events, however, might have been removed from the queue. I'm willing to entertain the idea that with this feature, SMF can properly track the state of the services that its previous incarnation launched, even if it crashed in the middle of handling an event. With any luck it will also handle the situation if a supervised process exits after the service manager crashes, and before it is restarted, as the contact should buffer the event in the kernel until it is read. Notably this is a Solaris specific kernel feature of the contract(4) filesystem; does Linux have anything equivalent in cgroups or somewhere? The other SMF process, svc.configd, uses an SQLite database (actually 2, a persistent one and a tmpfs one for runtime state), so it's plausible that it's properly transactional. > If we take your logic to its conclusion, we should just run everything in ring 0 with a single unisolated address space, because hey, anything can fail. That is an entirely erroneous extrapolation, as I never claimed any other single point of failure [in user-space] than the service manager.