On Sun, 29 Dec 2024, Max Nikulin wrote:
Commands that might help to discover what actually happened
journalctl -u fetchmail.service
Dec 28 10:37:58 titan systemd[1]: Stopping LSB: init-Script for system wide
fetchmail daemon...
Dec 28 10:37:58 titan fetchmail[1199929]: Not starting fetchmail daemon,
disabled via /etc/default/fetchmail.
Dec 28 10:37:58 titan systemd[1]: fetchmail.service: Succeeded.
Dec 28 10:37:58 titan systemd[1]: fetchmail.service: Unit process 1264
(fetchmail) remains running after unit
stopped.
Dec 28 10:37:58 titan systemd[1]: Stopped LSB: init-Script for system wide
fetchmail daemon.
Dec 28 10:37:58 titan systemd[1]: fetchmail.service: Consumed 6min 32.376s CPU
time.
Dec 28 18:46:01 titan fetchmail[1264]: terminated with signal 15
Notice the surprising entry "(fetchmail) remains running after unit stopped."
The final line is my command "kill 1264" which stopped fetchmail.
On Sat, 28 Dec 2024, Greg Wooledge wrote:
I looked at the file list for the oldstable package (the one I believe
Roger is using) at
<https://packages.debian.org/bullseye/amd64/fetchmail/filelist> and
this one does NOT have a systemd unit file. As I've pointed out a
couple times now, that version of the package only has an init.d file.
So, there is no service type, there is no KillMode, and I'm not *aware*
of any kind of timeouts enforced by the init.d script.
I ran command diff on the Debian 11 and Debian 12 ouputs of dpkg -L fetchmail
22a23,26
/usr/lib
/usr/lib/systemd
/usr/lib/systemd/user
/usr/lib/systemd/user/fetchmail.service
31a36
/usr/share/doc/fetchmail/README.systemd
On Debian 12 the command systemctl status fetchmail now has a "CGroup" entry:
● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
Loaded: loaded (/etc/init.d/fetchmail; generated)
Active: active (running) since Sat 2024-12-28 10:46:38 CET; 22h ago
Docs: man:systemd-sysv-generator(8)
Process: 252241 ExecStart=/etc/init.d/fetchmail start (code=exited,
status=0/SUCCESS)
Tasks: 1 (limit: 38046)
Memory: 3.0M
CPU: 52.194s
CGroup: /system.slice/fetchmail.service
└─252255 /usr/bin/fetchmail -f /etc/fetchmail
--pidfile /var/run/fetchmail/fetchmail.pid --syslog
So I'm assuming that something in Debian 11 fetchmail was mismanaging the PIDs,
and that that problem has been solved, although Debian 12 file
/var/run/fetchmail/fetchmail.pid shows
252255
150
which contains a PID which does not agree with the Process: declaration in the
systemctl output.
Roger
