3 ms·

He's missing the point about socket activation. The problem it solves is different: if you have daemon B that depends on daemon A, you want to express that depe

by dnr 12y ago

He's missing the point about socket activation. The problem it solves is different: if you have daemon B that depends on daemon A, you want to express that dependency in the init system, so that it starts A before B. But just starting process A isn't enough to ensure that A is actually listening on the socket that B wants to connect to, since it takes some time to load the binary and do initialization. There's a race condition there, where B can try to connect before A binds to the socket. To fix the race, the init system needs to either monitor for the availability of the socket, or do it systemd-style where it opens the socket itself.

jerf 12y ago
As a bit of a disinterested observer (I'm mostly in the "just make it work" camp), I can't help but feel that if you pile up the problems that systemd seems to solve on one side, and pile up the enormous piles of code that are apparently necessary to solve the problem on the other, that systemd does not come out looking too good. (Writing this in C was probably a silly idea.)
- mhogomchungu 12y ago
  what language do you think systemd should have been written in?
thaumaturgy 12y ago
Honest question, how frequent or serious of a problem is this in practice? Most of the servers I deal with have only a handful of daemons running concurrently, and of those, maybe only a couple of daemons have interdependencies, and of those, they don't seem to have much trouble polling each other and coordinating startup. I mean, from the software developer's perspective, it's probably not fun to write that polling code and get it exactly right. But from the sysadmin's perspective, this doesn't seem to be enough of a real-world problem to justify the adoption of systemd. (I am not a fan of systemd, but I'm being neutral here because I won't learn anything if I dismiss it -- so hopefully someone will give an equally fair response.)
- dnr 12y ago
  To be honest, I don't think I've ever tracked a problem down to that race condition. But I'm willing to believe some of the things that systemd does (and increased parallelization in general) might increase the likelihood of it occurring. I think the larger point to take away here is that the systemd authors have a bias for doing "the right thing"[1], even if it means additional (implementation) complexity. Unix has traditionally been a stronghold of "worse is better" culture, which I think is where all this friction is coming from. [1] https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better
zimbatm 12y ago
That's for desktops where boot times are more important. Starting A and B at the same time allows to lower that time. On servers you want to wait for A to be ready before starting B. Otherwise the socket min timeout from B to A is dictated by the startup time of A and not the normal runtime timeout (seconds vs millis).
- dnr 12y ago
  In my recent experience, server boot time is more important to me than desktop boot time. My desktop and laptop basically never boot anymore, they just suspend and resume. But I wait for ec2 instances to boot at least several times a week.
  - digi_owl 12y ago
    Giving me further proof that the "shism" is between traditional server admins and cloud admins.
    - zimbatm 12y ago
      Except that I am a cloud admin
  - zimbatm 12y ago
    Most of the EC2 boot time is taken by the resource allocation and provisioning of the host (~2min). Changing the init system would only save you a couple of seconds of that.

by dnr 12y ago

jerf 12y ago

As a bit of a disinterested observer (I'm mostly in the "just make it work" camp), I can't help but feel that if you pile up the problems that systemd seems to solve on one side, and pile up the enormous piles of code that are apparently necessary to solve the problem on the other, that systemd does not come out looking too good. (Writing this in C was probably a silly idea.)

mhogomchungu 12y ago
what language do you think systemd should have been written in?

thaumaturgy 12y ago

Honest question, how frequent or serious of a problem is this in practice? Most of the servers I deal with have only a handful of daemons running concurrently, and of those, maybe only a couple of daemons have interdependencies, and of those, they don't seem to have much trouble polling each other and coordinating startup. I mean, from the software developer's perspective, it's probably not fun to write that polling code and get it exactly right. But from the sysadmin's perspective, this doesn't seem to be enough of a real-world problem to justify the adoption of systemd. (I am not a fan of systemd, but I'm being neutral here because I won't learn anything if I dismiss it -- so hopefully someone will give an equally fair response.)

dnr 12y ago
To be honest, I don't think I've ever tracked a problem down to that race condition. But I'm willing to believe some of the things that systemd does (and increased parallelization in general) might increase the likelihood of it occurring. I think the larger point to take away here is that the systemd authors have a bias for doing "the right thing"[1], even if it means additional (implementation) complexity. Unix has traditionally been a stronghold of "worse is better" culture, which I think is where all this friction is coming from. [1] https://en.wikipedia.org/wiki/Worse_is_better https://en.wikipedia.org/wiki/Worse_is_better

zimbatm 12y ago

That's for desktops where boot times are more important. Starting A and B at the same time allows to lower that time. On servers you want to wait for A to be ready before starting B. Otherwise the socket min timeout from B to A is dictated by the startup time of A and not the normal runtime timeout (seconds vs millis).

dnr 12y ago
In my recent experience, server boot time is more important to me than desktop boot time. My desktop and laptop basically never boot anymore, they just suspend and resume. But I wait for ec2 instances to boot at least several times a week.
- digi_owl 12y ago
  Giving me further proof that the "shism" is between traditional server admins and cloud admins.
  - zimbatm 12y ago
    Except that I am a cloud admin
- zimbatm 12y ago
  Most of the EC2 boot time is taken by the resource allocation and provisioning of the host (~2min). Changing the init system would only save you a couple of seconds of that.