On Thu, 2010-02-25 at 14:57 +0100, Ales Kozumplik wrote: > 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). Thanks for clumens for pointing out this thread. Perhaps this might explain bug#577708 - Fail to start X with graphical kickstart install Thanks, James
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
