GNOME Bugzilla – Bug 94754
GSM should notify user of purged processes
Last modified: 2014-12-15 21:08:05 UTC
This problem stems from an issue with regards to OpenOffice.org and StarOffice when due to their long startup time they tend to be "purged" by GSM when it doesn't respond quick enough. Though this is possibly a problem with OOo and SO, it raises a question about whether GSM should just arbitarily kill processes silently. Would it not be better to inform the user that either : a) A process is about to be killed. or b) A process was killed due to lack of acknowledgement. or c) Log purge using syslog or to stderr of GSM. These options could be configurable also, depending on which behaviour the user would prefer. Personally, I think that the default should be (b) above, but when the dialog appears the user could have the option to turn it off there and then... (like Mozilla/Netscape when navigating between secure and non-secure sites).
Darren: yes this is horrible the way its currently done. I'd prefer to just use (a) above personally.
Hmm, now that I think about it I reckon (a) would be better. BTW, I wonder if extending the purge time might be an idea, 3 second seems to be a bit short, especially on older machines...
Import to bugtraq...
FYI - I've made the delay 2 minutes for the 2.2 release 2003-01-06 Mark McLoughlin <mark@skynet.ie> * main.c: make purge_delay and warn_delay 2 minutes by default. A proper strategy for this is being worked out in #94754 and will hopefully be done in 2.4. Should fixes the problem of slow starting up apps being killed off - e.g. OpenOffice.
The problem now is that clients which don't register properly appear to hang the session manager until the purge timeout expires. This is the "logout hangs my desktop" bug --- it's just gnome-session waiting for the purge timeout to expire.
Does gnome-session actually kill purged processes? They just seem to get moved to the purge_drop_list or purge_retain_list. I haven't read the whole code that uses those, but I don't think I've ever seen gnome-session actually killing a client. Shouldn't the behavior be: 1. start a client, install its purge timeout 2. if the client responds in time, go on with life 3. if the client doesn't respond, put it on the purge list 4. when saving the session, don't save the purged clients 5. Later, if a purged client wakes up and does decide to register, put it back on the list for normal clients 6. If the session is saved again, save the clients normally With this, I don't think we need to kill clients at all, or really do anything special. The purge lists would just be for slow/stupid clients. We could make the timeout pretty short, in the order of a few seconds or so. We could even do away with the timeout, perhaps, and just rely on the pending_list. Am I missing something totally obvious? I don't know the SM protocol very well.
The core of the problem isn't whether the client is behaving or not behaving, the problem it seems is that when the user runs gnome-save-session, it saves whatever value the binary is running under program such as: 1,id=117f000002000110266954100000015520001 1,Program=/usr/lib/mozilla-1.4/mozilla-bin 1,CloneCommand=/usr/lib/mozilla-1.4/mozilla-bin -UILocale en-US -contentLocale US 1,RestartCommand=/usr/lib/mozilla-1.4/mozilla-bin -UILocale en-US -contentLocale US The problem is like mozilla is that it is started with a wrapper and therefore when user login again with the command, /usr/lib/mozilla-1.4/mozilla-bin, it can not start up. Hence gnome-session would sit and wait for timeout value which in this case is 120 seconds. Even though we could twist the timeout to something smaller like 60 seconds, the fix is not to save these apps into session file if they do not support "Save current setup". Then problem can be reduced.
Has this behaviour changed? I can't reproduce the long wait with a gnome 2.10 branch build. The "program doesn't support save-yourself" dialog comes up immediately.
Sorry, that was intended for the "hangs my desktop" bug.
this bug is as old as the hills, closing out...