Re: fetchmail
On Sun, Sep 11, 2022 at 12:14:15PM +0200, Gerard ROBIN wrote:
> My problem is that I don't know what starts it.
> [...]
> Debian Bookworm (and Bullseye too) use systemd.
It's too late now, because you already "solved" the problem by purging
and reinstalling the package. (Which is not a bad solution -- just not
one that enlightens.)
Next time something like this happens, try to guess its service name,
and then start with:
systemctl status servicename
Guessing the service name is non-trivial. Sometimes it's the same as
the package name, and sometimes it's the same as the name of the program
inside the package.
If it's not either of those, then you can try grepping the list of files
contained in the package, thus:
unicorn:~$ dpkg -L openssh-server | grep 'systemd.*service$'
/lib/systemd/system/ssh.service
/lib/systemd/system/ssh@.service
"So the service name for the sshd daemon in the openssh-server package
is neither openssh-server nor sshd, but instead, ssh! Brilliant!"
You can also try looking through the contents of /lib/systemd/system/
either manually, or with globs or regular expressions, to try to figure
it out.
Anyway, once you've guessed the service name, systemctl status will
often give you some hints about what's happening. It may also contain
a small number of journal (logfile) lines. You can get more of those
lines by running "journalctl -u servicename".
Earlier in this thread, Nate posted the following output:
> $ 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 Sat 2022-09-10 15:37:33 CDT; 52min ago
> Docs: man:systemd-sysv-generator(8)
> Process: 1790 ExecStart=/etc/init.d/fetchmail start (code=exited, status=0/SUCCESS)
> CPU: 6ms
That's from <https://lists.debian.org/debian-user/2022/09/msg00205.html>.
Note that this particular package doesn't actually *have* a systemd
service file. One is "generated" on the fly, which simply runs the
sysv-rc script /etc/init.d/fetchmail.
Debugging problems with a sysv-rc start script is going to be a lot
more difficult, because they are inherently much more complicated. But
you can try a few things:
1) sysv-rc scripts are often configured by files in /etc/default/. Look
for a config file there, and see if it looks sensible. It might
contain comments; if so, read them. They are often helpful hints or
instructions for how the service can be configured.
2) You can try reading the init.d shell script itself, if you're fluent
in shell.
3) You can try running the init.d shell script directly, with trace mode
turned on, e.g. "sh -x /etc/init.d/foobar start". See where it blows
up, if it is in fact blowing up.
Of course, in your case, your grievance was that the service *wasn't*
blowing up. It was successfully starting and running, and that's
what you didn't want. So it would more likely be a configuration
issue, not a problem that sh -x is going to help you pinpoint.
Nevertheless, in other scenarios, where you *want* a service to run and
it's not running, this is sometimes useful.
Reply to: