server does not run cleanups on SIGINT from a console

[totaam]

Issue migrated from trac ticket # 626

component: platforms | priority: critical | resolution: fixed

2014-08-05 06:02:04: totaam created the issue

---

Calling xpra stop (or even xpra exit) cause the cleanups to run, but when sending a SIGINT (ie: control-C) they don't...

[totaam]

2014-08-05 10:03:56: totaam changed status from new to assigned

[totaam]

2014-08-05 10:03:56: totaam changed owner from antoine to totaam

[totaam]

2014-08-05 10:03:56: totaam changed title from centos7 server does not run cleanups on SIGINT to server does not run cleanups on SIGINT from a console

[totaam]

2014-08-05 10:03:56: totaam commented

---

Edited title: this only occurs when running from a console, not from an xterm!??? (also affects Fedora 20 and probably others too)

[totaam]

2014-08-05 10:43:19: totaam changed status from assigned to closed

[totaam]

2014-08-05 10:43:19: totaam changed resolution from ** to worksforme

[totaam]

2014-08-05 10:43:19: totaam commented

---

I don't really understand the problem, so this is more of an ugly workaround than a proper fix: r7134 fires all the cleanups from the server cleanup method which is called when we receive a signal.

[totaam]

2014-08-07 15:20:45: totaam changed status from closed to reopened

[totaam]

2014-08-07 15:20:45: totaam changed resolution from worksforme to **

[totaam]

2014-08-07 15:20:45: totaam commented

---

This change was breaking profiling and has been reverted in r7181.

We need a solution that:

• guarantees we always run the exit callbacks (usual case)
• runs the cleanups in the UI thread (see x11 cleanup must still be done in the UI thread #582)
• allows us to return from main() without calling them..
• works with a console or regular terminal..

Bonus would be if we could also kill the vfb without killing the server process by ensuring that the cleanups close all the X11 server connections.

[totaam]

2015-04-29 10:26:30: antoine changed status from reopened to closed

[totaam]

2015-04-29 10:26:30: antoine set resolution to fixed

[totaam]

2015-04-29 10:26:30: antoine commented

---

No idea why, but gtk_main just exited without returning control to us when our sys.excepthook override hack was in place, so r9197 unregisters it in the signal handler (and also from do_quit for good measure) and the process now exits cleanly again when we send control-c to the console.

(will backport)

[totaam]

2015-05-05 05:06:08: antoine changed status from closed to reopened

[totaam]

2015-05-05 05:06:08: antoine removed resolution (was fixed)

[totaam]

2015-05-05 05:06:08: antoine commented

---

Re-opening because of #852#comment:4, r9197 caused problems because of a typo.
Maybe the implementation error is what made it work from the console?

[totaam]

2015-05-10 13:05:35: antoine commented

---

Related: r9292 should make exit on CTRL_C more reliable on win32.

[totaam]

2015-05-10 16:59:52: antoine commented

---

r9294 also makes it more likely that we won't just hang on a signal: the second signal should force quit - even if that means a less clean exit. (particularly relevant with gtk3)

[totaam]

2015-05-11 10:43:03: antoine commented

---

Well, now that's interesting: it is the error (the typo) raised in the cleanup function which allowed the atcleanups functions to run, without it we end up running the server cleanups but not the regular python atexit cleanups. But we want both!

So r9295 uses sys.exit from the signal handler, and that seems to do the trick. Do not ask why, I think I have tried everything else.

Will backport.

Found a related ticket: Bug 622084 - Ctrl+C does not exit gtk app.

[totaam]

2015-05-11 11:00:55: antoine changed status from reopened to closed

[totaam]

2015-05-11 11:00:55: antoine set resolution to fixed

[totaam]

2015-05-11 11:00:55: antoine commented

---

Backports:

• 9296 for v0.15.x
• 9297 for v0.14.x

Closing, hopefully for the last time.