PID

Posted Oct 7, 2011 18:27 UTC (Fri) by sytoka (guest, #38525)
Parent article: A Plumber's Wish List for Linux

- random PID numbering scheme.

- add capabilities to LXC container (right now, drop capabilities which is a security aberration).

to post comments

PID

Posted Oct 7, 2011 23:20 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (3 responses)

How about udev working in LXC?

PID

Posted Oct 9, 2011 9:30 UTC (Sun) by arekm (guest, #4846) [Link] (1 responses)

And systemd. Or does it work currently in lxc/vserver guests?

PID

Posted Oct 10, 2011 17:04 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

I regularly test systemd in Linux containers (though only in systemd-nspawn, not LXC, since the latter is borked on Fedora, and has been since about always). It should boot up properly, however it you'll see a couple of warnings and error messages on the way, for example because sysctl cannot be applied and so on.

udev

Posted Oct 28, 2011 20:33 UTC (Fri) by gvy (guest, #11981) [Link]

udev in LXC is very much needed probably, but I hardly can imagine a single heavyweight use case so far.

PID

Posted Oct 8, 2011 0:22 UTC (Sat) by Richard_J_Neill (subscriber, #23093) [Link] (4 responses)

What about increasing the size of the pid maximum number? Otherwise, there is a real danger that the following code:

#!/bin/bash
process2 &
PID=$!
#do stuff for several hours.
kill $PID
exit

could end up killing the wrong process (if process2 exits, and the PID gets reused).

At least sequentially assigned PIDs make this not too probable: if the PIDs were randomly allocated, without increasing the possible range, it is riskier.

PID

Posted Oct 8, 2011 1:14 UTC (Sat) by neilbrown (subscriber, #359) [Link]

Is "echo 4000000 > /proc/sys/kernel/pid_max" enough for you?

Though to be fair I don't fully understand the memory usage implications of doing this. A quick look suggests that most things scale with the number of processes, not the number of possible processes.
There is a bitmap to track which pids are used, so if used-pids are not dense you would get more wastage in that data structure.

You could try it and see (??).

PID

Posted Oct 8, 2011 11:53 UTC (Sat) by abacus (guest, #49001) [Link]

There's no need to increase PID size in order to solve the race in your program. Just use the following:

#!/bin/bash
process2 &
jobspec="%1"
#do stuff for several hours.
kill $jobspec
exit

Safe killing of a child process

Posted Oct 8, 2011 12:10 UTC (Sat) by pjm (guest, #2080) [Link]

Increasing the pid maximum number won't remove the danger, it would only make the bug rarer.

What you want is kill %process2, or have a look at bash's job control documentation.

If job control stuff won't do what you're looking for, then you can add a trap on SIGCHLD and keep track of liveness yourself. The jobs and wait builtins might be useful in some cases.

All of the above should work on any Free Unix kernel, including Linux-2.6.xx and earlier; it doesn't require adding any Linux-3.x-specific features.

PID

Posted Oct 8, 2011 12:35 UTC (Sat) by nix (subscriber, #2304) [Link]

You can't eliminate the race here, but you can narrow it radically by looking at the ppid:

#!/bin/bash
process2 &
PID=$!
# do stuff for several hours.
[[ "$(ps -o ppid= -p $PID)" == $BASHPID ]] && kill $PID
exit

Now this will only lose if $PID dies and a new process starts in that narrow window, or if this bash has many children and one of them started after $PID dies and has the same PID (which you can solve, if you really need to, by remembering PPID->PID mappings in an associative array).