[SM-Grimoire-Bugs] [Bug 13114] simpleinit doesn't stop services during shutdown on recent kernels

bugzilla-daemon at bugs.sourcemage.org bugzilla-daemon at bugs.sourcemage.org
Mon Feb 26 20:38:56 EST 2007


------- Additional Comments From jblosser-smgl at firinn.org  2007-02-26 19:38 -------

<#sourcemage-grimoire> afrayedknot: i think the ERESTARTNOHAND happens on line
263 of initctl.c
<#sourcemage-grimoire> afrayedknot: then the code runs forward without waiting
for init (pid 1) to do its thing
<#sourcemage-grimoire> afrayedknot: thats my latest theory
<#sourcemage-grimoire> emrys: I think you are right
<#sourcemage-grimoire> emrys: I saw the suspend in there when I was writing the
bug report, based on the other stuff I've seen since then that would make sense
<#sourcemage-grimoire> afrayedknot: dumapge
<#sourcemage-grimoire> afrayedknot:         if (init_is_simpleinit)
<#sourcemage-grimoire> afrayedknot:                 system ("/sbin/initctl -r
-f"); /*  Roll back services      */
<#sourcemage-grimoire> afrayedknot:         syncwait (1);
<#sourcemage-grimoire> afrayedknot:         my_puts ("Sending TERM signal to all
remaining processes...");
<#sourcemage-grimoire> afrayedknot:         kill(-1, SIGTERM);
<#sourcemage-grimoire> afrayedknot: the initctl doesnt do anything interesting
after sigsuspend runs
<#sourcemage-grimoire> afrayedknot: so it just exits, and dumps back in there
<#sourcemage-grimoire> afrayedknot: and then the TERM/KILL signals get sent out
<#sourcemage-grimoire> emrys: yeah that's the initctl where it craps...then
initctl has the SIGCHLD which shows up in the trace.  and that sigsuspend that
comes next fits the pattern.  and then the next thing in the trace is the TERM
<#sourcemage-grimoire> afrayedknot: ok, so we're on the right track
<#sourcemage-grimoire> afrayedknot: next step is to figure out why the kernel
throws that error back at us
<#sourcemage-grimoire> afrayedknot: its not a documented error on my box, but
they all are running old kernels
<#sourcemage-grimoire> afrayedknot: returns ERESTARTNOHAND at the end,
unlike the 2.6.13 version i saw earlier
<#sourcemage-grimoire> afrayedknot: it calls schedule the same way pause does
<#sourcemage-grimoire> afrayedknot: so i have to assume schedule doesnt return
<#sourcemage-grimoire> afrayedknot: or doesnt normally return
<#sourcemage-grimoire> afrayedknot: since the function would always return
<#sourcemage-grimoire> afrayedknot: at the end -- end of sys_rt_sigsuspend()
<#sourcemage-grimoire> afrayedknot: if that wasnt clear, signal.c line 2618 in
my version

<#sourcemage-grimoire> emrys: I don't even see an rt_sigsuspend in signal.c in
<#sourcemage-grimoire> emrys: ahhh
<#sourcemage-grimoire> emrys: that stuff has moved from
arch/i386/kernel/signal.c to just kernel/signal.c since 2.6.13
<#sourcemage-grimoire> emrys: it starts around
150256d8aadb3a337c31efa9e175cbd25bf06b06 : [PATCH] Generic sys_rt_sigsuspend()
<#sourcemage-grimoire> emrys: the i386-specific one went ahead as of
<#sourcemage-grimoire> emrys: this is informative:
ourcemage-grimoire> emrys: now which kernel version was that...
<#sourcemage-grimoire> emrys: ok it hit the released kernel at 2.6.16-rc2
<#sourcemage-grimoire> emrys: don't know if those are exactly it but since it's
a near-complete rewrite of that part of signal.c and the introduction of
ERESTARTNOHAND to rt_sigsuspend, I think that's the likely culprit.

Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the SM-Grimoire-Bugs mailing list