[Znafon]

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

[labawi]

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

[maweki]

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.

[hnarn]

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

[edoceo]

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.

[hnarn]

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.

[doiwin]

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

[izacus]

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

[tempguy9999]

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

[Znafon]

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.

[Znafon]

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.