Mikaël Cluseau <mclus...@isi.nc> writes: > Do we agree that with systemd the pid-file logic becomes useless, and > thus the proper fix would be to get rid of them, or do you it would be > better to keep them, meaning the proper logic becomes the one of > "tmpfiles.d" ?
As long as the systemd units run the init scripts, which then fork the daemon, and the daemon makes a PID file, I think PIDFile= should be defined in the systemd unit. If PIDFile= is not set, systemd will make a guess as to what the main pid is, and it may be wrong. The relevant bits from man systemd.service(5): ,----[ GuessMainPID= ] | Takes a boolean value that specifies whether systemd should try to | guess the main PID of a service if it cannot be determined reliably. | This option is ignored unless Type=forking is set and PIDFile= is | unset because for the other types or with an explicitly configured PID | file, the main PID is always known. The guessing algorithm might come | to incorrect conclusions if a daemon consists of more than one | process. If the main PID cannot be determined, failure detection and | automatic restarting of a service will not work reliably. Defaults to | yes. `---- ,----[ PIDFile= ] | Takes an absolute file name pointing to the PID file of this daemon. | Use of this option is recommended for services where Type= is set to | forking. systemd will read the PID of the main process of the daemon | after start-up of the service. systemd will not write to the file | configured here. `---- -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
