Messages in this thread | | | Date | Mon, 22 Aug 2011 17:44:48 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 0/2] Send a SIGCHLD to the init's pid namespace parent when reboot |
| |
On 08/22, Daniel Lezcano wrote: > > If we pass the reason to the exit_code of the init process, that will be > a bit weird as the process is signaled and did not exited no ?
Just in case, you shouldn't change ->exit_code blindly. We should only change it if init was a) SIGKILL'ed and b) pid_ns->reboot_cmd is set. In this case we can assume that it was killed by sys_reboot.
Now. I didn't really mean exit_state should be equal to sys_reboot's cmd arg. I thought about something like
swicth (reboot_cmd) { case LINUX_REBOOT_CMD_RESTART: code = SIGHUP; break; case LINUX_REBOOT_CMD_HALT: code = SIGINT; // doesn't really matter what we report ... }
we know that init can't be killed by SIGHUP/SIGINT, and this can't be confused with the case when init does exit(exit_code).
But in fact I do not not think that WIFSIGNALED() is that important. init shouldn't exit anyway.
> Furthermore, how to differentiate an application container (eg. a > script) exiting with an error with the same value of a reboot reason ?
Well, I think it is better to fix the script than the kernel.
Daniel, I am not arguing. I agree that this looks like the hack anyway. Just I think that other approaches are even worse imho. We should try to make the kernel change as simple as possible.
> Wouldn't make sense to let the user to specify a signal via prctl where > the si_code is filled with the reason ?
Sorry, I don't quite understand the idea...
And, iiuc, the point was to "fix" sys_reboot() so that we do not need to mofify the distro/userspace?
In short. Please do what you like more. But I'd like you to know, I'll argue with any complications which (afaics!) we can avoid, I promise ;)
Oleg.
| |