After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 94754 - GSM should notify user of purged processes
GSM should notify user of purged processes
Status: RESOLVED OBSOLETE
Product: gnome-session
Classification: Core
Component: gnome-session
2.0.x
Other All
: High major
: 2.2.x
Assigned To: Session Maintainers
Session Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-10-03 10:48 UTC by Darren Kenny
Modified: 2014-12-15 21:08 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Darren Kenny 2002-10-03 10:48:39 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).
Comment 1 Mark McLoughlin 2002-10-03 23:54:23 UTC
Darren: yes this is horrible the way its currently done. I'd prefer to
just use (a) above personally.
Comment 2 Darren Kenny 2002-10-04 10:10:38 UTC
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...

Comment 3 Darren Kenny 2002-11-07 09:56:18 UTC
Import to bugtraq...
Comment 4 Mark McLoughlin 2003-01-06 06:32:19 UTC
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.

Comment 5 Federico Mena Quintero 2004-09-02 02:59:41 UTC
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.
Comment 6 Federico Mena Quintero 2004-09-10 20:10:38 UTC
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.
Comment 7 Ghee Teo 2004-12-10 12:44:45 UTC
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.
Comment 8 Hans Petter Jansson 2005-05-25 22:30:29 UTC
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.
Comment 9 Hans Petter Jansson 2005-05-25 22:31:42 UTC
Sorry, that was intended for the "hangs my desktop" bug.
Comment 10 Ray Strode [halfline] 2014-12-15 21:08:05 UTC
this bug is as old as the hills, closing out...