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