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.