GNOME Bugzilla – Bug 91273
improperly session managed programs can cause big startup lag
Last modified: 2004-12-22 21:47:04 UTC
To reproduce: 1. Add a program under "Startup Programs", e.g. "xmodmap /home/myname/.Xmodmap" (with priority 5) 2. Log out. 3. Log in - when the splash screen shows "Starting: xmodmap" (or whatever, mine speaks Danish) everything stops for about 15 seconds. xmodmap is being called, though, for my key bindings work. As I start both xmodmap and xbindkeys this adds a total of 30 seconds to the start up time. dselect says that my version of gnome-session is 2.0.5.
I should perhaps add that the bug was introduced at some point in the middle of the 2.0 series. The programs used to start in less than one second (this is on a 800 MHz PIII).
I've been reading through all the open gnome-session bugs and it looks like (just a wild guess) this bug might be related to the one I filed yesterday--bug #98363.
I'm not running any sound server. Somewhere deep, perhaps it's the same problem, though; I have really no idea. If someone could provide a pointer, I would be happy to take a look at the source. At the moment I don't even no what file to look in. I'm getting tired of having to wait for so long. :-)
Well, I've just did some testing, and, in addition to my bug in #98363 (which I still think may be related), I was able to duplicate this bug as it is and get some other peculiar problems too. When I added the program 'xmodmap /home/newren/xmodmap-swap' (where xmodmap-swap just had rules for swaping ctrl and caps-lock) and setting the priority to 5, the startup of gnome took an extra 20 seconds or so (normally, the complete startup takes just under 10 seconds from hitting enter on my password in gdm until everything has appeared). When I set the priority of this added program to 50, I had the following behavior: 1) No noticable difference in the amount of time it took to login, however: 2) If I tried to log out through an item in the gnome panel menus within the first 30 or so seconds after logging in, all my requests were silently ignored unless I tried to run some other program. #2 was really weird. Let me describe in more detail. If I waited 30 seconds or so after logging in (determined by the clock on the panel which shows seconds), everything was as expected. If I tried to log out before that time, nothing would happen. I'd either have to keep trying to log out (until about 30 seconds had passed), OR try to run some other program. Launching a gnome-terminal (after trying to log out before 30 seconds had transpired) seemed to bring gnome to its senses and it would immediately launch the logout pop-up box (i.e. shade the screen and bring up the little box that asks if you really want to log out). So, without the added startup programs, I observe none of the weird behavior mentioned. With the xmodmap program added at priority 5, I only get the behavior Ole mentioned (namely a severely lengthened log in process). With the xmodmap program added at priority 50, I get really weird behavior with trying to log out. Oh, and for what it's worth, I did all these tests on a stock Mandrake 9.0 system (which uses the gnome-session-2.0.5-4mdk package). I'm now pretty interested in this/these bug(s) too. I'm also willing to take a look at the source if someone will give me a pointer. I'm going to add myself to the cc list.
Ooops, forgot to add bugsquad keyword. Also, I just found bug 95834 which talks about the behavior I observed when I set the priority of the xmodmap startup process to 50. These bugs may be related.
I have experienced the same problem. When i straced gnome-session, i found this suspect poll(): Then gnome-session hangs for 30 secs waiting for an event, but no event occurs. [40af9bb0] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}, {fd=18 , events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN}], 11, 29866) = 0 <29.873615> Not shure what this ioctl does. fd 3 is the X server socket in /tmp [40ac6b41] gettimeofday({1039200710, 26737}, NULL) = 0 <0.000005> [40afb074] ioctl(3, 0x541b, [0]) = 0 <0.000006> [40ac6b41] gettimeofday({1039200710, 26952}, NULL) = 0 <0.000004> The poll is then retried, this time with a small timeout. [40af9bb0] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}, {fd=18 , events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN}], 11, 122) = 0 <0.139505> Then the windowmanager is started(?) [40ac6b41] gettimeofday({1039200710, 166607}, NULL) = 0 <0.000005> [40af4481] access("/home/jens/garnome-0.19.2/share/pixmaps/gnome-ccwindowmanager.png", F_OK) = 0 <0.000026> Invoking gnome-session with the parameters --warn-delay 3000 --purge-delay 3000 will make it start faster. The delay values are used like this (manager.c): gtk_timeout_add (purge_delay, purge, (gpointer)client) which makes me think that the bug is to be found in gtks timer functionality or the usage of this function.
Is this still relevant in 2.2?
Yeah, the problem have persisted through all versions. I'm currently running 2.2.1 and still have to wait.
Setting version->2.2.x and changing GNOMEVER2.0->GNOMEVER2.2, as per Ole's comments.
I think that the problem is that gnome-session is waiting until the program open a window or register as a X client. try 'xterm -e xmodmap ....' instead.
I got the same problem! When I put gkrellm into the session (well, it does this itself) - I get very long delay at startup (and see the splash screen for a very long time). Any workarounds? Cheers, Sergey
Have any of you tried the latest libbonobo to see if it's related to the fix there for slow startup?
I haven't tried to duplicate this for quite some time. I'll try again soon (ping me if I forget) to see if I can get this under GNOME 2.3.
Same story with the latest stuff I could get: % rpm -q libbonobo libbonobo-2.3.5-1
Now gkrellm works OK 2.1.18. Alan Swanson found the way to fix(workaround?) the problem. Probably, gnome-session should be fixed to coexist peacfully with "bad" application which do not have this workaround? Actually, the question is whether it WAS gkrellm incompatibility or it IS gnome-session bug. The only judge here is ICCCM certainly. The line from gkrellm changelog: o Alan Swanson <swanson--at--uklinux.net> patch: register the previous session id with the session manager to avoid session manager startup hangs. Also register the optional PID for sessions.
It is a gnome-session bug. The startup program thingie is supposed to take care of non-session aware programs.
gkrellm is session-aware. And almost always it was. The problem was that its session awareness was incompatible with gnome-session. Now it is compatible. Now the question is whether gkrellm's earlier session-managment was not 100% right - or gnome-session's code is not 100% right. I heard some people have similar problems with xmms - but I do not know exactly.
Yeah, but gkrellm is just one case. I was refering the xmodmap problem which I still have.
Updating the subject and keywords a bit.
Nothing new? I still have this strange behaviour in gnome 2.6.2...
Updating version due to Giacomo's comment
This should be related to bug 116814.
Marking as a dup of bug 116814, please feel free to re-open if you think these are different bugs. *** This bug has been marked as a duplicate of 116814 ***