Hi,
Rawhide (and possibly other versions too) anaconda has race conditions
when starting X. We fire up X.org binary and go into signal.pause(),
waiting for either SIGUSR1 from X when it is started or SIGCHLD if it
terminated with an error. The problem is: before this branch of code
even begins anaconda has forked() itself and me might see many more
SIGCHLD signals coming from these non-X processes. If that happens, the
code responsible for starting X assumes X has failed (though it has not)
and switches for text install.
There's many more similar scenarios depending on when exactly is SIGCHLD
delivered. For instance if SIGUSR arrives and resumes the signal.pause
and then immediately SIGCHLD arrives, it messes up startup of the window
manager that was going on after startup of X. Typically it hits the
os.read() bit when main anaconda is watching the pipe with mini-wm. This
raises an WhateverSystemCallInterrupted exception and kills anaconda.
But there are endlessly more possibilities, the beauty of concurrency
lies in its lack of determinism.
Nonetheless, I seem to be the only one person running into this, maybe
it's because I test on a specific vmware server that gives me a unique
timing to trigger these problems. I am attaching a fix which
specifically forks the offending children into orphans. If similar bugs
start showing up more often we will perhaps need to change the X startup
mechanism (I am not sure how though).
Ales
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
