On Tue, Mar 25, 2014 at 4:02 PM, Theo de Raadt <dera...@cvs.openbsd.org> wrote: >> well openBSD is so neat it provides a nice call: >> >> http://www.openbsd.org/cgi-bin/man.cgi?query=pidfile&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html >> >> but i failed to patch :'( this make the dhclient quit instead of >> going background, the fact there is two process may also explain why >> there is no pidfile. One is root he other dropped privilege, all of >> this is just giving me a headache at the moment. > > pidfile() is a dangerous subsystem. The files stay around long after > the process has died. There is no interlock. > > If you signal a process lists in a pidfile, who knows what you are > sending a signal to. Since the signals are often termination related, > this can have dangerous effects. > > We don't add more pidfile use, we actually remove them where we can. > This mechanism has applicability in some situations, but in the big > picture it is sloppy practice.
Ok. Listing process takes also times, and deleting the listed PID may also end in deleting another process in a race condition case. Or is there some kind of smart lock inside pkill ? Because pidfile subsystems exists, would it be possible to let the kernel create and delete a read_only pidfile when forking/cleaning the process ? -- --------------------------------------------------------------------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\
