Removing delay between logout and Slim prompt

R09UE-RAVEN · 2012-06-07 20:10:49

So, ever since I installed Slim as my display manager, I've had this problem. It always takes place when I logout. Here is what happens:

* In my Xmonad window manager, I hit Mod+Shift+Q. This performs the default action of quiting out of Xmonad and returning me to the login screen.
* Upon entering the keybind combination above, I briefly get a view of the default tty1 console login prompt.
* Moments later (a couple seconds), Slim throws up its login screen.

My question is whether it is possible to remove this tacky behavior?

In Other Words:

* Which of the three are causing this? Slim, tty1, or Xmonad?
* Can Slim start its login screen faster?
* Can tty1 be disabled during this? Inittab?
* Is Xmonad involved in this hiccup in any way?

Couple of Notes That Might be Helpful to Know:

* I am launching Slim on boot via the Daemon array.
* No black magic has been done to Slim. It has a stock theme and that's it.
* This problem has been present from the moment I installed Slim. I witnessed this problem the first time I tested it out.
* I have not installed or played with any other display managers, so I don't know whether this symptom is universal or not. This was the display manager I installed during my initial setup of Arch. I will proceed to test other display managers should that prove necessary.

Thanks,

Trilby · 2012-06-07 20:22:56

I didn't know slim could be ran from the daemons array. Have you tried just putting slim in your inittab and booting to rl-5?

I suspect this would do what you want.

R09UE-RAVEN · 2012-06-07 21:06:24

Hmm, I tried using the inittab method, but Slim didn't launch at all when I rebooted. I just got the tty1 login. This is probably my bad, though I thought I did it correctly. I set the rl to 5 and commented out the default respawn line and uncommented the slim respawn line. Out of technical curiosity, how would the daemon method be responsible? I used that method primarily because I like having my settings in as few config files as possible. Also, it's a well documented method in the wiki (and quite simple), so I would assume that simply using the daemon array to launch Slim wouldn't cause this issue. Otherwise, this problem would be more common....I don't know, I'm obviously doing something wrong.

root · 2012-06-07 21:08:22

I am running Slim from the inittab and this happens to me too.
Taking a look at the slim log file it seems the delay might be due to Slim waiting for X to begin accepting connections apparently causing that delay/tty1 switching.

Last edited by root (2012-06-07 21:09:41)

R09UE-RAVEN · 2012-06-07 21:10:06

Or maybe I'm not doing anything wrong, everyone has this problem, and I'm the only one OCD enough to make a forum post about it.

EDIT: Prima donna is wrong and is currently checking his slim log file.

Last edited by R09UE-RAVEN (2012-06-07 21:17:19)

root · 2012-06-07 21:17:35

The thing is R09UE-RAVEN is if this is actually a problem or just how this is supposed to work. On the basis of what I have said in #4 I understand that Slim has to wait for X in order to do anything else, that is start itself, as if X wouldn't accept connections at the time Slim was already running it would lead to an error message.

EDiT: I have to give you though that this delay does not happen when I lock the session (using slim lock even though I vaguely remember happening with other lockers too) but that mostly likely is due to not actually logging off and thus not "restarting" Slim to accept new login info.

Last edited by root (2012-06-07 21:22:41)

R09UE-RAVEN · 2012-06-07 22:25:35

Yeah, I see what you mean about delays due to waiting for the X server. It would be pretty sad if this is just X server causing latency and that's all there is to it. I'm afraid I'm not very capable of posting a section of my log at the moment, though I think a few key lines from a login entry might do. This is the basic pseudocode format of information that gets logged to my slim.log during a session:

/usr/bin/xauth:  file /var/run/slim.auth does not exist 


slim: waiting for X server to begin accepting connections
[Normal X server stats]
Current version of pixman: 0.26.0
[block of text about reporting problems, markers, and the choice of log and config files]

/usr/bin/xauth:  file /home/jonnyappleseed/.Xauthority does not exist

slim: waiting for X server to shut downServer terminated successfully (0). Closing log file.

* Obviously, the first error is due to the recent update.

Would you happen to know the orientation of the second and last lines? I was assuming (and quite wrongly) which way these entries were being posted chronologically. I'm assuming that the last line was the last entry in this sample, given that its closing the log file. Correct?

Last edited by R09UE-RAVEN (2012-06-07 22:53:14)

root · 2012-06-08 22:15:40

From what I know, yes, as, just like you yourself state, it wouldn't make much sense to close the log file if there were still things going on.

R09UE-RAVEN · 2012-06-08 23:06:55

The log doesn't really hint at a solution. Since the error about finding .Xauthority should not be contributing significantly to the hangup, I guess that leaves the last line. What doesn't make sense here is the shutdown time. I'm curious as to why X server's terminating procedure takes so much time. I guess what I don't get is X server's role in this and at what times it shuts down and at what times it starts up. This is how I understand the process in relation to the log entries:

1. During boot, Slim is launched via the daemon array, so it is ready with the login by the time booting is finished

2. I login via Slim, which launches X server and Xmonad (this part is extremely quick)
Log Entry: slim: waiting for X server to begin accepting connections
[Normal X server stats]
Current version of pixman: 0.26.0
[block of text about reporting problems, markers, and the choice of log and config files]

3. I close Xmonad and thus tell X server to terminate. (this part is amazingly longer than the startup time)
Log Entry: /usr/bin/xauth: file /home/jonnyappleseed/.Xauthority does not exist

slim: waiting for X server to shut down

4. During X server's closure, the period passes where neither X server nor Slim is using the display, thus Arch defaults to tty1

5. X server finishes shutting down and THEN Slim takes control of the display, showing me it's login.
Log Entry: Server terminated successfully (0). Closing log file.

My intuition tells me that shutting down shouldn't take more time than starting up. And even if it did take a while to shut down, can't X server give Slim the control of the display the moment it stops displaying the wm, that way it can close in the background? Better yet, why does X server have to close at all? Can't it simply close the session and wait behind the display manager until it's given a new window manager to launch?

Last edited by R09UE-RAVEN (2012-06-08 23:35:47)

root · 2012-06-09 21:50:30

Bear in mind that the login procedure and the session closing are not on the same level. The login one starts "fresh" from the x base system whereas the session closing has to deal with all the program the X session has started. Therefore it is understandable that it takes more time as first the system has to close these.

As I have said in #6 it might even be the way Slim works as an independet login manager. Therefore, by not being part of an overall environment pack (see f.e. gdm or kdm - they may be even having the same behaviour but the tty1 switch is "hidden" by a grey etc. background) it just "reboots"/exits like the rest of the X in order for the user to decide what to do, again from a "fresh starting point".

Arch Linux

#1 2012-06-07 20:10:49

Removing delay between logout and Slim prompt

#2 2012-06-07 20:22:56

Re: Removing delay between logout and Slim prompt

#3 2012-06-07 21:06:24

Re: Removing delay between logout and Slim prompt

#4 2012-06-07 21:08:22

Re: Removing delay between logout and Slim prompt

#5 2012-06-07 21:10:06

Re: Removing delay between logout and Slim prompt

#6 2012-06-07 21:17:35

Re: Removing delay between logout and Slim prompt

#7 2012-06-07 22:25:35

Re: Removing delay between logout and Slim prompt

#8 2012-06-08 22:15:40

Re: Removing delay between logout and Slim prompt

#9 2012-06-08 23:06:55

Re: Removing delay between logout and Slim prompt

#10 2012-06-09 21:50:30

Re: Removing delay between logout and Slim prompt

Board footer