Your message dated Mon, 6 Jan 2025 16:10:59 +0100
with message-id <[email protected]>
and subject line Re: Bug#1024990: freeradius.service needs
StartLimitIntervalSec=30s or similar
has caused the Debian Bug report #1024990,
regarding freeradius.service needs StartLimitIntervalSec=30s or similar
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1024990: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024990
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: freeradius
Severity: normal
Dear Maintainer,
a failing freeradius startup is repeated indefinitely, the unit never
ever reaches the FAILED state. This makes it harder than necessary to
see that there is a problem.
freeradius.service sets
Restart=on-failure
RestartSec=5
and in Debian, the defaults for
DefaultStartLimitIntervalSec=10s
DefaultStartLimitBurst=5
are usually in place via /etc/systemd/system.conf.
This means that freeradius is restarted every 5s, but it would have to
be restarted 5 times in 10s to be marked FAILED.
I suggest setting StartLimitIntervalSec=30s in freeradius.service, so
that restarts will be aborted and the unit marked as failed if it is
being restarted more than 5 times in 30s. You may want to make that 60s.
Does that make sense?
Florian
--- End Message ---
--- Begin Message ---
Control: tags -1 + wontfix
On 28/11/22 12:33 PM, Schlichting, Florian wrote:
Dear Florian,
> a failing freeradius startup is repeated indefinitely, the unit never
> ever reaches the FAILED state. This makes it harder than necessary to
> see that there is a problem
I think this is a matter of personal preference. FreeRADIUS might fail
to start due to a unavailable remote service, in this case I would prefer it
to keep trying. Service monitoring can/should look on more than the
systemd service status.
Unless you have a convincing argument I plan not to change this. You can
always override this locally using a systemd service dropin.
Bernhard
--- End Message ---
