Stuart Henderson <s...@spacehopper.org> wrote: > On 2020-12-07, Harald Dunkel <ha...@afaics.de> wrote: > > About the PIDs: Maybe a systctl like > > > > kernel.pid_max = 4194303 > > > > known from other OSes could help to reduce the risk for PID conflicts. > > This doesn't help if you actually want reliability, rather than just > "reliable most of the time". > > There were also some concerns about what software would do with long > PIDs - even on a very basic level that adds another couple of columns > to top(1) output.
Yep. Also expanding the pid range increases the cost of allocpid(), so fork() becomes slower. > > If you store the PID files on a volatile file system, so you can be sure > > they are gone on the next reboot, anyway. > > /var/run is cleared at boot anyway - the problem is pid reuse during > uptime of the system. > > One can check that the new pid is owned by a process of the correct name > - but then the problem returns, the process name doesn't have enough > information to uniquely identify it. And if that is fixed there's no > need to save the pid. > > So if there's a problem to be fixed, it is to get the information into > the other process string.. It is worth considering what the 'lifetime' of a pid number. It is a unique number while the process is running. After it runs, the number is immediately available for reuse. There is no lazy "don't use that number yet, wait a while" scheme (adding such a scheme in OpenBSD would not solve the general problem).
