[g-i] Again on cdebconf's internal signal handling of SIGUSR1
Hi
Here at Extremadura Mike, Davide and me have been working on #339379 and
we definitely stated that's caused by cdebconf's internal way of
handling SIGUSR1 ( see [1] and Bug#316484 )
When a DFB app is VT switched, then one of its internal threads sends
SIGUSR1 to another of its threads and the DFB core gets suspended
correctly as it's suposed to (well, not SO perfecltly, some work has to
be done still..).
Then, the SIGUSR1 is propagated also to cdebconf (as it's suposed to do)
and cdebconf exits after saving the question DB: cdebconf exiting after
DFB is suspended makes the GTK frontend crash.
Now, we could modify the cdebconf so that, when SIGUSR1 is received, it
only saves the question DB and no longer exits: would this be a problem
somewhere (we know that rootskel wants theat cdebconf to be restarted
when receiving SIGSIGHUP/SIGUSR1).
cdebconf gurus, please reply.. :)
Attilio
[1] http://lists.debian.org/debian-boot/2005/12/msg00041.html
Reply to: