:> execution. :> :> If xdm happens to run before other getty processes, it may grab a vty :> which will be eventually opened by a getty later. :> : :vty's are assigned in /etc/ttys, though: : :ttyv4 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure :^^^^^ :so it the starting order shouldn't matter, unless you have a getty and xdm :assigned the same vty, and then it _should_ lock up whether using SMP or :not. : :----- :Chris D. Faulhaber <jed...@fxp.org> | All the true gurus I've met never

That's what I thought too... and it's correct for getty's. But xdm ignores the argument init passes to it.

So here is what happens:

init opens the vty and runs xdm.

xdm runs X which ignores the vty and locates a new one by scanning the vty's sequentially looking for one that is unused.

In this case a race is possible. X will not, in fact, run in vty 0 like we expected.

I tested this. My /etc/ttys runs xdm from ttyv0, but the X sessions winds up on ttyv4.

However X does search vty's sequentially, so all you need to do is make sure the first two slots in /etc/ttys for ttyv0 and ttyv1 are turned off.

So this is my recommendation now: Run xdm on ttyv0, leave ttyv1 turned off. Run your getty's starting with ttyv2.

# ttyv0 "/usr/X11R6/bin/xdm -nodaemon cons25 on secure ttyv1 "/usr/libexec/getty Pc" cons25 off secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure

Or, if you want to run xdm from your rc.local, leave both ttyv0 AND ttyv1 turned off. Why? Because ttyv0 will be allocated while the rc files are being run so you still have to leave at least ttyv1 turned off in init to avoid a race.

If you do this I believe there is no possibility of a race.

It would be nice if we could specify the vty that X is to allocate as an option to X. I couldn't find anything in the man pages right offhand to accomplish this, though.

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message