Control: affects -1 logrotate

Hi,

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
 * make the fail2ban-client failure non-fatal by adding "|| true"

I am currently implementing the first suggestion, because the second feels like
hiding problems.


Thanks for considering,
    Damyan

Hello

I tried with your proposition and lintian isn't happy:

W: fail2ban: systemd-service-file-refers-to-unusual-wantedby-target
logrotate.service [usr/lib/systemd/system/fail2ban.service]
N:
N:   The specified systemd service file declares an unusual WantedBy=
N:   relationship.
N:   
N:   Most services that want to be started automatically at boot should use
N:   WantedBy=multi-user.target or WantedBy=graphical.target. Services that
N:   want to be started in rescue or single-user mode should instead use
N:   WantedBy=sysinit.target
N:
N:   Please refer to
https://wiki.debian.org/Teams/pkg-systemd/rcSMigration for
N:   details.
N:
N:   Visibility: warning
N:   Show-Always: no
N:   Check: systemd

WDYT?

Thanks

S

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

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