Ludovic Courtès <l...@gnu.org> skribis: > You would expect wpa_supplicant to create its PID file atomically: write > it under a different name, then rename(2)… but no:
Regarding this PID file atomicity issue, a few other data points: Tor, syslogd (GNU Inetutils), sshd (OpenSSH), and dbus-daemon all do the exact same non-atomic PID file creation as wpa_supplicant. Libdaemon (used by Avahi) does something more fancy: it acquires an exclusive write lock (fcntl with F_SETLKW) on the PID file right after opening it, but since shepherd does not attempt to acquire locks on PID file, it has no effect. systemd and GNU Pies don’t take any precautions while reading PID files. The assumption seems to be that if the file exists, then it must contain a valid PID. So perhaps the problem we see with ‘wpa_supplicant’ is elsewhere. Ludo’.
