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 7
Some 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...
Also does this ever occur without selinux ?
It doesn't appear to happen with selinux=0. Suspect that's more timing
than policy though.
That may not be - there is a signal failure path that is specifically
different and can only happen in the SELinux case if SELinux decides
the 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
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list