seninha has quit [Remote host closed the connection]
hrberg has quit [Quit: No Ping reply in 180 seconds.]
chexum has quit [Remote host closed the connection]
hrberg has joined #picolisp
chexum has joined #picolisp
rob_w has joined #picolisp
beneroth has joined #picolisp
beneroth has quit [Ping timeout: 248 seconds]
beneroth has joined #picolisp
seninha has joined #picolisp
<abu[m]>
Tonight the picolisp.com server was rebooted by the provider. No idea why
<abu[m]>
But now the problem is that there is a fetchmail process running, which restarts when killed
<abu[m]>
Because this process runs, the mailing list does not start
<abu[m]>
The fetchmail systemd config is ignored
<abu[m]>
Any idea why fetchmail keeps popping up?
<abu[m]>
systemd reads some obscure /sys/fs/cgroup/user.slice/user-1001.slice directory. No idea what that is about.
<beneroth>
well it's systemd
<beneroth>
it's just horrible
<abu[m]>
indeed
<beneroth>
you removed /usr/lib/systemd/system/fetchmail.service ?
<abu[m]>
No, but modified it to see if anything changes
<abu[m]>
It says "Restart=always" so I changed to "Restart=no"
<beneroth>
systemctl disable fetchmail
<beneroth>
systemctl stop fetchmail
<beneroth>
also not helping?
<abu[m]>
I did try stop without success
<beneroth>
try disable
<abu[m]>
also changed "ExecStart=fetchmail --nodetach --daemon 300" to "700"
<beneroth>
I guess the always and the enable/disable is auto-restarting it
<abu[m]>
but "300" is seen in ps
<beneroth>
ah well
<abu[m]>
ok, I try disable now
<beneroth>
I think you need to run a systemd command after changing the file, it does not automatically detect and apply changes
<beneroth>
because you know, thats an improvement about how things were for decades...
<abu[m]>
yes, did so
<abu[m]>
I did restart after any changes
<abu[m]>
hmm
<abu[m]>
disable gives "fetchmail.service is not a native service"
* beneroth
wonders about having a statistic of the usage of systemd over time and the occurence of critical administrator failures
<beneroth>
ah
<beneroth>
the service files in /lib/systemd/system/ should not be edited
<beneroth>
the files in /etc/systemd/system/ are supposed to be edited
<beneroth>
or /etc/systemd/system/ is used to overwrite lib configs?
<beneroth>
Usually, if you edit a systemd unit file, for it to take effect, you need to run: sudo systemctl daemon-reload
<abu[m]>
I see. There is no fetchmail in /etc/systemd/system
<abu[m]>
But why does systemd start it then?
<beneroth>
no idea. I hate systemd.
<beneroth>
all troubles I have is because of it.
<abu[m]>
:(
<abu[m]>
I can see that systemd is the parent process
<abu[m]>
And I strace'd it and see it reads from /sys/fs/cgroup/user.slice/user-1001.slice
<abu[m]>
1001 is the mailing list user
<abu[m]>
I suspect the mailing list was calling fetchmail at the moment the server was rebooted
<beneroth>
slice is about resource quotas, no?
<abu[m]>
No idea
<abu[m]>
Totally obscure
<abu[m]>
Interesting. I experimented as root. But the fetchmail process does indeed belong to user 'picolisp'. I can kill it, sr do "fetchmail --quit" as user picolisp
<abu[m]>
But it immediately restarts :(
<abu[m]>
Look like I should reboot the server this night once more as a last resort
<abu[m]>
Ha!
<abu[m]>
Seems I managed to kill it
<abu[m]>
I renamed .fetchmailrc, then killed the process
<beneroth>
.fetchmailrc in the users homedir?
<beneroth>
wtf?
<beneroth>
afk lunch :)
<abu[m]>
Yes, exactly.
<abu[m]>
Bon appetite!
<abu[m]>
Cause .fetchmailrc was gone, the permanent restart failed it seems
<abu[m]>
After moving back to ~/.fetchmailrc everything seems to work fine ☺
<beneroth>
thanks
<beneroth>
well sounds like a solution, though not really like the root cause got resolved. but hey ¯\_(ツ)_/¯
<abu[m]>
T. Still interesting.I learned that systemd tries to be nice and restart processes of some user which were killed during reboot.
<abu[m]>
Took me half a day though ;)
<beneroth>
well I just spent half a day cleaning a customer system from wrong entries in LD_LIBRARY_PATH which was filled at various locations