Hacker News Reader

Comment by bandrami | Hacker News Reader

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

View on HN

> 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"?

> 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.

> 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.

> 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.

> 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.

Hm. You seem to have a lot invested in convincing me that the systems I've been using for over a decade don't actually work. shrug.

Yes, I agree there are complicated ways that systemd and other rc systems can, largely, emulate the flexibility I get from writing a bash script to start the services I want started. I just don't really want them.

> You seem to have a lot invested in convincing me that the systems I've been using for over a decade don't actually work.

Yes, I used to work with people like you. "What's wrong with this method? we've been using these scripts for 10 years!"

And every time the database restarts the app server crashes and the site goes down. And for 10 years this has been seen as perfectly normal. After all, it's so simple! At 3am all someone has to do is login and run some site specific bash scripts that someone hacked together 10 years ago.

> And every time the database restarts the app server crashes and the site goes down.

Nope. I've also never had these phantom poorly behaved forking daemons leaving orphan processes all over the process space that people claim drove them to systemd. Like I said, YMMV. What I've built works really, really well, and can be picked up tomorrow by anybody who knows sh.

http://memory-alpha.wikia.com/wiki/Galaxy's_Child_%28episode...

Reply on news.ycombinator.com