In which case a better idea would be to 1) audit the tree to make sure that nothing else will break if the pid range changes. and 2) make the change globally.
Discussion among the developers seems to indicate that a patch to make this tweakable will not be submitted - sane defaults! Cheers -0- On Thu Dec 18 2014 at 11:06:41 AM David CARLIER <[email protected]> wrote: > Might be useful, for example, with ps ... parse_pid => strtonum might use > pid_max as legit upper limit, ... top ... etc etc ... > > True processes id are randomised but by allowing greater value than > (SHRT_MAX-1) potentially, that makes those processes id even less > predictable. Gives the responsibility to the admin to decide if he wants > more room. > > Note : FreeBSD does it. > > Regards. > > On 18 December 2014 at 10:33, Owain G. Ainsworth <[email protected]> > wrote: >> >> On Thu Dec 18 2014 at 5:06:44 AM David CARLIER <[email protected]> >> wrote: >> >>> Hi all, >>> >>> I wished to propose a small diff in order to expose PID_MAX to the user >>> land via sysctl (readable/writable). It is actually fixed to the value >>> (SHRT_MAX-1) but with it we can set as will (with some boundaries...). >>> Might be also useful for app which rely on pid ... >>> >>> Feel free to give your impressions. >>> >>> Why do you need to programatically know the PID space? Since PIDs are >> randomised i'm not sure what this would buy you. I am very dubious why you >> would want to *set* the pid space. Can you explain why you want this? >> >> Cheers, >> -0- >> >>> Thanks in advance. >>> >>
