gnome-session properties hangs, when writing to files it doesn't have permisions to modify

Bug #31402 reported by Andrzej Mendel-Nykorowycz
90
Affects Status Importance Assigned to Milestone
gnome-session
Fix Released
Medium
gnome-session (Ubuntu)
Fix Released
Medium
Ubuntu Desktop Bugs

Bug Description

This is actualy a two part problem.
Firstly, gnome-session-properties hangs when trying to delete program defined in /usr/share/autostart from startup program list, because ordinary users don't have write pemission on these files. strace gives thousands of these lines:
unlink("/usr/share/autostart/gnome-power-manager.desktop") = -1 EACCES (Permission denied)
While it should show an error message and let the user carry on.

Another problem is that user can't disable these startup programs withous becoming root and moving .desktop files out of the way. I had to cope with kicker starting alongside gnome-panel for several days and it was really annoying.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. That works fine for me on gnome-volume-manager by example. What version of gnome-session do you use? Where do you click exactly?

Revision history for this message
Sebastien Bacher (seb128) wrote :

The KDE autostart issue is bug #30849 which is a different topic

Changed in gnome-session:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Revision history for this message
Andrzej Mendel-Nykorowycz (kelner) wrote :

gnome-session 2.13.91-0ubuntu1, but the problem was also aparent in 2.13.90 and earlier 2.13.x releases.
I click:
Sys => Preferences => Session => Startup Programs => any of progs listed there => Delete
And it hangs. It woes in same way when I launch it from terminal, gnome-run, whatever.
I can't delete any of the programs from /usr/share/autostart, neither can I delete gnome-volume-manager.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Enough duplicates to confirm

Changed in gnome-session:
status: Needs Info → Confirmed
Revision history for this message
Joshua Lock (incandescant) wrote :

I think this is related so I am commenting on this bug rather than starting a new one.
I cannot delete any of the startup items from the gnome-session-properties GUI.
Even if the items where added by me rather than being default items added during install.

When i try to delete any item from gnome-session-properties the UI hangs.
Also when adding my own startup program I get errors about not being able to write to the already exisiting .desktop files in /usr/share/autostart even though I have not modified those items.

I'm running up to date dapper on an iBook G4.

Revision history for this message
McQueen (camplear) wrote :

The only method I have to delete any of the existing items from the gnome-session-properties GUI is to do so manually in /usr/share/autostart. Otherwise, the window completely freezes if 'delete' is selected. I don't understand how it could only be a permission problem when I can add them easily, but just can't remove them in a likewise fashion.

Revision history for this message
Andrzej Mendel-Nykorowycz (kelner) wrote :

This is a bit more complicated, gnome-session-properties is quite broken currently and I'll try to explain it now.
The first thing is that when gnome-session-properties can't delete appropriate .desktop file it hangs and needs to be killed by hand. This is very bad, GUI should pop a nice message up and let the user carry on as. That's what I ment when I filled this bug.

Let's suppose it does work this way. Unfortunately Joe Average still won't be able to stop programs declared in /usr/share/autostart from launching at login. There should be some way to disable them and make gnome-session ignore them. We can't exept each and every e.g. KDE package maintaner will remember to declare "OnlyShowIn=KDE;" and vice versa. That was the second problem

I have also found out that gnome-session-properties doesn't actually write stuff to ~/.local/share/autostart/*.desktop as it should do when user adds programs to his startup. It does show on startup programs list, but dissapears after logout and subsequent login. Trying to delete it hangs g-s-p and strace gives following message:
unlink("/home/kelner/.local/share/autostart/ps.desktop") = -1 ENOENT (No such file or directory)

so there are 3 related, but separate bugs:
I: gnome-session-properties hangs when it fails to delete .desktop file
II: can't disable startup programs listed in /usr/share/autostart
III: gnome-session doesn't create .desktop files for user-defined startup apps.
II and III both lead to I, but are different issues and IMHO should be treated as such.
Hope this clarified thing a bit. Guess it confused you a lot more ;)

Revision history for this message
Sebastien Bacher (seb128) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Andrzej, that's one bug you describe, it's just trying to use the wrong directory

Revision history for this message
Sebastien Bacher (seb128) wrote :

That's fixed upstream

Changed in gnome-session:
status: Unconfirmed → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

fixed upstream

Changed in gnome-session:
status: Confirmed → Fix Committed
Revision history for this message
Sebastien Bacher (seb128) wrote :

That upload fixes the issue:

 gnome-session (2.14.0-0ubuntu1) dapper; urgency=low
 .
   * New upstream version:
     Session Manager
     - Support old directory for autostart .desktop files
     - Fix leak
     - Fix enabling/disabling of autostart services (Ubuntu: #31402)
     Misc
     - New splash screen
   * debian/patches/01_fix_autostart_path.patch:
     - fixed with the new version
   * debian/patches/01_fix_autostart_edition.patch:
     - patch from Vincent Untz, fix the autostart edition

Now removing doesn't hang but doesn't do anything neither for non-user .desktop, that's an another issue. The hang is fixed and the enable toggle button works fine too so it makes possible to desactivate a .desktop for the user which fixes the issue. I'm closing the bug, feel free to reopen if you disagree

Changed in gnome-session:
status: Fix Committed → Fix Released
Changed in gnome-session:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.