[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Can start X once but no more



On Sun, 05 Sep 2010 20:08:14 -0400 (EDT), Tong <mlist4suntong@yahoo.com> wrote:
> On Sun, 05 Sep 2010 17:41:34 -0400, Stephen Powell wrote:
>> I also use the nv driver, and I can start the X server multiple times,
>> but usually not without manual intervention.  What usually happens is
>> that the old session only partially dies.  The new session tries to grab
>> vt 7, but finds it unavailable for allocation; so it allocates vt 8.  If
>> I switch to a text console with, say, Ctrl+Alt+F1, then if I attempt to
>> switch back to X with Alt+F7, I see a black screen.  But if I use Alt+F8
>> instead, I get back to X. Multiple restarts can force the use of higher
>> numbered vts. 
> 
> YES! that's *exactly* the symptom that I'm experiencing. 
>>
>> I have to jump through some hoops to get the X server back
>> on vt 7. I usually just reboot because it's easier, but it is possible
>> to do it without rebooting.
> 
> I don't mind jumping through some hoops to get the X to start at VT 7. I 
> want to avoid rebooting as much as possible. How were you able to do that?

I run GNOME, so this technique may not work for you or may need to be
adapted.  But here's what I do:

(1) I click on System -> Logout from the GNOME action bar.  The logout
completes, and the gdm daemon restarts, but not necessarily on vt7.

(2) I switch to text console number 1 via Ctrl+Alt+F1, then attempt to
switch back to X via Alt+F7.  If I see a black screen, I know it restarted
on the wrong vt.  I don't know which one yet, but I know it's not vt7.

(3) If I get a black screen in step 2, I switch back to text console number
1 via Alt+F1.  (Note: the Ctrl key is not needed here, since X is not
running on vt7!)

(4) On text console number 1, I login as root.  I find the
console-kit-daemon process via

   ps aux|grep console-kit-daemon

Sample output looks something like this:

   smp3:~# ps aux|grep console-kit-daemon
   root      1609  0.0  0.6  17424  3116 ?        Sl   Sep05   0:00 /usr/sbin/console-kit-daemon --no-daemon
   root      4274  0.0  0.1   3796   780 pts/0    S+   09:51   0:00 grep console-kit-daemon
   smp3:~# 

I obtain the process id from the output of the above command, in this case 1609,
and use it in the kill command:

   kill 1609

I can then deallocate vt 7 with

   deallocvt 7

I find that the "deallocvt 7" command fails unless I kill console-kit-daemon
first.  I also find which vt gdm started on via

   ps aux|grep gdm

Typical output might look something like this:

   smp3:~# ps aux|grep gdm
   root      1080  0.0  0.4  16100  2072 ?        Ss   Sep05   0:00 /usr/sbin/gdm
   root      1087  0.0  0.6  16412  3252 ?        S    Sep05   0:10 /usr/sbin/gdm
   root      1094  0.7  6.6  41044 34180 tty7     Ss+  Sep05  10:40 /usr/bin/X :0 -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt8
   root      4294  0.0  0.1   3796   780 pts/0    S+   10:03   0:00 grep gdm
   smp3:~# 
   
The above output shows it started on vt 8.  I keep that in mind for later.
Then I restart gdm with

   /etc/init.d/gdm restart

The X server restarts on vt 7.  When the restart occurs, the active vt automatically
switches to vt 7 and I see the gdm login screen.  I switch back to text console
number 1 with Ctrl+Alt+F1, and repeat the process of finding and killing the
console-kit-daemon process and deallocating vt 8 (or whatever vt it was on before).
I then logout of my root session on vt 1.

I then switch back to vt 7 via Alt+F7 and login.  Note: it is important not to
switch back to X between killing console-kit-daemon and deallocating the vt.
For this procedure I owe someone else on this list who helped me months ago,
but I don't remember who it was.  But thanks again to you, sir, though I don't
remember your name.

This is clearly a bug.  I shouldn't have to do this.  The question is, against
what Debian package do I report the bug?  My first thought was against
xserver-xorg-video-nv, but I have seen these symptoms (though less often) with
other video drivers, such as intel.  Perhaps console-kit is the right package,
since it owns the executable whose process must be killed in order to
deallocate the vt.

If this process, or an adaptation thereof, works for you, you may be able
to circumvent it by issuing (as root)

   mv /usr/sbin/console-kit-daemon /usr/sbin/console-kit-daemon.disabled
   killall console-kit-daemon

But I don't know what other ramifications this might have; so I can't
recommend it at this time.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-


Reply to: