Andy Green wrote: > Busybox init sure didn't spawn it... it must just > for accounting it marks it up as child of PID #1 when nothing real > occupies PID #1 yet.
PID 1 is also the precursor if init. It's the parent whose pending signals get checked there, not the child. The child starts with its signals cleared. > Anyway this issue doesn't come from JFFS2, if that isn't the > first kernel thread to behave that way and get aborted, then we solved > nothing by that. Yup, it would affect other kernel threads as well, if they're unfortunate enough to try to launch at that time. That's why I wrote "hack", because it would probably make the problem go away, but we may meet it again later ;-) > What we really wanted was to let *busybox init* have an advance warning > of power loss so it can go down in an orderly way. Yes, perhaps we could just have a sysfs file that controls whether we send that signal or not. Default would be "off". When turning it on, we'd check if we're in that problem situation, and generate the signal, if necessary. > -- and we might not make it through all that because we have > genuine low battery! Yes, but we still need to distinguish running out of battery power from trying to start with an empty battery. So perhaps the immediate power down would be a an option if the sysfs file says "off". However, since we already made it this far, we may also decide to just let it run until init can take over. (Which would then flip the sysfs switch, and get itself killed.) How does that sound ? In any case, I think we have two issues here: 1) We (OpenMoko) try to kill init unusually early, which widens that window in which that problem can happen, and thus we actually see it. 2) That fork logic is probably not what we (Linux kernel) want to do for "trusted" threads in general. - Werner
