Comment 73 for bug 1446865

Revision history for this message
In , Thomas-luebking (thomas-luebking) wrote :

(In reply to David Lang from comment #70)
> only if you only do this by looking at what's running at the time you
> shutdown.

Nothing is tracked or something.
There's a session protocol and clients can support it and call for a restart or not.
They can notably define *how* they want to be restarted (commandline).

Even if it was not: restarting only clients that were launched through a specific interface is a pretty much instant fail. Should we care about kickoff? krunner? plasma panels? what about 3rd party dockers? Should we estrablish a protocol that each and every runner/docker/whatever needs to support? Let alone the mess that this would cause for less integrated environments as well as the most obvious question, *why* to discriminate processes that were started from eg. konsole. (Eg. I *very* often launch kwrite instances from konsole)

> But if you are actually trying to restart all apps
As pointed out: it's configurable and you're free to start with a blank session or an explicitly stored one.

> then you are failing miserably.
Thank you - But maybe better read into the topic next time.

> I routinely have many apps running in terminal windows that don't
> get restarted, as well as a few GUI apps (almost none KDE/Gnome apps) that
> don't get restarted.
As mentioned, clients either support this (dead old) protocol or not. Qt5 is apparently buggy itr. and atm.

> Other apps that get restarted are missing the context
> (what files they had open, etc)
The apps get a signal "the session is gonna end, save your stuff" and a signal "session restarted, your last id was 123456" - what they do with that is their thing and not job of the session manager.

========== OFF TOPIC ============================================

> swap is horrible to use
swap is slow, yes, but unless some process runs wild, the logged out user will quickly get swapped out in favor of the active users processes (notably when stopping processes)
Since the user isn't logged in, he doesn't care.

> I've actually had a machine with 128G of RAM that only had 120G of disk. My VMs for work
> typically have 40G of disk or so, even if they have 32+G of RAM

Sorry, but personal design decisions do not form a concept.
Naturally a multiuser (for multiseat you obviously need tons of physical RAM) system would be designed different (hard quotas and sufficient swap space to protect user processes agains other users processes causing OOM)