On Mon, 26 Aug 2019 at 07:18:47 +0000, Damyan Ivanov wrote:
> Some times (observed on slow virtual hardware) logrotate.service fails to
> start
> during boot, because the fail2ban logrotate configuration calls
> fail2ban-client
> flushlogs and that fails because fail2ban is not yet started.
>
> Prpoposed fixes:
>
> * make fail2ban service start before logrotate by putting
> WantedBy=logrotate.service
> in the [Install] section of fail2ban.service
logrotate.service is a periodic job run by a timer (systemd as a cron
replacement), not a job run once during boot (systemd as a sysv-rc
replacement). If I've stopped fail2ban.service (perhaps because I'm half
way through undoing a misconfiguration that was locking out legitimate
users, or because I'm doing other maintenance that leaves it in a broken
state), and then the logrotate timer goes off, running logrotate really
shouldn't be starting the fail2ban service as a side-effect...
(Requires, Wants and WantedBy also don't affect ordering, so if this plan
was the right one, you'd also want to use Before: see systemd.unit(5).)
> * make the fail2ban-client failure non-fatal by adding "|| true"
This seems more appropriate, although it would probably be better if the
client had an option to make it behave a bit like "systemctl try-restart",
so that it sends the flushlogs command to the service if it is running,
fails if the service is running but the command could not be sent, but
silently succeeds if the service isn't running.
smcv
