2009-03-07 19:06:08

by Sukadev Bhattiprolu

[permalink] [raw]
Subject: Re: [PATCH 0/7][v8] Container-init signal semantics

> Gregory Kurz proposed a solution:
> * when shutdown is called and we are not in the init pidns, then we kill
> the process 1 of the pidnamespace.
> * when reboot is called and we are not in the init pidns, then we reexec
> the init process, using the same command line. I guess this one could be
> easily retrieved if we are able to display /proc/1/cmdline ;)
>
> IMHO, this is a good proposition because it is generic and intuitive, no ?
>
> What do you thing ?

Yes, I think it makes sense. Do we have any prototype patches that
implement this behavior ?


2009-03-07 19:43:55

by Daniel Lezcano

[permalink] [raw]
Subject: Re: [PATCH 0/7][v8] Container-init signal semantics

Sukadev Bhattiprolu wrote:
>> Gregory Kurz proposed a solution:
>> * when shutdown is called and we are not in the init pidns, then we kill
>> the process 1 of the pidnamespace.
>> * when reboot is called and we are not in the init pidns, then we reexec
>> the init process, using the same command line. I guess this one could be
>> easily retrieved if we are able to display /proc/1/cmdline ;)
>>
>> IMHO, this is a good proposition because it is generic and intuitive, no ?
>>
>> What do you thing ?
>>
>
> Yes, I think it makes sense. Do we have any prototype patches that
> implement this behavior ?
>
I have a simple prototype for the first case, added in attachment.
For the second case, I didn't had time to do it yet as it is not so
trivial because we force an exec of another process.



Attachments:
kill-cinit-at-shutdown.patch (2.72 kB)

2009-03-07 19:52:10

by Greg Kurz

[permalink] [raw]
Subject: Re: [PATCH 0/7][v8] Container-init signal semantics

On Sat, 2009-03-07 at 20:43 +0100, Daniel Lezcano wrote:
> case LINUX_REBOOT_CMD_HALT:
> - kernel_halt();
> - unlock_kernel();
> - do_exit(0);
> + if (power_off_pid_ns(current->nsproxy->pid_ns)) {
> + kernel_halt();
> + unlock_kernel();
> + do_exit(0);
> + }

Even if current will get SIGKILLed when zap_pid_ns_processes() is
called, I see no reason it doesn't call do_exit(0).

> break;
>
> case LINUX_REBOOT_CMD_POWER_OFF:
> - kernel_power_off();
> - unlock_kernel();
> - do_exit(0);
> + if (power_off_pid_ns(current->nsproxy->pid_ns)) {
> + kernel_power_off();
> + unlock_kernel();
> + do_exit(0);
> + }

Same.

> break;
>
--
Gregory Kurz [email protected]
Software Engineer @ IBM/Meiosys http://www.ibm.com
Tel +33 (0)534 638 479 Fax +33 (0)561 400 420

"Anarchy is about taking complete responsibility for yourself."
Alan Moore.

2009-03-07 20:00:16

by Daniel Lezcano

[permalink] [raw]
Subject: Re: [PATCH 0/7][v8] Container-init signal semantics

Greg Kurz wrote:
> On Sat, 2009-03-07 at 20:43 +0100, Daniel Lezcano wrote:
>
>> case LINUX_REBOOT_CMD_HALT:
>> - kernel_halt();
>> - unlock_kernel();
>> - do_exit(0);
>> + if (power_off_pid_ns(current->nsproxy->pid_ns)) {
>> + kernel_halt();
>> + unlock_kernel();
>> + do_exit(0);
>> + }
>>
>
> Even if current will get SIGKILLed when zap_pid_ns_processes() is
> called, I see no reason it doesn't call do_exit(0).
Right and unlock_kernel too :)
>
>> break;
>>
>> case LINUX_REBOOT_CMD_POWER_OFF:
>> - kernel_power_off();
>> - unlock_kernel();
>> - do_exit(0);
>> + if (power_off_pid_ns(current->nsproxy->pid_ns)) {
>> + kernel_power_off();
>> + unlock_kernel();
>> + do_exit(0);
>> + }
>>
>
> Same.
>
>
>> break;
>>
>>