On Sun, Dec 29, 2024 at 09:40:44 +0700, Max Nikulin wrote: > On 28/12/2024 23:47, Greg Wooledge wrote: > > On Sat, Dec 28, 2024 at 17:21:08 +0100, Roger Price wrote: > > > root@titan ~ /etc/init.d/fetchmail --quit > > > Not starting fetchmail daemon, disabled via /etc/default/fetchmail. > > > > The correct way to use a legacy sysv-rc init.d script to stop a service > > is: > > > > /etc/init.d/fetchmail stop > > I do not have fetchmail installed, [...]
Yeah, that's the common problem here. Only the OP is using this package, and apparently he's not on the current stable release. > My guess is that the main service process exited, but some its child (it > belongs to service's cgroup) were continuing running for some reason. Unless > improperly configured, systemd is able to kill all processes after some > timeout. Perhaps something is wrong with service type, KillMode, or > timeouts. Right. I had a similar guess (parent dies, children live on). 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. But I haven't actually read it. Anyway, I'm still going with the "init.d script failure, made irrelevant in the stable release because now it has a systemd unit file" theory. There's not much point trying to debug an init.d script in an oldstable release, when the stable release won't be using it (normally).
