Systemd: Enable indefinite service restarts
michael.stapelberg.ch
Systemd: Enable indefinite service restarts
1–10 of 83 posts
Re: Systemd: Enable indefinite service restarts
#2[flagged]
Re: Systemd: Enable indefinite service restarts
#3This must be a different philosophy. When I see something like this happening, I investigate to find out why the service is failing to start, which usually uncovers some dependency that can be encoded in the service unit, or some bug in the service.
Re: Systemd: Enable indefinite service restarts
#4This must be a different philosophy. When I see something like this happening, I investigate to find out why the service is failing to start, which usually uncovers some dependency that can be encoded in the service unit, or some bug in the service.
If your server has a bug that makes it crash every two hours you still want it up the rest of the time until you fix it.
Re: Systemd: Enable indefinite service restarts
#5This must be a different philosophy. When I see something like this happening, I investigate to find out why the service is failing to start, which usually uncovers some dependency that can be encoded in the service unit, or some bug in the service.
Of course you understand you can do both, like I do.
Re: Systemd: Enable indefinite service restarts
#6This must be a different philosophy. When I see something like this happening, I investigate to find out why the service is failing to start, which usually uncovers some dependency that can be encoded in the service unit, or some bug in the service.
I think the author's specified use case is to address transient conditions that drive failures.
When the given (transient) condition goes away (either passively, or because somebody fixed something), then the service comes back without anyone needing to remember to restart the (now dead) service.
By way of example, I've run apps that would refuse to come up fully if they couldn't hit the DB at startup. Alternatively, they might also die if their DB connection went away. App lives on one server; DB lives on another.
It'd be awfully nice in that case to be able to fix the DB, and have the app service come back automatically.
Re: Systemd: Enable indefinite service restarts
#7This must be a different philosophy. When I see something like this happening, I investigate to find out why the service is failing to start, which usually uncovers some dependency that can be encoded in the service unit, or some bug in the service.
Imagine you use systemd to manage daemons in a large distributed system. Crashes could be caused by a failure in a dependency. Once you fix the dependency, you want all your systems to recover as quickly as possible, you don't want to go through each one of them to manually restart things.
This doesn't mean that you don't investigate, it just means that you have an additional guarantee that the system can automatically eventually recover.
If you set a limit on number or time or restart, what's a reasonable limit? That will be context dependent, and as soon as it's more than a few minutes, it may as well be infinite.
Re: Systemd: Enable indefinite service restarts
#8I've always preferred daemontools and runit's ideology here. If a service dies, wait one second, then try starting it. Do this forever.
The last thing I need is emergent behavior out of my service manager.
Re: Systemd: Enable indefinite service restarts
#9I’ve been bitten by the restart limit many times. Our application server (backend) was crash looping, newest build fixed the crash, but systemd refused to restart the service due to the limit. A subtle but very annoying default behavior.
Re: Systemd: Enable indefinite service restarts
#10It would be nice if `RestartSec` weren't constant.
Then you could have the default be 100ms for one-time blips, but (after a burst of failures) fall back gradually to 10s to avoid spinning during longer outages.
That said, beware of failure chains causing the interval to add up. AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port.