This configuration file is not part of new installs any more since 6dfe776b4eb60bd151066783ffcd8b674ac67340, but debian leaves old configuration files around unless the user purges them. It seems to do that even if there's no local modifications. (At least I don't remember local modifications on my system.)
Having this configuration file around is dangerous since e2f264aa5adf7f4a, as it will send a SIGHUP to a process that doesn't expect it.
I don't rememember this having given actual trouble until my upgrade to Ubuntu 18.10, and I could speculate that it has some change in behaviour for systemctl kill and how it deals with the parent pac4cli process and the actual daemon python3 -m pac4cli. This is wild speculation though.
I already pushed this commit to launchpad for the daily builds.
Trying to debug this was a perfect storm -- there's nothing in the systemd journal about why a process exits, and we also don't log the signals ourselves. Moreover, I discarded the SIGHUP hypothesis early on after checking the hooks under /etc/network, forgetting about fe581c7568e3f3becee82bfbc0b058364dac63df.
tkluck
commented
6 years ago
This configuration file is not part of new installs any more since 6dfe776b4eb60bd151066783ffcd8b674ac67340, but debian leaves old configuration files around unless the user purges them. It seems to do that even if there's no local modifications. (At least I don't remember local modifications on my system.)
Having this configuration file around is dangerous since e2f264aa5adf7f4a, as it will send a SIGHUP to a process that doesn't expect it.
I don't rememember this having given actual trouble until my upgrade to Ubuntu 18.10, and I could speculate that it has some change in behaviour for
systemctl killand how it deals with the parentpac4cliprocess and the actual daemonpython3 -m pac4cli. This is wild speculation though.I already pushed this commit to launchpad for the daily builds.
Trying to debug this was a perfect storm -- there's nothing in the systemd journal about why a process exits, and we also don't log the signals ourselves. Moreover, I discarded the SIGHUP hypothesis early on after checking the hooks under
/etc/network, forgetting about fe581c7568e3f3becee82bfbc0b058364dac63df.