[Devel] Re: pid namespace bug ?
Sukadev Bhattiprolu
sukadev at linux.vnet.ibm.com
Thu May 6 13:52:33 PDT 2010
Daniel Lezcano [daniel.lezcano at free.fr] wrote:
> Ferenc Wagner wrote:
>
>> I noticed something strange:
>>
>> # lxc-start -n jail -s lxc.mount.entry="/ /tmp/jail none bind 0 0" -s lxc.rootfs=/tmp/jail -s lxc.pivotdir=/mnt /bin/sleep 1000
>> (in another terminal)
>> # lxc-ps --lxc
>> CONTAINER PID TTY TIME CMD
>> jail 4173 pts/1 00:00:00 sleep
>> # kill 4173
>> (this does not kill the sleep!)
>> # strace -p 4173
>> Process 4173 attached - interrupt to quit
>> restart_syscall(<... resuming interrupted call ...> = ? ERESTART_RESTARTBLOCK (To be restarted)
>> --- SIGTERM (Terminated) @ 0 (0) ---
>> Process 4173 detached
>> # lxc-ps --lxc
>> CONTAINER PID TTY TIME CMD
>> jail 4173 pts/1 00:00:00 sleep
>> # fgrep -i sig /proc/4173/status SigQ: 1/16382
>> SigPnd: 0000000000000000
>> SigBlk: 0000000000000000
>> SigIgn: 0000000000000000
>> SigCgt: 0000000000000000
>> # kill -9 4173
>>
>> That is, the jailed sleep process could be killed by SIGKILL only, even
>> though (according to strace) SIGTERM was delivered and it isn't handled
>> specially. Why does this happen?
Yes, SIGKILL is the only reliable way to terminate a container-init.
container-init needs to be immune to signals from within the container
but be open to receiving signals from parent container. These requirements
complicate the implementation of allowing SIGINIT/SIGTERM etc to
container-init from parent container.
Besides a realistic container-init would block such signals, in which case
the complexity in the kernel could be viewed as unnecessary.
Hope that helps,
Sukadev
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list