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 779306 - disconnects xsmp clients immediately after sending SmsDie
disconnects xsmp clients immediately after sending SmsDie
Status: RESOLVED OBSOLETE
Product: gnome-session
Classification: Core
Component: gnome-session
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-02-27 12:57 UTC by Oliver Henshaw
Modified: 2021-06-14 18:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Oliver Henshaw 2017-02-27 12:57:26 UTC
Firefox xsmp session restore on some gnome-session desktops does not appear to work. Investigation indicates that the problem lies with gnome-session.

See https://bugzilla.mozilla.org/show_bug.cgi?id=557601#c17 onwards and https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1662281 for the original report. I have also reproduced with on Fedora 25 workstation:

gnome-session-bin/yakkety,now 3.20.2-1ubuntu7 amd64 [installed,automatic]
gnome-session-3.22.2-3.fc25.x86_64

My xsmp test client dispatches a SmcCloseConnection() call on the glib2 main loop 3 seconds after getting a "die" message. When I run it under gnome-session and logout I find that I get an ICE i/o error a few tens of ms after the Die message (as the server has closed the connection). But, according to https://www.x.org/releases/X11R7.7/doc/libSM/SMlib.html#Sending_a_Die_Message the server should wait for clients to close the connection.



This might be a result of the fix for bug #750508 - attachment #323125 [details] seems to go too far in not waiting at all before ending the phase. As mentioned earlier, the session manager should wait for clients to close the connection after sending a "die" message - this lets them e.g. complete their teardown and get to a state where they're safe to crash or be killed.

Firefox with many tabs and windows open can take a long time to close, and I'm fairly sure app teardown can much longer than normal when the machine is even lightly swapped (with a hdd). I appreciate that a timeout of 90 seconds may be too long, but zero seconds it definitely too short. How about 30 seconds or so? I know that ksmserver, for example, waits 10 seconds for clients to quit - but that's probably too short a time for the mildy pathological cases I mentioned earlier (heavily loaded firefox sessions or sessions having to read back 50-100MB of swap from a HDD).
Comment 1 André Klapper 2021-06-14 18:20:57 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of gnome-session, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-session/-/issues/

Thank you for your understanding and your help.