Package: fetchmail Version: 6.4.16-1 Severity: grave This is currently run on testing since ages. I had to restart due to a changed fingerprint and the global service started to fail with:
$ systemctl status fetchmail.service ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon Loaded: loaded (/etc/init.d/fetchmail; generated) Active: active (exited) since Wed 2021-06-16 08:07:28 CEST; 1h 23min ago Docs: man:systemd-sysv-generator(8) Tasks: 0 (limit: 9313) Memory: 0B CPU: 0 CGroup: /system.slice/fetchmail.service giu 16 08:07:28 klecker systemd[1]: Starting LSB: init-Script for system wide fetchmail daemon... giu 16 08:07:28 klecker fetchmail[846490]: Starting mail retriever agent: fetchmail. giu 16 08:07:28 klecker systemd[1]: Started LSB: init-Script for system wide fetchmail daemon. giu 16 08:07:28 klecker fetchmail[846499]: starting fetchmail 6.4.16 daemon giu 16 08:07:28 klecker fetchmail[846499]: fetchmail: lock creation failed, pidfile "/run/fetchmail/fetchmail.pid": File o directory non esistente The /run/fetchmail directory ownership is correct (fetchmail:nogroup) and if I start the process by hand with: sudo -u fetchmail -- fetchmail --pidfile /run/fetchmail/fetchmail.pid --nosslcertck -f /etc/fetchmailrc --syslog it works regularly. So the problem is with the init script, still used by systemd. Here: start-stop-daemon -S -o -q -p $PIDFILE -x $DAEMON -u $USER -c $USER -- $OPTIONS; I think the problem resides. I see that the pidfile is passed at the same time to start-stop-daemon and the daemon (-p and $OPTIONS) which run in unprivileged mode. I changed the instruction into: start-stop-daemon -S -o -q -x $DAEMON -u $USER -c $USER -- $OPTIONS; and now it works. Note that currently man page reports: Warning: Using this match option with a world-writable pidfile or using it alone with a daemon that writes the pidfile as an unprivileged (non-root) user will be refused with an error (since version 1.19.3) as this is a security risk, because either any user can write to it, or if the daemon gets compromised, the contents of the pidfile cannot be trusted, and then a privileged runner (such as an init script executed as root) would end up acting on any system process. Using /dev/null is exempt from these checks. and bullseye runs dpkg v1.20.9 currently. I'm tagging this bug as grave because even if fetchmail is not always used in daemon mode, it breaks for sure existing configurations in an unexpected way (and the reason is quite obscure for the casual user) - cheers -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser 3.118 ii debianutils 4.11.2 ii libc6 2.31-12 ii libcom-err2 1.46.2-1 ii libgssapi-krb5-2 1.18.3-5 ii libkrb5-3 1.18.3-5 ii libssl1.1 1.1.1k-1 ii lsb-base 11.1.0 Versions of packages fetchmail recommends: ii ca-certificates 20210119 Versions of packages fetchmail suggests: ii exim4-daemon-heavy [mail-transport-agent] 4.94.2-5 pn fetchmailconf <none> pn resolvconf <none> -- Configuration Files: /etc/default/fetchmail changed: OPTIONS=--nosslcertck START_DAEMON=yes PIDFILE=/run/fetchmail/fetchmail.pid -- no debconf information -- Francesco P. Lovergine