SourceMage Grimoire Bug List

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=13114





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

<#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
stuff.
<#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: 2.16.19.2 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
ERESTARTNOHAND otherwise
<#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
2.6.13
<#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
283828f3c19ceb3a64a8544d42cc189003e8b0fe
<#sourcemage-grimoire> emrys: this is informative:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=283828f3c19ceb3a64a8544d42cc189003e8b0fe
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.