Delayed Login
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
compiz (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bug Description
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(
Oct 30 23:48:44 m1530 gnome-session[
A fix is to go to System-
Error has been confirmed with others: http://
Details:
Fresh install of Ubuntu 8.10
Video card is 8600m gt using proprietary 177 NVIDIA drivers
Sebastien Bacher (seb128) wrote : | #1 |
Sarath (prosarath) wrote : | #2 |
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) wrote : | #3 |
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.
Changed in compiz: | |
status: | New → Confirmed |
Jack Deslippe (jdeslip) wrote : | #4 |
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) wrote : | #5 |
very same problem here, i already filed it as bug #295454 which is obviously a dupe now.
roots (roots) wrote : | #6 |
worth mentioning, that this delay did not occur with hardy. it can, as already described, be 'solved' by deactivating compiz.
Rocko (rockorequin) wrote : | #7 |
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-
Nov 10 10:04:54 galactica pulseaudio[27134]: main.c: setrlimit(
Nov 10 09:59:18 galactica x-session-
Nov 10 09:59:28 galactica x-session-
Nov 10 10:05:05 galactica pulseaudio[27134]: module-x11-xsmp.c: X11 session manager not running.
Rocko (rockorequin) wrote : | #8 |
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) wrote : | #9 |
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) wrote : | #10 |
That does not solve the delay for me. Probably you had a different bug...
Dalle1985 (mortendalgaard) wrote : | #11 |
Me neither. Still has the same delay, but now without sound :D
Robb Topolski (funchords) wrote : | #12 |
Accepted -- it must be something else that I did. Sorry for the false alarm.
dvdmeer (dennis-dvdmeer) wrote : | #13 |
I have the same issue. With intrepid and also with jaunty.
In jaunty I found in daemon.log:
x-session-
gdm[5971]: WARNING: gdm_slave_
x-session-
When I uncheck gnome-wm in my sessions I have a quick login. Rechecking results into slow login again.
Jack Deslippe (jdeslip) wrote : | #14 |
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) wrote : | #15 |
"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) wrote : | #16 |
To Jan Vissers,
I'm using a intel driver.
Id2ndR (id-2ndr) wrote : Re: [Bug 291467] Re: Delayed Intrepid Login | #17 |
>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) wrote : Re: Delayed Intrepid Login | #18 |
I was reading the compiz-fusion blog this week: http://
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) wrote : | #19 |
I use the same workaround as jdeslip :
Launch gnome-session-
Compiz isn't the first program launch so AvantWindowNavi
MikeE (mechevar21) wrote : | #20 |
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) wrote : | #21 |
@MikeE.. Yes. It does work. However, it is not limited to nvidia. I have a Intel GM965/GL960.
philinux (philcb) wrote : | #22 |
- xsession-errors Without Compiz Edit (1.8 KiB, text/plain)
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) wrote : | #23 |
Dalle1985 (mortendalgaard) wrote : | #24 |
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.
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) wrote : | #25 |
Here i've the same problem. These are the errors foundend in my xsession-errors:
x-session-
x-session-
(gnome-panel:5577): Gdk-WARNING **: /build/
x-session-
Failure: Module initalization failed
Dmik (dmik-for-maillists) wrote : | #26 |
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) wrote : | #27 |
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/
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-
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) wrote : | #28 |
i do not know if that error is really of significance...
i have this, too:
gnome-session[
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>
2)
open terminal and do:
$ sudo gedit /home/where/
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/
4)
and then under
system>
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) wrote : | #29 |
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://
Antoine Pairet (b-ly) wrote : | #30 |
@ 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) wrote : | #31 |
jdeslip - your solution worked GREAT on my Intrepid system. Delay is down to 3-4 sec from 20!
What I did:
System>
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) wrote : | #32 |
@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) wrote : | #33 |
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) wrote : | #34 |
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) wrote : | #37 |
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) wrote : | #38 |
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) wrote : | #39 |
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) wrote : | #40 |
More info on this. I may have captured the offending call; it seems that compiz.real gets stuck in a call to XGetWindowAttri
$ ltrace -cp`pgrep compiz.real`
% time seconds usecs/call calls function
------ ----------- ----------- --------- -------
67.02 33.785698 3753966 9 XGetWindowAttri
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 XGetWindowAttri
XGetWindowAttri
. . . (more calls)
The second parameter to XGetWindowAttri
I think this is ripe to be forwarded to the compiz clique and let them duke it out with the Xorg guys. :)
Зоран Рилак (zoran.rilak) wrote : | #41 |
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) wrote : | #42 |
Actually the fix that jdeslip (<https:/
Changed in compiz: | |
assignee: | nobody → cyan-spam |
status: | Confirmed → In Progress |
Зоран Рилак (zoran.rilak) wrote : | #43 |
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) wrote : | #44 |
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/
#!/bin/sh
gnome-wm &
/usr/bin/
/usr/lib/
/usr/lib/
/usr/lib/
gsynaptics-init --sm-disable &
/usr/lib/
And make it executable:
chmod +x /usr/bin/
Basically this is just all the commands from /usr/share/
*2* Move all the autostart files to a temporary directory:
cd /usr/share/
mkdir tmp
mv *.desktop tmp
*3* Create a new file in /usr/share/
[Desktop Entry]
Name=Auto Start Scripts
Exec=/usr/
OnlyShowIn=GNOME;
Terminal=false
Type=Application
X-GNOME-
-------
That's all. I hope this works for you as a temporary fix.
Id2ndR (id2ndr) wrote : | #45 |
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) wrote : | #46 |
I just made more tests on Jaunty and found this :
- the following launchers works normally :
at-spi-
- the Exec directive of following launchers need to be place in /usr/bin/
gnome-volume-
I'll try to change X-GNOME-Autostart-* directives of these 2 launchers to see if it changes anything
Id2ndR (id2ndr) wrote : | #47 |
I found a better way to avoid the delay. Just edit a launcher that cause the delay and comment the line X-GNOME-
Botond Szász (boteeka) wrote : | #48 |
@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) wrote : | #49 |
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) wrote : | #50 |
ld2ndR:
Yes, the delay is gone! But I did it like this:
In libcanberra-
Startup sound works fine.
I commented out X-GNOME-
It boots extremely fast, but it seems to be a dirty way to do it, as I get these:
x-session-
** (nm-applet:16787): WARNING **: No connections defined
Failure: Module initalization failed
(gnome-
** (nautilus:16779): WARNING **: Can not calculate _NET_NUMBER_
** (nautilus:16779): WARNING **: Can not calculate _NET_NUMBER_
** (nautilus:16779): WARNING **: Can not get _NET_WORKAREA
** (nautilus:16779): WARNING **: Can not determine workarea, guessing at layout
cueball (adam-adamoxford) wrote : | #51 |
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(
Feb 5 10:03:02 Linux pulseaudio[8487]: main.c: setrlimit(
Feb 5 10:03:03 Linux x-session-
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-
Also tried disabling PulseAudio and the login sound, the errors are different but the delay is the same.
Id2ndR (id2ndr) wrote : | #52 |
- fix_gnome_delay.sh Edit (257 bytes, text/x-sh)
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) wrote : | #53 |
weird... after I applied this script the login is slower still!
Is there a way to undo that?
Id2ndR (id2ndr) wrote : | #54 |
@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) wrote : | #55 |
yeah, undoing that improved login speed here. Would you like me to post something like system logs?
Id2ndR (id2ndr) wrote : | #56 |
@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-
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:/
- the explanation about the timeout : http://
cueball (adam-adamoxford) wrote : | #57 |
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/
** Message: another SSH agent is running at: /tmp/ssh-
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(
Feb 12 12:00:24 Linux pulseaudio[8444]: main.c: setrlimit(
Nicolò Chieffo (yelo3) wrote : Re: [Bug 291467] Re: Delayed Login | #58 |
Sorry, but, can compiz be registered to the session manager?
Id2ndR (id2ndr) wrote : | #59 |
- gnome-wm.diff Edit (286 bytes, text/plain)
Nicolò Chieffo , that's exactly the trouble !
I found a way to fix the bug : apply the path I attached
mercutio22 (macabro22) wrote : | #60 |
Torbjörn N (kulturhamstern) wrote : | #61 |
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-
cueball (adam-adamoxford) wrote : | #62 |
Still having the same problem but there's one behaviour which seems odd to me. Disabling services in Preferences/
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) wrote : | #63 |
The bug doesn't exist in Jaunty with latest updates. It only affects Intrepid.
Charon (markus-lobedann) wrote : | #64 |
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) wrote : | #65 |
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_
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_
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) wrote : | #66 |
It works !!! Thanks a lot dtrichar !!!
For me gnome.wm is here : usr/bin/gnome.wm
Thanks again !!
dtrichar (david-pcpromotions) wrote : | #67 |
woops a typo in there you are correct it should be /usr/bin/gnome.wm
Dmik (dmik-for-maillists) wrote : | #68 |
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) wrote : | #69 |
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_
So.....
edit the file /usr/bin/compiz and go to the last line which on my system is :-
${COMPIZ_
you need to replace "$@" with --sm-client-id $DESKTOP_
${COMPIZ_
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) wrote : | #70 |
WORKED for me =]
The file is at /usr/bin/gnome-wm in Intrepid Ibex.
Nicolò Chieffo (yelo3) wrote : | #71 |
Do I need this in Jaunty?
Jeffrey Baker (jwbaker) wrote : | #72 |
You shouldn't need this for a clean Jaunty install, but you might need it on an upgraded machine.
David Tombs (dgtombs) wrote : | #73 |
Works in Jaunty after dist-upgrade from Intrepid. Can anyone else confirm?
David Tombs (dgtombs) wrote : | #74 |
Note that Jaunty uses the now-recommended /desktop/
Jakub Gocławski (jgoclawski) wrote : | #75 |
- xsession-errors Edit (4.2 KiB, text/plain)
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-
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) wrote : | #76 |
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) wrote : | #77 |
I'm no longer experiencing the delay in login after upgrading to Jaunty, which is great!
David Tombs (dgtombs) wrote : | #79 |
Setting to Fix Released per Jan Visser's seconding.
Changed in compiz (Ubuntu): | |
assignee: | David Tombs (cyan-spam) → nobody |
status: | In Progress → Fix Released |
the issue is likely a compiz one if using no effects workaround the bug