Stuart Henderson <stu@spacehopper.org> wrote:
> On 2020-12-07, Harald Dunkel <harri@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).
No comments:
Post a Comment