Live data from Hacker News

Systemd: Enable indefinite service restarts

michael.stapelberg.ch

41–50 of 83 posts

Re: Systemd: Enable indefinite service restarts

#41
post #37

Earlier quoted context omitted.

Is it possible to do this system wide? Or do I have to do it for each individual service? It may be a trivial amount of work but if the configuration is fragile, I've gained nothing.

It's literally described in the article.

They're literally rhetorical questions. So, yes, you can set /defaults/, but you can't /force/ the configuration globally. Which means you still need to examine every single configuration file to understand the behavior of your system as a whole.

Hence.. why I called it a fragile mechanism.

Re: Systemd: Enable indefinite service restarts

#42
post #14
post #10

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

> AFAIK there's no way to have the kernel notify you of when a different process starts listening on a port. Would the ExecCondition be appropriate here, minimally, with a script that runs `lsof -nP -iTCP:${yourport} -sTCP:LISTEN`?

I'm talking: once your process has started, how do you wait for a process you depend on?

Obviously if systemd opens the port for you it's easy enough (in this case, even across machines), but otherwise you have to do a sleep loop. And I'm not sure how dependency restarts work in this case.

ExecCondition must moves the spin to systemd, and has more overhead than doing in your own process. There's no point in gratuitously restarting after all.

Re: Systemd: Enable indefinite service restarts

#43

I can understand avoiding infinite restarts when there is something clearly wrong with configuration, but I can't figure out why they made the "systemctl restart" command also limited by this. For services which don't support dynamic reloading, restarting them is a substitute for that. This makes "systemctl restart" extremely brittle when used from scripts. Nobody accidentally runs "systemctl restart" too fast, when…

[flagged]

Re: Systemd: Enable indefinite service restarts

#44
post #37

Earlier quoted context omitted.

It's literally described in the article.

They're literally rhetorical questions. So, yes, you can set /defaults/, but you can't /force/ the configuration globally. Which means you still need to examine every single configuration file to understand the behavior of your system as a whole. Hence.. why I called it a fragile mechanism.

It's trivial to grep all system service files for the relevant lines to see if they override the default. It is also easy to override that override to set it to whatever you like of so desired.

Re: Systemd: Enable indefinite service restarts

#45
post #37

Earlier quoted context omitted.

It's literally described in the article.

They're literally rhetorical questions. So, yes, you can set /defaults/, but you can't /force/ the configuration globally. Which means you still need to examine every single configuration file to understand the behavior of your system as a whole. Hence.. why I called it a fragile mechanism.

It takes a tenth of a second to run over every unit file in the system and change/set the restart policy.

Re: Systemd: Enable indefinite service restarts

#46
post #31

Earlier quoted context omitted.

Correct, because the startup limit had been reached: `service start request repeated too quickly, refusing to start`.

Thats terrifying, systemd shouldn't pretend to be smarter than manual intervention. That violates everything I ever enjoyed linux for, I left Windows because it thought it knew better than me.

It doesn't the user just fucked up. You can always run systemctl reset-failed whatever.service

Re: Systemd: Enable indefinite service restarts

#47
post #31

Earlier quoted context omitted.

Correct, because the startup limit had been reached: `service start request repeated too quickly, refusing to start`.

Thats terrifying, systemd shouldn't pretend to be smarter than manual intervention. That violates everything I ever enjoyed linux for, I left Windows because it thought it knew better than me.

It's not terrifying, it's mildly annoying. It's also fixed with 'systemctl reset-failed'. SysD doesn't know if 'systemctl start' was emitted by the operator or by a badly running script.

Re: Systemd: Enable indefinite service restarts

#48
post #31

Earlier quoted context omitted.

Correct, because the startup limit had been reached: `service start request repeated too quickly, refusing to start`.

Thats terrifying, systemd shouldn't pretend to be smarter than manual intervention. That violates everything I ever enjoyed linux for, I left Windows because it thought it knew better than me.

Hello, welcome to an init vs systemd rehash! :)

Re: Systemd: Enable indefinite service restarts

#49
post #31

Earlier quoted context omitted.

Thats terrifying, systemd shouldn't pretend to be smarter than manual intervention. That violates everything I ever enjoyed linux for, I left Windows because it thought it knew better than me.

It's not terrifying, it's mildly annoying. It's also fixed with 'systemctl reset-failed'. SysD doesn't know if 'systemctl start' was emitted by the operator or by a badly running script.

I don't think it should matter if 'systemctl start' was issued by an operator or an external script, it should try to start no matter what. SysD itself should use a different start command or flag that is subject to the limit when trying to restart after it detects a failure to start.

Re: Systemd: Enable indefinite service restarts

#50
post #17

> I would guess the developers wanted to prevent laptops running out of battery too quickly And I would guess sysadmins also don't like their logging facilities filling the disks just because a service is stuck in a start loop. There are many reasons to think a service failing to start multiple times in a row won't start. Misconfiguration is probably the most frequent reason for that.

Exactly. If a service crashes within a second ten times in a row, it's not going to come up cleanly an eleventh time. The right thing to do is stay down, and let monitoring get the attention of a human operator who can figure out what the problem is. Continually rebooting is just going to fill up logs, spam other services, and generally make trouble. I'm sure there are exceptions to this. For those, set Restart=alway…

It might actually, if a network connection is temporarily down.
Post reply on HN