docker-systemctl-replacement icon indicating copy to clipboard operation
docker-systemctl-replacement copied to clipboard

Don't cap RestartSec at DefaultStartLimitIntervalSec

Open srd424 opened this issue 1 year ago • 3 comments

The code currently caps RestartSec at DefaultStartLimitIntervalSec, which I'm not sure makes a lot of sense, and isn't compatible with systemd. It may originally have been a copy/paste error?

My use case is a whole-system appliance which I dockerized. It relies on RestartSec=120 to run a job every two minutes; under docker-systemctl-replacement it runs every 10 seconds or less.

srd424 avatar Apr 07 '24 08:04 srd424

The 999 is not a good thing to put here.

Actually, RestartSec is influenced by StartLimitInterval/StartLimitIntervalSec - did you change that in the service spec? I guess that the real problem is using the default instead of the actual values.

gdraheim avatar Jun 10 '24 12:06 gdraheim

The 999 is not a good thing to put here.

Well, I copied the example of get_StartLimitIntervalSec which I assume uses it as a simple stand-in for infinity.

Actually, RestartSec is influenced by StartLimitInterval/StartLimitIntervalSec - did you change that in the service spec? I guess that the real problem is using the default instead of the actual values.

Sorry, I don't understand. StartLimitInterval / StartLimitIntervalSec in reality are usually used to slow down 'unexpected' restarts (due to faults etc.) RestartSec is for situations where we always want a service restarted at a given interval.

Apart from anything else systemd doesn't arbitrarily cap RestartSec and I can't see that there's any pressing need to deviate from its behaviour?

FWIW, here's the unit file (generated from a template, hence the <VAR> syntax):

[Unit]
Description=BirdNET-Pi Chart Viewer Service
[Service]
Restart=always
RestartSec=120
Type=simple
User=<USER>
ExecStart=<PYTHON_VIRTUAL_ENV> /usr/local/bin/daily_plot.py
[Install]
WantedBy=multi-user.target

srd424 avatar Jun 10 '24 13:06 srd424

SystemD is simply not documented well, so in the end one has to use experience to get to conclusions about its inner logic.

Now that you mention it, I see the other 999. That should be removed as well. Personally I would pick DefaultMaximumTimeout that was introduced for other purposes and it is currently 200 which atleast helps for your case as well.

gdraheim avatar Jun 10 '24 13:06 gdraheim