3 ms·

Can't stand it on servers. It takes an absurd amount of effort to just get a deterministic non-parallel service initiation. And the whole "systemctl start foo.s

Can't stand it on servers. It takes an absurd amount of effort to just get a deterministic non-parallel service initiation. And the whole "systemctl start foo.service && systemctl status foo.service" bit to make sure it actually started is such a regression it's mind-boggling. Plus it hates the fact that I use a static /dev tree (that's the only way I've found to do it on a server while keeping my sanity). On my laptop, it's fine, I guess, though even there I aesthetically dislike parallel service initiation; I'm glad Jessie still lets you replace it with a real init system, though I wish epoch [1] were packaged. [1] http://universe2.us/epoch.html http://universe2.us/epoch.html

parenthephobia 10y ago
> deterministic non-parallel service initiation When is this a problem? > systemctl start foo.service && systemctl status foo.service If you need to do that, the problem is with foo.service, not systemd. If foo.service fails to start, the right way, then "systemd start foo" will fail. This is true of any init system: if a service starts but then bails out after success has been reported to the user, it's too late to change that. > static /dev tree What's insanity-causing about a dynamic /dev tree "on a server"?
- bandrami 10y ago
  > When is this a problem? You're joking, right? Sysadmins need a deterministic boot order, period. If I want services to activate on a request I'll use inetd, but I haven't wanted that in years. > If you need to do that, the problem is with foo.service, not systemd. This isn't about assigning blame, this is about my server being usable. If a service fails to start I need the command that called it to fail also. > What's insanity-causing about a dynamic /dev tree "on a server"? Again, it's non-deterministic. Worse yet, it's declaratively configured in a million and one udev rules instead of one imperative run control script (which would at least be better, though still a bad idea) I need the devices on my servers to always have the same names and numbers, and obviously a static tree which doesn't expose any surface for my error or somebody else's attack is strictly better than a configurable system that does expose those surfaces. My run control scripts start the services that need to be started, in the order they need to be started, one at a time, because at 3 am with the alarms going off, that is transparent to me or to whoever has replaced me after the tragic bus accident. Sysadmins get this, which is why so much of the pushback against systemd came from us. Distribution maintainers love systemd, and I get that, but I'm not a distribution maintainer. So now my site-local imperative run control scripts replace an upstream declarative config system rather than a distro-maintained set of run control scripts. C'est la vie.
  - justinsaccount 10y ago
    > My run control scripts start the services that need to be started, in the order they need to be started, one at a time, because at 3 am with the alarms going off, that is transparent to me or to whoever has replaced me after the tragic bus accident. If your services need to be started in a particular order to work your services are broken. I've seen this sort of setup over and over again. Some custom 'startservices.pl' script that starts services "one at a time" in the "right order" like application server -> web server. Then one day the DBA restarts the database that lives on another box, the app server crashes and the entire site is down. So you get paged at 3am and run your startservices.pl script to fix the site. Great job, pat yourself on the back. Meanwhile, a site run by admins that use process supervision had a 5 second outage until the app server process was restarted automatically. You can tell systemd that one service depends on another, but it shouldn't really be needed. This doesn't even have anything to do with systemd. You can do the same thing using runit. > Sysadmins get this, which is why so much of the pushback against systemd came from us. ..."us". No. You don't speak for everyone.
    - bandrami 10y ago
      > If your services need to be started in a particular order to work your services are broken. Umm... that's possibly the silliest thing I've read on HN, which is going a ways. I don't know about you, but I like for my web server to come up after the NFS share it reads from is mounted. YMMV.
      - justinsaccount 10y ago
        > I like for my web server to come up after the NFS share it reads from is mounted. Why does this matter? Your load balancer or service discovery layer should detect that the web server is not functioning properly and take it out of rotation. What do you do when your NFS server has an outage? Even if you DID care about that sort of thing, systemd has a RequiresMountsFor option: RequiresMountsFor= Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path. Or with something like runit you would just do #!/bin/sh # web/run if [ -d /web/root ] ; then exit 2 fi .. normal start commands here That way if the box comes up before the NFS server the web server process will still properly start on its own as soon as NFS comes back up. I'm sure your hacked up scripts handle this scenario or anything else that can go wrong. Or maybe you get paged at 3am every few days when something breaks. YMMV.

parenthephobia 10y ago

> deterministic non-parallel service initiation When is this a problem? > systemctl start foo.service && systemctl status foo.service If you need to do that, the problem is with foo.service, not systemd. If foo.service fails to start, the right way, then "systemd start foo" will fail. This is true of any init system: if a service starts but then bails out after success has been reported to the user, it's too late to change that. > static /dev tree What's insanity-causing about a dynamic /dev tree "on a server"?

bandrami 10y ago
> When is this a problem? You're joking, right? Sysadmins need a deterministic boot order, period. If I want services to activate on a request I'll use inetd, but I haven't wanted that in years. > If you need to do that, the problem is with foo.service, not systemd. This isn't about assigning blame, this is about my server being usable. If a service fails to start I need the command that called it to fail also. > What's insanity-causing about a dynamic /dev tree "on a server"? Again, it's non-deterministic. Worse yet, it's declaratively configured in a million and one udev rules instead of one imperative run control script (which would at least be better, though still a bad idea) I need the devices on my servers to always have the same names and numbers, and obviously a static tree which doesn't expose any surface for my error or somebody else's attack is strictly better than a configurable system that does expose those surfaces. My run control scripts start the services that need to be started, in the order they need to be started, one at a time, because at 3 am with the alarms going off, that is transparent to me or to whoever has replaced me after the tragic bus accident. Sysadmins get this, which is why so much of the pushback against systemd came from us. Distribution maintainers love systemd, and I get that, but I'm not a distribution maintainer. So now my site-local imperative run control scripts replace an upstream declarative config system rather than a distro-maintained set of run control scripts. C'est la vie.
- justinsaccount 10y ago
  > My run control scripts start the services that need to be started, in the order they need to be started, one at a time, because at 3 am with the alarms going off, that is transparent to me or to whoever has replaced me after the tragic bus accident. If your services need to be started in a particular order to work your services are broken. I've seen this sort of setup over and over again. Some custom 'startservices.pl' script that starts services "one at a time" in the "right order" like application server -> web server. Then one day the DBA restarts the database that lives on another box, the app server crashes and the entire site is down. So you get paged at 3am and run your startservices.pl script to fix the site. Great job, pat yourself on the back. Meanwhile, a site run by admins that use process supervision had a 5 second outage until the app server process was restarted automatically. You can tell systemd that one service depends on another, but it shouldn't really be needed. This doesn't even have anything to do with systemd. You can do the same thing using runit. > Sysadmins get this, which is why so much of the pushback against systemd came from us. ..."us". No. You don't speak for everyone.
  - bandrami 10y ago
    > If your services need to be started in a particular order to work your services are broken. Umm... that's possibly the silliest thing I've read on HN, which is going a ways. I don't know about you, but I like for my web server to come up after the NFS share it reads from is mounted. YMMV.
    - justinsaccount 10y ago
      > I like for my web server to come up after the NFS share it reads from is mounted. Why does this matter? Your load balancer or service discovery layer should detect that the web server is not functioning properly and take it out of rotation. What do you do when your NFS server has an outage? Even if you DID care about that sort of thing, systemd has a RequiresMountsFor option: RequiresMountsFor= Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path. Or with something like runit you would just do #!/bin/sh # web/run if [ -d /web/root ] ; then exit 2 fi .. normal start commands here That way if the box comes up before the NFS server the web server process will still properly start on its own as soon as NFS comes back up. I'm sure your hacked up scripts handle this scenario or anything else that can go wrong. Or maybe you get paged at 3am every few days when something breaks. YMMV.