Alan Cox wrote:
On Tue, Sep 26, 2006 at 04:43:26PM -0400, Adam Jackson wrote:rhgb X gdm X VT_ACTIVATE 7 VT_ACTIVATE 1 VT_WAITACTIVE 7Some variant where both do VT_ACTIVATE may mean one of them never gets its screen
Woo. So on the way up I could spin the activate/waitactive pair inside an alarm loop that interrupts the waitactive until it succeeds. That feels unbelievably dirty but I can't see much of a way around it. Also X server rebuilds take way less time than kernel rebuilds so in the interest of fixing this soon...
It doesn't appear to happen with selinux=0. Suspect that's more timing than policy though.Also does this ever occur without selinux ?That may not be - there is a signal failure path that is specifically different and can only happen in the SELinux case if SELinux decidesthe person doing the switch isn't allowed to signal the current graphical vt owner.
A VT switch triggered by one suid root process isn't allowed to generate a signal to another suid root process? Madness.
It wouldn't matter though, the server on its way up hasn't told the kernel what signal to use yet, you can't call VT_SETMODE until after you own the VT, so there's no way we could be signaling gdm's X server yet. If you mean signaling rhgb's server, it still doesn't matter, we're going to VT_ACTIVATE on the way down no matter what.
(I've also been told that rhdb itself will throw lots of VT_ACTIVATE around. Thanks, rhgb!)
- ajax