Bug#935778: race between fail2ban.service and logrotate.service
On Mon, 26 Aug 2019 at 07:18:47 +, 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
Bug#935778: race between fail2ban.service and logrotate.service
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
Bug#935778: race between fail2ban.service and logrotate.service
Package: fail2ban Version: 0.10.2-2.1 Severity: important Tags: patch 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 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fail2ban depends on: ii lsb-base 11.1.0 ii python3 3.7.3-1 Versions of packages fail2ban recommends: ii iptables 1.8.3-2 ii nftables 0.9.1-3 ii python 2.7.16-1 ii python3-pyinotify 0.9.6-1.2 pn python3-systemd ii whois 5.5.1 Versions of packages fail2ban suggests: ii bsd-mailx [mailx]8.1.2-0.20180807cvs-1+b1 pn monit ii rsyslog [system-log-daemon] 8.1908.0-1 ii sqlite3 3.29.0-2 -- debconf-show failed
