Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Because systemd is event-driven, you can't actually be sure the service file won't be re-used in the running configuration - or that it won't trigger other service reloads/starts/stops due to its dependency specifications. Ergo systemd requires an explicit reload to commit the state of the unit files once you're satisfied they are as intended.

This is very important when you consider that unit files can kill other units on their conditions - I've used this feature in particular to make sure nginx goes down if a mountpoint becomes unavailable or the servicing process dies (and systemd can't restart it). This is extremely useful because it means a load balancer won't send requests to a webserver in an improper state. But it also means that while editing those config files, I wouldn't want systemd auto-reloading everytime I saved.



And in the end i will gladly trade a few seconds longer boot for a system i can actually reason about rather than treat as some kind of black box voodoo. The latter is why i moved away from Windows in the first place.


It's definitely more then a few seconds (systemd boots fast), but more importantly reasoning about unit files is a lot easier then reasoning about the init-script ordering.

With a unit file I can just declare the conditions under which it should run or stop. If the system doesn't achieve those conditions, then I can solve that problem - rather then having my unit run before the system is ready to do so.

You're not really reasoning about your system because you can say "this runs after this" if you don't also express all the dependencies and failure conditions.


Aren't you confused with Upstart, which is event-driven? Systemd is mostly goal-driven (e.g. on startup it will start default.target, which involves recursively starting its dependencies).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: