On 8/9/07, Udo Richter <[EMAIL PROTECTED]> wrote:
>
> Petri Helin wrote:
> > Udo Richter wrote:
> >> I *think* that these are kill signals received by the child process.
> >> Which is strange, as the child does an exit immediately. (Unless you're
> >> somewhere between 1.5.1 and 1.5.3 - this changed in 1.5.4)
> >>
> >> 6 is SIGABRT, 11 is SIGSEGV and 9 is SIGKILL.
> >
> > I use version 1.5.6. I tested with my normal shutdown script and with a
> > script that just does an "exit 0". No difference there. Can the script
> > itself have any influence on the return value?
>
> Since 1.5.4, VDR forks into a child that does nothing but fork off a
> second child, and do an exit(0). The second child exec's the shutdown
> script:
>
> VDR
> +-- Child 1 -> exits
> +-- Child 2 -> runs shutdown
>
> That way the waitpid quickly returns, the second child becomes orphaned,
> and no process ends up being a zombie.
>
> Since the shutdown script runs orphaned, the return value of the script
> is not evaluated, nor does anyone wait for the script to terminate.
I noticed my vdr-1.5.6 did an emergency shutdown when I had poor signal
reception during a recording, which in itself is a fine thing to do... but
my "runvdr" script didn't seem to catch the bad exit code (exit 1) when vdr
did that, so VDR never restarted. This code snippet used to work for me,
but doesn't now:
eval "screen -D -m -S vdr $VDRCMD &"
# Remember PID of VDR process
PID=$!
# Wait for VDR to end or signal to arrive
wait $PID
# Remember return value of VDR
RET=$?
if test $RET -eq 0 -o $RET -eq 2; then exit; fi
TIMEOFDEATH=$(date +%s)
so, something is wrong with RET. Does this have to do with the children
spawning the exit code?
Groeten.
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
