Delayed Login

[aramadia]

Logging into ubuntu results in excessively long login time. After entering the password the background is displayed but nothing happens for the next 10s. Loading continues afterwards.

Going through system log reveals

Oct 30 23:48:33 m1530 pulseaudio[15958]: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted
Oct 30 23:48:44 m1530 gnome-session[15895]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout

A fix is to go to System->Preferences->Appearance->Visual Effects and use the "None" setting. No error is reported and login is quick. After switching back to normal, the error appears again.

Error has been confirmed with others: http://ubuntuforums.org/showthread.php?t=963800

Details:
Fresh install of Ubuntu 8.10
Video card is 8600m gt using proprietary 177 NVIDIA drivers

[Sebastien Bacher (seb128)]

the issue is likely a compiz one if using no effects workaround the bug

[Sarath (prosarath)]

I have put this to a lot of people. It may seem disabling compiz solves the issue, but the root cause is some where is gdm or more likely in X. I am speculating but, just hoping this bug reaches visibilty of the right people.

[mercutio22 (macabro22)]

I am changing the status to confirmed, since so many people in the forum thread Sarath mentioned are experiencing this and I can also reproduce this behavior in two intrepid ibex computers.

[Jack Deslippe (jdeslip)]

Bug 286696 is another duplicate of this - but it has a lower number. Anyway, it is more evidence that many people have this problem!

[roots (roots)]

very same problem here, i already filed it as bug #295454 which is obviously a dupe now.

[roots (roots)]

worth mentioning, that this delay did not occur with hardy. it can, as already described, be 'solved' by deactivating compiz.

[Rocko (rockorequin)]

I do get this X startup 'freeze' in both Intrepid and Hardy (usually, but not always in Hardy). It always happens in Intrepid, unless I turn off compiz.

During the freeze, xorg is running at 100% CPU (you have to use ssh from another PC to see this since X is almost completely unresponsive during this time - I can move the mouse cursor, but it isn't animated).

I'm using the nvidia driver (173.14.12) to get the 3D compiz effects, in case that's relevant.

Although it's probably not relevant since disabling compiz works around the bug, I also get a libcanberra-login-sound.desktop timeout error message as well as the gnome-wm.desktop timeout and various pulseaudio error messages:

Nov 10 10:04:54 galactica pulseaudio[27134]: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted
Nov 10 09:59:18 galactica x-session-manager[26357]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout
Nov 10 09:59:28 galactica x-session-manager[26357]: WARNING: Application 'libcanberra-login-sound.desktop' failed to register before timeout
Nov 10 10:05:05 galactica pulseaudio[27134]: module-x11-xsmp.c: X11 session manager not running.

[Rocko (rockorequin)]

The delay happens also with the nvidia 177.82 drivers. I don't think it's an nvidia issue, though, because I also get the delay and warning message on a laptop with an ATI Radeon 9600 card.

[Robb Topolski (funchords)]

ATM, I'm able to avoid the delay by going to System - Preferences - Sessions and clearing the checkbox next to Gnome Login Sound.

[Jack Deslippe (jdeslip)]

That does not solve the delay for me. Probably you had a different bug...

[Dalle1985 (mortendalgaard)]

Me neither. Still has the same delay, but now without sound :D

[Robb Topolski (funchords)]

Accepted -- it must be something else that I did. Sorry for the false alarm.

[dvdmeer (dennis-dvdmeer)]

I have the same issue. With intrepid and also with jaunty.

In jaunty I found in daemon.log:

x-session-manager[6014]: WARNING: Unable to find provider 'gnome-wm' of required component 'windowmanager'
gdm[5971]: WARNING: gdm_slave_xioerror_handler: Fatale X-fout - :0 wordt opnieuw gestart
x-session-manager[6320]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout

When I uncheck gnome-wm in my sessions I have a quick login. Rechecking results into slow login again.

[Jack Deslippe (jdeslip)]

Yes getting rid of gnome-wm solves the problem on intrepid... but then compiz is not loaded and I have no window decorations.

As a workaround however, I find that disabling gnome-wm and enabling "fusion-icon" (not "fusion-icon --no-start") - works nicely. This still isn't ideal, though. People are getting a bad first impression of ubuntu.

[Jan Vissers (jan-vissers)]

"People are getting a bad first impression of ubuntu." Yep and that's a shame cause everything else is working like a charm. Can anybody confirm the delay in login behavior using a different driver than nvidia's?

[dvdmeer (dennis-dvdmeer)]

To Jan Vissers,

I'm using a intel driver.

[Id2ndR (id-2ndr)]

 >Can anybody confirm the delay in login behavior using a different
driver than nvidia's?

A friend of mine is using proprietary fglrx driver and got the same trouble.

[Jack Deslippe (jdeslip)]

I was reading the compiz-fusion blog this week: http://smspillaz.wordpress.com/2008/11/15/compiz-fusion-community-news-for-november-15-2008-can-i-haz-plugins/

And one of the bugs that was fixed is:

"Fixed bugs with sessions management when using an executable name other than ‘compiz’ (like ‘compiz.real’)"

[Id2ndR (id2ndr)]

I use the same workaround as jdeslip :
Launch gnome-session-properties, uncheck gnome-wm, and add compiz as a new program.

Compiz isn't the first program launch so AvantWindowNavigator displays a warning because composing isn't available for a very short time until compiz realy start. It works great after that.

[MikeE (mechevar21)]

Just want to confirm this bug in Ubuntu 8.10 using the nvidia proprietary driver with compiz. Setting desktop effects to 'none' and adding 'compiz --replace' and unchecking Window manager (gnome-wm) in the session startup greatly helped the issue.

[Sarath (prosarath)]

@MikeE.. Yes. It does work. However, it is not limited to nvidia. I have a Intel GM965/GL960.

[philinux (philcb)]

I attached the contents of xsession-errors with and without compiz enabled. With it takes 30 seconds from login to useable desktop. Without is about 11 seconds less.

[philinux (philcb)]

With Compiz.

[Dalle1985 (mortendalgaard)]

Okay, so I still have the issue at startup with gnome-wm disabled and compiz set to start in sessions. But only at initial startup. If i do a Ctrl+Alt+Backspace and then login, the system is ready in 8-10 secs. So I've been going through even more logfiles and once again, it looks like I get some errors from compiz. In my kern.log, I find the following entry:

Dec 5 01:36:47 morten-laptop kernel: [ 293.729440] compiz.real[6968]: segfault at 168 ip 08055c7d sp bfb587d0 error 4 in compiz.real[8048000+34000]

I don't really understand what it means, but it looks like an error in Compiz and it just so happens that there is a consistent 22 second delay with no kernel action what-so-ever.

Anyway, the entries in the other logs disappeared after I did the "workaround", but this one persists...

[Srik (maxpower-email)]

Here i've the same problem. These are the errors foundend in my xsession-errors:

x-session-manager[5365]: WARNING: Unable to find provider 'gnome-wm' of required component 'windowmanager'
x-session-manager[5365]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout
(gnome-panel:5577): Gdk-WARNING **: /build/buildd/gtk+2.0-2.14.4/gdk/x11/gdkdrawable-x11.c:878 drawable is not a pixmap or window
x-session-manager[5365]: WARNING: Application 'libcanberra-login-sound.desktop' failed to register before timeout
Failure: Module initalization failed

[Dmik (dmik-for-maillists)]

Seeing the same. In my case, disabling gnome-wm (Window Magager) in Startup Programs and adding a new entry that starts compiz-manager solved the problem. Fast startup and no errors in .xsession-errors.

[David Tombs (dgtombs)]

I've done a bit of research on this, and here's what I've come up with. I'm a newb, so sorry if some of this was obvious.

So, gconf key /desktop/gnome/session/required_components/windowmanager on my system lists gnome-wm. I'm assuming this means gnome-session is going to look for something called gnome-wm to be the window manager. It probably finds this in /usr/share/gnome/autostart/gnome-wm.desktop.

Now, this (IMO pretty ugly) script locates whatever window manager you have selected and runs it. Meanwhile, it seems gnome-session is waiting for some GObject signal "registered" from gnome-wm (or whatever app it launches). Since everything works fine with Metacity, I assume Metacity sends this signal, gnome-session gets it (as evidenced by no warnings in .xsession-errors), and everything's great. In the case of Compiz, I don't think it's sent (or at least not received), so gnome-session waits around for a while for this signal to get sent, but it never happens. Boo.

Why does gnome-session wait for this "registered" deal? I think it's because of the line in gnome-wm.desktop:

X-GNOME-Autostart-Phase=WindowManager

So, I guess all window managers (ie, things loaded during the WindowManager phase) should send this "registered" signal at some point. Compiz doesn't seem to, so I think this is actually a Compiz bug.

Other wiser opinions?

PS: Is it possible to run gnome-session with debug logging on?

[huiii (a00ps)]

i do not know if that error is really of significance...
i have this, too:

gnome-session[15895]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout

i discovered that compiz was making gconf2 angry, pushing cpu up to constant 20% after login and making machine slow.

after all the following did the trick:

i wrote a delay-script for starting up compiz. delayed for 10sec.
since than gconf2 is quiet, behaving nomal.

1)
system>preferences>appearance>visual effects> set to "none"

2)
open terminal and do:

$ sudo gedit /home/where/ever/compizdelay.sh

paste this text and save:

#!/bin/bash
  sleep 10
  compiz --loose-binding --replace &
  emerald --replace &
exit 0

3)
now we need to make it executable:
$ sudo chmod +x /home/where/ever/compizdelay.sh

4)
and then under
system>preferences>sessions> press "add" and browse to where that new script is.

test and reboot and voila, works,,,
if not try to play with the "sleep ..." setting in the script, perhaps on your maschine it needs to sleep longer

[David Tombs (dgtombs)]

All the solutions that add Compiz explicitly to the Session properties are just workarounds for the real issue, which is that Compiz does not do what it is supposed to do (c.f. <http://live.gnome.org/SessionManagement/GnomeSession#head-b6779810556ec641fc2fe351be8a874b82ac9e1f>).

[Antoine Pairet (b-ly)]

@ David Tombs
A bug should be opened in compiz bug tracking system and it should be linked to this bug in Launchpad.

Am I right?

[graysky (da-audiophile)]

 jdeslip - your solution worked GREAT on my Intrepid system. Delay is down to 3-4 sec from 20!

What I did:

System>Preferences>Sessions - unchecked Windows Manager
Added a new one called 'fusion-icon' what simply has the command: fusion-icon

ctrl+alt+backspace to restart gdm and it's fixed :)

[David Tombs (dgtombs)]

@Antoine: Yes, I think you're right. I am, however, on holiday right now and not around my Ubuntu box, and I don't want to report a bug without being on the reproducing machine. I'll do it ASAP, though.

[Paul Kroll (fromubuntu)]

Having the same problem on a new Ubuntu 8.10 64 bit box (nVidia GTX 260, Core I7), jdeslip's line of attack worked for me. In sessions, unchecked Window Manager, added a "compiz-manager" box with "compiz-manager" as the command. Delay gone.

If this going to cause something subtly wrong, later, or is this "not ideal (compiz shouldn't cause the issue in the first place) but workable?"

[Зоран Рилак (zoran.rilak)]

This may well be an issue between Compiz and Nautilus. When Nautilus is restarted (try it yourself: killall nautilus), the same delay can be observed. But this happens only when Nautilus tries to draw the desktop; when Nautilus isn't running, invoking it with 'nautilus --no-desktop' doesn't cause the delay. Maybe it's related to how Compiz handles the root window? I am just guessing.

[Jeffrey Baker (jwbaker)]

Updated the title since this also affects Jaunty. Obviously we are going to want to fix this for Jaunty, right? It's a big regression from Hardy.

Perhaps this is bare speculation, but it seems to me that this bug appeared late in the Intrepid beta cycle, right around the time that people were coming up with (misguided, imho) ways to avoid the PulseAudio startup race condition. Did the delay inserted for PulseAudio to settle down cause this problem?

[Зоран Рилак (zoran.rilak)]

This isn't merely a login issue, either. It happens whenever gnome-session starts nautilus (i.e. the old nautilus process dies/is killed).

[Jeffrey Baker (jwbaker)]

I believe the nautilus delay is due to libcanberra (bug #276072). If you remove libcanberra0 from your system nautilus will start and restart immediately.

[Зоран Рилак (zoran.rilak)]

More info on this. I may have captured the offending call; it seems that compiz.real gets stuck in a call to XGetWindowAttributes. When I run nautilus and X freezes, ltrace -cp`pgrep compiz.real` shows something like this (remaining entries omitted):

$ ltrace -cp`pgrep compiz.real`
% time seconds usecs/call calls function
------ ----------- ----------- --------- --------------------
 67.02 33.785698 3753966 9 XGetWindowAttributes
 28.03 14.128147 220752 64 poll
 . . .

A detailed ltrace log further reveals this (different invocation, times will not match):

$ ltrace -fTp`pgrep compiz.real` &> compiz.ltrace & nautilus -n
 . . . (several calls to XGetWindowAttributes that return in well under 100msec)
XGetWindowAttributes(0x1c17e40, 0x160001d, 0x7fff4a1be190, 1, 0x1c18898) = 1 <35.761979>
 . . . (more calls)

The second parameter to XGetWindowAttributes, Window whose attributes are to be obtained, matches Nautilus desktop window as returned by xpropget: xwininfo: Window id: 0x160001d "x-nautilus-desktop".

I think this is ripe to be forwarded to the compiz clique and let them duke it out with the Xorg guys. :)

[Зоран Рилак (zoran.rilak)]

Also, ps showing cumulative CPU time attributes the sum of this delay to X executable (some 20+ seconds of CPU time while the desktop is nonresponsive). My binary-fu is weak, so I can only guess that it's X who's mishandling the call.

[David Tombs (dgtombs)]

Actually the fix that jdeslip (<https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/291467/comments/18>) referenced is probably the fix to this issue. I will do some of my own testing and see if it works.

[Зоран Рилак (zoran.rilak)]

I hope it does, but I compiled Compiz from source and the executable's name was compiz, yet same thing was happening. But, here's hoping :)

[apostolis (dimitromanolakis)]

I have managed to fix it for me with the following trick. Login is now is close to 1 sec.

*1* Create a file /usr/bin/my-gnome-session with the following contents:

#!/bin/sh
gnome-wm &
/usr/bin/canberra-gtk-play --id="desktop-login" --description="GNOME Login" &
/usr/lib/gnome-session/helpers/at-spi-registryd-wrapper &
/usr/lib/gnome-session/helpers/gnome-keyring-daemon-wrapper &
/usr/lib/gnome-session/helpers/gnome-settings-daemon-helper &
gsynaptics-init --sm-disable &
/usr/lib/vino/vino-server &

And make it executable:
chmod +x /usr/bin/my-gnome-session

Basically this is just all the commands from /usr/share/gnome/autostart. If you have different autostart files then you might want to edit it. Check with grep Exec *.desktop.

*2* Move all the autostart files to a temporary directory:

cd /usr/share/gnome/autostart/
mkdir tmp
mv *.desktop tmp

*3* Create a new file in /usr/share/gnome/autostart/start.desktop:

[Desktop Entry]
Name=Auto Start Scripts
Exec=/usr/bin/my-gnome-session
OnlyShowIn=GNOME;
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization

-------------------------------------------------

That's all. I hope this works for you as a temporary fix.

[Id2ndR (id2ndr)]

I can confirm that previous trick works on jaunty alpha3 (liveUsb). It allows me to load my gnome session in 4 seconds where it needed 18 seconds without the trick : amazing !

[Id2ndR (id2ndr)]

I just made more tests on Jaunty and found this :
- the following launchers works normally :
at-spi-registryd-wrapper.desktop, libcanberra-login-sound.desktop, gnome-keyring-daemon.desktop, gnome-session-splash.desktop, gnome-settings-daemon-helper.desktop, vino-server.desktop
- the Exec directive of following launchers need to be place in /usr/bin/my-gnome-session (from the trick use bellow) to start the session without delays :
gnome-volume-control-applet.desktop, seahorse-daemon.desktop

I'll try to change X-GNOME-Autostart-* directives of these 2 launchers to see if it changes anything

[Id2ndR (id2ndr)]

I found a better way to avoid the delay. Just edit a launcher that cause the delay and comment the line X-GNOME-Autostart-Phase=*. For Intreprid these launchers are gnome-wm.desktop and libcanberra-login-sound.desktop. Enjoy the difference.

[Botond Szász (boteeka)]

@ld2ndR:

Your solution doesn't work for me at all. If I edit those files, my gnome desktop doesn't even start, I only get a black screen, although the login sound does play.

Using Intrepid (up to date) on a Dell Inspiron 1525. I got Intrepid by upgrading Hardy, way back when Intrepid was released.

[cueball (adam-adamoxford)]

I have the same problem and timeout error messages, but disabling compiz or manually switching from gnome-wm doesn't have any effect. Nor do the scripts described above.

[Torbjörn N (kulturhamstern)]

ld2ndR:

Yes, the delay is gone! But I did it like this:

In libcanberra-login-sound.desktop: I changed it to: X-GNOME-Autostart-Phase=Application

Startup sound works fine.

I commented out X-GNOME-Autostart-Phase= in gnome-wm.desktop.

It boots extremely fast, but it seems to be a dirty way to do it, as I get these:

x-session-manager[16626]: WARNING: Unable to find provider 'gnome-wm' of required component 'windowmanager'

** (nm-applet:16787): WARNING **: No connections defined
Failure: Module initalization failed

(gnome-panel:16778): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -4 and height 24

** (nautilus:16779): WARNING **: Can not calculate _NET_NUMBER_OF_DESKTOPS

** (nautilus:16779): WARNING **: Can not calculate _NET_NUMBER_OF_DESKTOPS

** (nautilus:16779): WARNING **: Can not get _NET_WORKAREA

** (nautilus:16779): WARNING **: Can not determine workarea, guessing at layout

[cueball (adam-adamoxford)]

Completely disabling Compiz and gnome-wm has no effect for me - still leaves these errors in the syslog:

Feb 5 10:02:04 Linux ntpdate[8412]: adjust time server 91.189.94.4 offset -0.010046 sec
Feb 5 10:03:02 Linux pulseaudio[8485]: ltdl-bind-now.c: Failed to find original dlopen loader.
Feb 5 10:03:02 Linux pulseaudio[8487]: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted
Feb 5 10:03:02 Linux pulseaudio[8487]: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted
Feb 5 10:03:03 Linux x-session-manager[8302]: WARNING: Could not launch application 'pulseaudio.desktop': Unable to start application: Failed to execute child process "start-pulseaudio-x11" (No such file or directory)
Feb 5 10:03:03 Linux pulseaudio[8487]: module-x11-xsmp.c: X11 session manager not running.
Feb 5 10:03:03 Linux pulseaudio[8487]: module.c: Failed to load module "module-x11-xsmp" (argument: ""): initialization failed.
Feb 5 10:03:11 Linux kernel: [ 105.356933] canberra-gtk-pl[8535]: segfault at 10152f198 ip 00007fd137c13988 sp 00007fff44dec340 error 4 in libc-2.8.90.so[7fd137b98000+169000]

Also tried disabling PulseAudio and the login sound, the errors are different but the delay is the same.

[Id2ndR (id2ndr)]

These errors aren't linked with this bug. You might create an other bug about this, or search there is already one about this.

@Botond Szász,
What happened it you revert the change in the laucher ? It works again ? I'm not sure that the changes in the lauchers are responsible for your black screen. It may be an other bug. You can look the logs of xession, xorg, dmesg to understand what happened.

@cueball,
You might not see the difference since the performance of your hard disk are limitative. You can try to logout/login again with and without the changes to see the difference (since the files are loaded into memory).
Gnome startup is still very slow because it need to load a large amount of files from disk.

I attach a script that automaticaly do the change in the lauchers (should be use with superuser privileges).

[mercutio22 (macabro22)]

weird... after I applied this script the login is slower still!

Is there a way to undo that?

[Id2ndR (id2ndr)]

@macabro22: yes, you just have to inverse the way the sed works in the script : put the '#' character just after the '^' instead of after the second '/' and just run the script again.

[mercutio22 (macabro22)]

yeah, undoing that improved login speed here. Would you like me to post something like system logs?

[Id2ndR (id2ndr)]

@macabro22: you can put your ~/.xsession-errors file

@all:
- the problem is that compiz doesn't register itself to gnome-session and thus gnome-session wait until timeout (10 seconds) => error "WARNING: Application 'gnome-wm.desktop' failed to register before timeout"
- the *workaround* that seems to works for more of us is to disable gnome-wm.destop and start compiz with an other launcher.
  - in fact there is no more window manager => error "WARNING: Unable to find provider 'gnome-wm' of required component 'windowmanager'"
  - ways to disable the windowmanager phase : uncheck it in gnome-session-properties OR comment line X-GNOME-Autostart-Phase in gnome-wm.desktop (in fact that, compiz will start as a normal application)

For those who still have the delay issue.
- Be sure that you don't have any windowmanager in the windowmanager phase : you shouldn't have and timeout error related to it in your ~/.xsession-errors file.
- Look at other possible errors in your ~/.xsession-errors file.

Explanation about the bug :
- look at comment 27 (https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/291467/comments/27)
- the explanation about the timeout : http://live.gnome.org/SessionManagement/GnomeSession#head-fea2c0aa8dc1b74e5a42a644a402f008c43bdf03

[cueball (adam-adamoxford)]

Not sure if this is any use but I'm getting the same 10 second pauses and gnome-wm failing to register on an EeePC I just installed Eeebuntu on. The catch is that it's never had Compiz installed on it, ever.

Removing and reinstalling Compiz and PulseAudio has helped to clear out the errors in the xsession-errors file - the only one I have left in there now is:

Unable to create /home/cueball/.dbus/session-bus
** Message: another SSH agent is running at: /tmp/ssh-lNluPF8259/agent.8259

However syslog still shows this error and pause while starting up the desktop.

Feb 12 11:59:42 Linux ntpdate[8366]: adjust time server 91.189.94.4 offset 0.008782 sec
Feb 12 12:00:01 Linux CRON[8402]: Authentication failure
Feb 12 12:00:24 Linux pulseaudio[8442]: ltdl-bind-now.c: Failed to find original dlopen loader.
Feb 12 12:00:24 Linux pulseaudio[8444]: main.c: setrlimit(RLIMIT_NICE, (31, 31)) failed: Operation not permitted
Feb 12 12:00:24 Linux pulseaudio[8444]: main.c: setrlimit(RLIMIT_RTPRIO, (9, 9)) failed: Operation not permitted

[Nicolò Chieffo (yelo3)]

Sorry, but, can compiz be registered to the session manager?

[Id2ndR (id2ndr)]

Nicolò Chieffo , that's exactly the trouble !

I found a way to fix the bug : apply the path I attached

[mercutio22 (macabro22)]

Ok, here it is.

[Torbjörn N (kulturhamstern)]

I got tired of Ubuntu 8.10, so I thought I should give Arch Linux a chance. So far I'm very impressed with Arch.

Arch's latest Gnome build is 2.24.3. By default the annoying delay's still there, but when I installed compiz and compiz fusion it totally disappeared! Now there is no delay whatsoever at boot.

I run compiz like this: compiz --replace --sm-disable --ignore-desktop-hints ccp

[cueball (adam-adamoxford)]

Still having the same problem but there's one behaviour which seems odd to me. Disabling services in Preferences/Sessions makes the appropriate changes to my /usr/share/gnome/autostart scripts, but every time I boot the default sessions are being written to ~/.config/autostart - including two more references for PulseAudio.

Aside from the fact that the only way I can get Bluetooth drivers to stop loading is to uninstall them, is there a chance that the double entries for starting desktop services are conflicting, and if so, how would one turn them off?

[Id2ndR (id2ndr)]

The bug doesn't exist in Jaunty with latest updates. It only affects Intrepid.

[Charon (markus-lobedann)]

I have the same problem, but hesitate to try the suggested solutions in fear of crippling my system.

Any idea idea if the changes in jaunty will be backported?

[dtrichar (david-pcpromotions)]

SOLVED
The problem: Using compiz as the window manager causes gnome session to timeout after 10 seconds slowing boot time.
Solution: This is a quick hack to /usr/lib/gnome.wm.
Add the following line to gnome.wm

SMID=$DESKTOP_AUTOSTART_ID

above the following code which appears near the bottom

# Now create options OPT1, OPT2 and OPT3 based on the windowmanager used
OPT1=
OPT2=
OPT3=
OPT4=

Reason:
$DESKTOP_AUTOSTART_ID is the way that gnome session passes the DBus ID that is required.
Metacity uses this argument directly (and resets it to ""), Compiz expects it passed with the smClientId parameter (--sm-client-id)
gnome.wm is NOT passed SMID as an argument, I would have assumed that it would do, however gnome.wm is in a transitional state, hopefully this will be fixed in a later release.

Enjoy an 8 second decrease in boot time.

[Krakapuk (krakapuk)]

It works !!! Thanks a lot dtrichar !!!
For me gnome.wm is here : usr/bin/gnome.wm
Thanks again !!

[dtrichar (david-pcpromotions)]

woops a typo in there you are correct it should be /usr/bin/gnome.wm

[Dmik (dmik-for-maillists)]

dtrichar, what distribution are you using? Here, there is no /usr/lib/gnome.wm and no /usr/bin/gnome.wm, but there is /usr/bin/gnome-wm which looks similar to what you posted. However, doing what you propose didn't solve the problem -- the delay is still there.

[dtrichar (david-pcpromotions)]

Ok for those of you tht do not have gnome-wm then here is another way to do the same thing.
The previous fix was for Mint6 Felicia, which is one of the distro's I am playing around with.

The idea is to start compiz-real with the parameters --sm-client-id $DESKTOP_AUTOSTART_ID as well as all the other parameters that are required.
So.....

edit the file /usr/bin/compiz and go to the last line which on my system is :-

${COMPIZ_BIN_PATH}${COMPIZ_NAME} $COMPIZ_OPTIONS "$@" $COMPIZ_PLUGINS || exec $FALLBACKWM $FALLBACKWM_OPTIONS

you need to replace "$@" with --sm-client-id $DESKTOP_AUTOSTART_ID i.e

${COMPIZ_BIN_PATH}${COMPIZ_NAME} $COMPIZ_OPTIONS --sm-client-id $DESKTOP_AUTOSTART_ID $COMPIZ_PLUGINS || exec $FALLBACKWM $FALLBACKWM_OPTIONS

this will ensure that compiz-real gets the correct arguments passed to it.
hope this works for you, if it does/not please reply so that others may know.

[mercutio22 (macabro22)]

WORKED for me =]
The file is at /usr/bin/gnome-wm in Intrepid Ibex.

[Nicolò Chieffo (yelo3)]

Do I need this in Jaunty?

[Jeffrey Baker (jwbaker)]

You shouldn't need this for a clean Jaunty install, but you might need it on an upgraded machine.

[David Tombs (dgtombs)]

Works in Jaunty after dist-upgrade from Intrepid. Can anyone else confirm?

[David Tombs (dgtombs)]

Note that Jaunty uses the now-recommended /desktop/gnome/session/required_components/windowmanager gconf key to launch the window manager instead of an autostart .desktop file. So, anyone who did any mucking around with their gnome-wm.desktop should probably delete it (ON JAUNTY) if the upgrade didn't automatically.

[Jakub Gocławski (jgoclawski)]

I have encountered a similar error on a fresh install of ubuntu Jaunty. After I've installed ATI proprietary drivers (I have Radeon HD4870, so it's well supported, surprisingly; and the driver enables compiz of course) only SOMETIMES my system fails to boot. When I enter my username, password and hit enter I get very slow loading: first there's black screen with a cursor and after a while I get my wallpaper, desktop icons and two empty bars (one is the upper gnome panel and one is the lower gnome panel, both are completely empty, though, just grey). And that's the furthest I can get, it hangs in there. So it's not really a 10 sec slowdown while booting. And also it doesn't happen every time I boot, I have no idea how to explain this.

But in syslog there's one similar thing:
x-session-manager[3476]: WARNING: Application 'gnome-wm.desktop' failed to register before timeout

I enclose you my xsessions-error. I'd be grateful if you could point me where I should begin looking for a solution. This bug is the only thing I could find, which only partially fits my error. Should I try the "fix" mentioned above and check what happens?

[David Tombs (dgtombs)]

As your problem seems to be a localized issue, I would suggest filing a "question" on launchpad and looking for support there. I have a couple ideas (I don't think gnome-wm.desktop should be running at all, actually), but don't want to pollute this bug report with support info.

[Jan Vissers (jan-vissers)]

I'm no longer experiencing the delay in login after upgrading to Jaunty, which is great!

[David Tombs (dgtombs)]

Setting to Fix Released per Jan Visser's seconding.