session files not pruned automatically

[cnzhx]

Good morning,

I like using save sessions so that the opened directories in Dolphin, opened files in Okular, etc. can be opened automatically the next time I boot the
machine and log in to my account. So I enter “Configure Desktop” (systemsettings5)->Startup and Shutdown->Session Management, and set the option “Restore previous session”.

I noticed that there are too many saved session files in ~/.config/session directory. Among them, only the latest ones matter to the system, I think. It seems not normal to have tons of such session files kept.

So I searched and found little information on this. May I ask whether those files are kept intently or there is a bug?

BTW, my environment is,

openSUSE Tumbleweed: 20170510
KDE Plasma: 5.9.5
Qt: 5.7.1
KDE Frameworks: 5.33.0
Kernel: 4.10.13-1-default

Regards,
CnZhx

[wolfi323]

@cnzhx

I noticed that there are too many saved session files in ~/.config/session directory. Among them, only the latest ones matter to the system, I think. It seems not normal to have tons of such session files kept.

Strictly speaking, none of them matter “to the system”.

A short overview how this works:

• the session manager signals the running applications that the session is about to end
• the applications can store their state then, and tell the session manager how they want to be started on next login (so that they can find their saved state e.g., for KDE applications this looks something like “konsole --session 10c26d6967000148847592200000111300010_1493206720_37234”)
• the session manager then stores this information in ~/.config/ksmserverrc (in the case of Plasma5), reads that at login and carries out the necessary operations
• On login, the applications are then started as desired, and the applications read in their state file (if applicable).

So, it’s the applications (or the toolkit they use, Qt in the case of the mentioned applications) that create (or read) those files. (and ~/.config/session is rather specific to Qt5/KF5 applications).

I’m not an expert on all the details, but as far as I know, the applications can also tell the session manager what to do to discard their state after they have been restarted on login. The ~/.config/ksmserverrc does have lines like this here:

discardCommand4$e]=rm,$HOME/.config/session/konsole_10c26d6967000148847592200000111300010_1493206720_37234

If the session files stay, I assume that can be because of two reasons:

• Either the application/toolkit doesn’t specify that “discardCommand” or it specifies it wrongly
• Or ksmserver doesn’t actually carry out those discardCommands for some reason

It doesn’t seem to happen in general though, my current ~/.config/sessions (from a user account I’m not logged in currently) looks like this:

test@amiga:~> ls ~/.config/session/
kmix_10c26d6967000149320535800000264590009_1493206720_37416
konqueror_10c26d6967000149319389100000019160015_1493206720_107374
konqueror_10c26d6967000149319389600000019160016_1493204967_161953
konqueror_10c26d6967000149320542000000264590012_1493205579_238051
konqueror_10c26d6967000149320562300000273360011_1493206183_369741
konqueror_10c26d6967000149320623400000285170012_1493206366_851669
konqueror_10c26d6967000149320641600000293950012_1493206561_203964
konqueror_10c26d6967000149320660000000302590012_1493206720_39043
konsole_10c26d6967000148847592200000111300010_1493206223_913040
konsole_10c26d6967000148847592200000111300010_1493206590_676811
konsole_10c26d6967000148847592200000111300010_1493206720_37234
kwin_10c26d6967000149182596200000019260006_1493206720_623980
test@amiga:~>

Obviously, at least kwin’s and kmix’s state files did get cleaned up properly, but not konqueror’s and konsole’s (or at least not every time) even though I do currently also have discardCommands for konsole and konqueror in the ksmserverrc (so it’s not that they don’t specify that at all)…

Might also indicate some timing issue or something like that. Or maybe it happens if the application fails to start for some reason, or crashes at logout during/after writing its state.

In the end, it probably is a “bug” somewhere, but it’s not really straight-forward to tell where (and probably not easy to investigate either, because it is a bit “random”).

All I can say is that I have seen that (sometimes, not always) since years already, in KDE4 times and maybe even KDE3.
I’m currently logged in to a KDE4 session with only KDE4 applications having been restored, and my ~/.kde4/share/config/session/ (that’s the location used by KDE4 applications) looks like this:

wolfi@amiga:~/Desktop> ls ~/.kde4/share/config/session/
kget_10c26d6967000148302799600000019010110_1494797782_630226
kget_10c26d6967000148302799600000019010110_1494974558_333326
kgpg_10c26d6967000148232030300000018700010_1494797782_629924
kgpg_10c26d6967000148232030300000018700010_1494974558_982460
kmix_10c26d6967000146755580400000031280011_1494797782_629800
kmix_10c26d6967000146755580400000031280011_1494974557_888828
konqueror_10c26d6967000149477658700000019770040_1494797782_635741
konqueror_10c26d6967000149495057300000018650120_1494974559_431187
konsole_10c26d6967000149124314000000018100062_1494797782_630105
konsole_10c26d6967000149124314000000018100062_1494974557_755993
kwin_10c26d6967000147749630000000034870000_1494797797_336697
kwin_10c26d6967000147749630000000034870000_1494974607_830377
wolfi@amiga:~/Desktop>

(IIRC I did delete the whole folder just a week ago, those files are dated 14. and 17. May, the latter are from the previous session and the corresponding discardCommands are still in ~/.kde4/share/config/ksmserverrc, this may indicate that this cleaning of the previous session is actually done on logout of the new session not at login)

So it’s not exactly a new problem.

Other than the (small) disk space it takes, there shouldn’t be issues because of that though. The stale files are just not used by anything.

[cnzhx]

Hi @wolfi323,

Thanks for the technical explanation. This session management is much more complex than I thought.

I do have discardCommands in ~/.config/ksmserverrc and they looks no problem (format and parameters). So, no idea why does ksmserver not actually carry out those discardCommands.

And it’s a relief for me to know that I am not the only one has this problem. It’s true that the storage is not a big deal. I just need to manually empty them now and then to prevent enormous number of files keeping in the folder.

[nrickert]

@cnzhx

I like using save sessions so that the opened directories in Dolphin, opened files in Okular, etc. can be opened automatically the next time I boot the
machine and log in to my account. So I enter “Configure Desktop” (systemsettings5)->Startup and Shutdown->Session Management, and set the option “Restore previous session”.

I set that to “restore manually saved session”.

Then I setup my session exactly the way that I like it, and click “save session” (in the “Power / Session” sub-menu).

The problems that you are describing are exactly why I prefer to manually save the session as I want it.

[cnzhx]

@nrickert

I set that to “restore manually saved session”.

Then I setup my session exactly the way that I like it, and click “save session” (in the “Power / Session” sub-menu).

The problems that you are describing are exactly why I prefer to manually save the session as I want it.

Thanks @nrickert for your suggestion.

The manually saved session seems always having the same configuration. But I want the “saved” applications to open the save directories/files as those opened when I log out. To achieve what I want, I need to manually save the session every time I log out. That’s annoying too. So I prefer to delete the obsolete session files occasionally, like before every time I upgrade the system by using a bash script to combining them together like this,

#!/bin/bash -e
find ~/.config/session -mtime +2 -type f -delete
sudo zypper dist-upgrade  --no-allow-vendor-change
# other stuff

Of course I need to make sure this file is safe.

[nrickert]

@cnzhx

But I want the “saved” applications to open the save directories/files as those opened when I log out.

Your choice, of course.

As for your script – suppose you take a 3-day vacation. When you return and run that script, it deletes all session files.

I suppose that’s not too serious, since you probably run the script after login. So you have your current session, and that will be saved on logout. But maybe you should use something a tad longer than 2 days.

[cnzhx]

@nrickert

Your choice, of course.

As for your script – suppose you take a 3-day vacation. When you return and run that script, it deletes all session files.

I suppose that’s not too serious, since you probably run the script after login. So you have your current session, and that will be saved on logout. But maybe you should use something a tad longer than 2 days.

Yes, you’re right. I also thought about that situation but couldn’t think of a robust way to avoid it. Anyway, the session files are not so important that I have to invest too much on it. It’s just for saving my time to open those again and again. So I leave the rest to luck

[the_wumpus]

Hi all,

@cnzhx

I noticed that there are too many saved session files in ~/.config/session directory. Among them, only the latest ones matter to the system, I think. It seems not normal to have tons of such session files kept.

Although this thread is a few yeas old, this seems to be still an issue. I just stumbled over this directory, it contains >3100 files with a total of 13M, with some files dating back to 2017. While this seems not to be an issue with today’s hard disks (indeed matches well the size of my very 1st hdd…), I think this is a rather annoying thing. I will clean it now, but keep an eye on it… :.

Regards,
the_wumpus