Hacker News Reader

Comment by Znafon | Hacker News Reader

> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup

This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.

View on HN

Many simple systems don't do parallel service startup like systemd, if that is what you mean.

They mean that you can specify dependencies. So start some service Y only after X has been started. I use this extensively in my home automation services. Can't start other services if the MQTT-Server hasn't started and that isn't done until the network is initialized.

Sure, but doesn't that also make them slower?

Hardly. I'm an OpenRC user. Booting OpenRC vs SystemD, desktop, server, VM. Near zero difference in boot time, neither side was a clear winner, nor always faster.

My favorite part is OpenRC still likes the old ways, has script extensions for new ways, and runs the same path every time.

That's just anecdotal. If it's a technical fact that SystemD does parallel upstarts where OpenRC for example does not, that just means you don't have a system where parallel upstart makes a difference.

No, I can not remember having a race condition regarding startup scripts.

Then you didn't have to mantain a system of any kind of complexity.

And you have? Can you give an example and how you solved it? Thanks! (edit: not trolling; curious)

I think my issue what binding Consul to docker0 while Docker is starting. Half the time the interface wasn't ready. I don't remember exactly how I fixed it but with SystemD you can just specify a dependency.

I think I had one where one service was trying to bind to a network interface that wasn't ready, maybe docker0. It was painful to find and fix.

Reply on news.ycombinator.com