should delete the saved session when unmarking automatic session saving option

Bug #34321 reported by Artem Vakhitov on 2006-03-10
This bug affects 20 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
gnome-session (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

I've found that gnome-session doesn't properly handle turning off automatic session saving. Here's what I done:

1) Turn on auto_save_session via gconf-editor.
2) Leave some program open - say, Gnome Terminal.
3) Reboot. Upon login, Gnome Terminal pops up, which is what is supposed to happen.
4) Turn off auto_save_session via gconf-editor. Close all apps.
5) Reboot. Upon login, gconf-editor opens, which was closed before rebooting, as well as Nautilus, which wasn't launched at all.

To fix this manually, I have to delete ~/.gnome2/session file after turning off automatic session saving.

UPDATE: workaround for jaunty and Karmic 10.04 is: rm -R ~/.config/gnome-session/saved-session

I have the same issue after a forced shutdown due to critical battery: It seems that in this case the session is automatically saved.
When I
1. turn on the option "Automatically save changes to session" in the System -> Sessions dialog
2. close all windows to get a empty desktop
3. log out and log in with the result: the desktop is empty (like expected)
4. turn of the option "Automatically save changes to session"
5. log out and log in with the result: Session manager and nautilus window open automatically after the login

Sebastien Bacher (seb128) wrote :

Thanks for your bug. THat's known upstream:

Changed in gnome-session:
assignee: nobody → desktop-bugs
status: Unconfirmed → Confirmed
Jan (debian-gepro) wrote : nasty bug

I do feel that

1. It is not a minor bug. It's a major anyonance and if not fixed, it will remember itself for the next three years on every logout.

2. It's easy fixable, just disable calling gnome-session-save on state change of the "automatically save changes to session" flag.

Changed in gnome-session:
status: Unconfirmed → Confirmed
shaggy (slimshaggy) wrote :

Like Jan i think its not a minor thing because:
One can enable "automatically save changes to session", but never revert that the same easy way. Its broken, i feel like its underscored with "low importance".

br, Sven

Changed in gnome-session:
status: Confirmed → Needs Info
Daniel Holbach (dholbach) wrote :

 Comment #11 from Vincent Untz (gnome-session developer, points: 24)
2007-01-08 14:37 UTC

I can't reproduce this. Can you still reproduce? (and I see no reason why this
would happen...)

Changed in gnome-session:
status: Confirmed → Needs Info

I still can reproduce the bug on Edgy with latest updates:
To reproduce:
1. Go to System/Sessions/ and select Automatically save changes to session.
2. Open an application (e.g. gedit)
3. log out and log in result: as expected gedit is opened automatically
4. Go to System/Sessions/ and unselect Automatically save changes to session.
5. log out and log in
result: nautilus and the Sessions dialogue and gedit are opened automatically despite of the fact that we deselected "Automatically save changes..."

Best regards

Daniel Holbach (dholbach) wrote :

Forwarded upstream.

Changed in gnome-session:
status: Needs Info → Unconfirmed
Changed in gnome-session:
status: Needs Info → Confirmed
Dylan McCall (dylanmccall) wrote :

This is a bug present apparently since Dapper and still present in Feisty. In my opinion, it is extremely important that it be fixed for Feisty and that it be fixed well.
For a new user just getting used to Ubuntu, this can be a big problem. They could be merely exploring the options for the first time when they decide to try out this session saving and then after turning it on and off end up with their account stuck in this state for eternity.
On my lesser computer (500 mHz), this bug practically doubles the time required to log in, not to mention being very annoying to someone who does not know what file to delete.

I'm sure that somebody will be bothered if their previously saved session is automatically deleted upon them unchecking that box (I see that feature being very useful for public computers!), so my suggestion is that the saved sessions work sort of like starting a new session with an already logged in user (where a choice pops up asking the user if he wishes to start a new session or go back to the old one).
In this case, a box could pop up saying that a session has been saved. A choice could be given for if the user wants to open that saved session, start a new session (and/or delete that saved session... perhaps that option could be a check box).

Also, the option to delete a saved session needs to be present. It's just one little button; it will not hurt anything.

Sebastien Bacher (seb128) wrote :

Are you sure it's still happening with the current version? Vincent said it works fine for him

This bug is still present.
I just installed Ubuntu 7.04 on my intel386 laptop to test if this bug is still present with Gnome 2.18.1.
There is a slight change in the misbehavior, compared to former misbehavior: Now the session
dialog box is not saved anymore at the moment when the the "Automatically save changes to the session" is unselected.
However the session is still saved at that moment.

To produce this bug I did the following:
1. Boot into Gnome
2. Open Nautilus
3. Select "Automatically save changes to the session" in the System/Sessions/Session Options dialog.
4. Log out and log in again
result: as expected Nautilus is opened after login in.
5. Open in addition the Gedit Text-editor.
6. unselect "Automatically save changes to the session" in the System/Sessions/Session Options dialog.
7. Log out and log in again
result: Nautilus and the Text-editor are opened exactly as they have been at the moment at which I have unselected
the "Automatically save changes to the session"
expected results: getting a plain standard desktop after the login (without open gnome-application).

It seems like at the exact moment when unselecting the save-session option the session is saved for a last time and this
session is reestablished after each log-in.
Probably the file ~/.gnome2/session should just be deleted at the moment where the option is unselected.

However, since now there is the option "Save the current session" in the System/Session/Session Options dialog it is easy
to get back to the default desktop. In my case it was sufficient to close Nautilus and Gedit and to click on "Save the current session".
Thanks a lot to the developers to add this very useful option.

Changed in gnome-session:
status: New → Triaged
donal (donalbuckley) wrote :

I have a fresh install of 8.10 and this still seems present. As far I can I tell from the discusion here and at that is. Tomboy Notes keeps starting at Startup, regardless of what i do. . . However in Intrepid there doesn't seem to be a ~/.gnome2/session file.


jgpaiva (jgpaiva) wrote :

Also happens in Jaunty, and there's no ~/.gnome2/session file.

Confirmed in Jaunty, no .gnome2/session here, either.

So is there a fix/workaround?

Indeed - I confirm for Ubuntu 9.04.
Actually this could be considered as a regression since the option "Save the current session" is not present anymore in the System/Preferences/Startup Applications/Options.

For me the following workaround helped:
1. Close all applications
2. Make sure that the option "Automatically remember running applications when logging out" is selected in System/Preferences/Startup Applications/Options
3. Logout and login again.
4. Unselect the option "Automatically remember running applications when logging out".

So the problem is to get an empty session (no applications opened) one has to go through a logout / login cycle with the enabled "Automatically remember running applications when logging out" option.

One way to make this easier would be to put the "Save the current session"-option back to the options.
Or perhaps even better: a "Restore clean desktop"-button. Easy enough to understand even for new users.

Hmmmmm. That didn't work for me. :(

Note the following with respect to the description of my workaround:
When doing the logout in step 3 the session file should be empy (since from step 1 there is no application open and since from step 2 you tell Ubuntu to remember running applications (which means here: no running applications) when logging out).
When you login in step 3 you should then get the last session (without running applications).
If this is not the case then you most probably suffer from a different bug - since until now we did not de-activate the "automatic session saving option".
Now, if you disable (step 4) the saving of running application - from this moment Ubuntu should always use the last saved session (without running applications).

If this is not the case, could you please describe in detail what kind of behaviour you observe? Perhaps you are suffering from a different bug?

Hi Christian

I followed your instructions, and perfectly understand what you are saying, and was surprise when it did not work.

There aren't many more details to give- just to note that every time I log in, Tomboy is present as an icon in the notification area on my panel. There is no .gnome2/sessions file. There is no entry for Tomboy in System > Prefs > Startup Apps either.

The only way I have found to get rid of this behaviour is to uninstall Tomboy.


This behaviour persisted after moving my /home folder to a separate partition and a clean install of Jaunty. Not a massive surprise, there's something lurking in the home folder that we can't find!


Ben (ben2talk) wrote :

This is annoying - it didn't work properly and there seems no way to turn it off. Does anybody know where the session settings are kept? I just want to delete this and not bother about using it. Better just do everything manually B-)

Ben (ben2talk) wrote :


Actually I should have tried to edit first, but I just deleted them. Now I know where they are I might have a go at just setting it up on my next few reboots.

description: updated
summary: - should not write the session when changing automatic session saving
+ should delete the saved session when unmarking automatic session saving
Apteryx (maxco) wrote :

The bug is still present in Ubuntu 9.10. The procedure to delete the saved session is the same as for Jaunty : rm -R ~/.config/gnome-session/saved-session

Kev (ukev) wrote :

I can confirm this bug on jaunty.

rm -R ~/.config/gnome-session/saved-session
works as a workaround but is a no-go for usability and new users.

This bug is more than three years old and still not fixed.

Another point is: The man page of "gnome-session" is wrong:
"When saving a session, gnome-session saves the currently running applications in the $XDG_CONFIG_HOME/gnome-session/saved-session directory.

But the $XDG_CONFIG_HOME is unset. gnome session saves in ~/.config/gnome-session/saved session which is not mentioned in the man page.

Daniel Hollocher (chogydan) wrote :

ok, I think I fixed this, woo!

I'm happy that the fix is only 2.5 lines, 2 lines of which are somewhat trivial. I think the fix integrates well.

I'm not really sure what happened with the original upstream bug report. I suspect that this bug is not the same as the gnome bug. Plus I'm a noob, so I don't really know what to do.

I will try and set this up on my ppa (a fun and profit kind of thing):
This is my first attempt to fix a bug, and my second attempt to package something, so please give me feedback!

I've only coded for jaunty, but it should be very simple to put into karmic. Let me know if you would like that.

Daniel Hollocher (chogydan) wrote :

hmm, I just found a regression with my proposed fix. I block session loading if autosaving session is disabled, but what if there is another way to save the session than through that option? Those would get blocked too.

Now, I don't actually know what those other ways are, but if they exist they will get blocked.

Daniel Hollocher (chogydan) wrote :

I'm attaching the output of debdiff. It show the patch fairly well. Most of the lines are just refactoring. The second to last edit is the one of importance.

Daniel Hollocher (chogydan) wrote :

I'm attaching the output of debdiff. It shows the patch fairly well. Most of the lines are just refactoring. The second to last edit is the one of importance.

Daniel Hollocher (chogydan) wrote :

I uploaded to my ppa gnome-session_2.28.0-0ubuntu4 which is this bug fix plus gnome-session_2.28.0-0ubuntu3 (I'm still figuring out how to version things, sorry). This is for karmic. It built ok in pbuilder, but I'm haven't test on karmic, only jaunty.

Fraser Murray (fraserm) on 2009-10-02
Changed in gnome-session (Ubuntu):
status: Triaged → Confirmed
Changed in gnome-session (Ubuntu):
status: Confirmed → Triaged

Apteryx wrote on 2009-08-24:

>The bug is still present in Ubuntu 9.10. The procedure to delete the saved session is the same as for Jaunty : rm -R ~/.config/gnome-session/saved-session

I thought this was a brilliant solution which finally could help me solve this issue with Tomboy. And probably it is, on others' systems. But unfortunately, it failed like other solutions listed here and in other fora (uninstalling Tomboy included). Then I bumped into this page - - which let me understood why the hell Tomboy was so stubborn: it was the Deskbar-applet which I added to my panel a couple of weeks ago to fire up Tomboy at login. Once disabled the relevant option in the applet preferences, it finally stopped. This worked in my case, so it might not apply to yours. However, I wanted to share just in case someone could find it helpful.

Vish (vish) wrote :

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

For further information about papercuts criteria, please read

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

Changed in hundredpapercuts:
status: New → Invalid
SoulDr0p (souldr0p) wrote :

Thanks for the fix in #29 there, I was wondering what was going on. So, something is looking for that saved session if it exists, and if so, to use it...instead of checking the setting to see if it's wanted. If I knew how to break down the code myself, I'd do it.

description: updated

Looks like this has gotten worse in Lucid. There is now a fat button to click in gnome-session-properties to store the session (see attached screenshot), but no way to get rid of that stored session. It spawns every time you log in (i tried it two times, then the rm -R workaround) even when "Automatically remember ..." is NOT checked.

Daniel Hollocher (chogydan) wrote :

I think that button showed up in Karmic. I personally found it pretty confusing. Of course it is a simple button that just calls the save_session function, but it doesn't fit into any sort of normal user workflow, as far as I can see. I agree that this went from bad to worse, and I took the appearance of that button (along with the lack of upstream response) as a sign that this bug will not be fixed any time soon.

FWIW, I would still go my route for a solution; it is basically the same as the workaround. One exception, I would also get rid of the button too.

Changed in gnome-session:
importance: Unknown → Medium
Dimitrios Ntoulas (ntoulasd) wrote :

You can add a Delete option under Save ..

Delete option must do :
rm -R ~/.config/gnome-session/saved-session

RJBradlow (rjbradlow) wrote :

For those where the suggested solution of:
<quote> rm -R ~/.config/gnome-session/saved-session </quote>
doesn't work, check your ~/.config/autostart directory where you will find the appropriately named files that continue to annoy you.
Edit or Delete them.
<b>Editing the files</b>
In my experience; right clicking the files offers no 'Open With' option so to edit them use the command line or drag the files onto an open instance of gedit and change (if 'true') the following filed to false as shown below.


RJBradlow (rjbradlow) wrote :

My last comment edit:
"and change (if 'true') the following filed"
Should be:
"and change (if 'true') the following field"

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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