[Bug 584573] New: rcxdm stop doesn't stop lxdm
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c0 Summary: rcxdm stop doesn't stop lxdm Classification: openSUSE Product: openSUSE 11.3 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: LXDE AssignedTo: andrea@opensuse.org ReportedBy: lnussel@novell.com QAContact: qa@suse.de Found By: --- Blocker: --- rcxdm stop (ie init 3) doesn't stop lxdm as expected -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c1 andrea florio <andrea@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |lnussel@novell.com --- Comment #1 from andrea florio <andrea@opensuse.org> 2010-03-02 11:05:11 UTC --- hi ludwig, what's the version of lxdm you have installed? 0.1.0 or 0.2.0 git? it worked before.. rpm -qi lxdm will be enought -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c2 andrea florio <andrea@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Info Provider|lnussel@novell.com |sndirsch@novell.com --- Comment #2 from andrea florio <andrea@opensuse.org> 2010-03-02 12:32:50 UTC --- @ Ludwig i can confirm it even with X11:lxde version, no more needs about your informations @ Stefan on openSUSE 11.2 i use xdm script with that patch http://en.opensuse.org/LXDE#Troubleshooting and there everything is working fine (same package)... i wonder if you have clue about changes into xdm script (Factory package) that may brake it. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c3 Stefan Dirsch <sndirsch@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|sndirsch@novell.com | --- Comment #3 from Stefan Dirsch <sndirsch@novell.com> 2010-03-02 13:13:32 UTC --- I'm not aware of any changes, which would have broken it. Your patch has been applied. Feel free to provide a patch, which fixes it. I'm afraid I don't have time to investigate any lxdm issues. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c4 andrea florio <andrea@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #4 from andrea florio <andrea@opensuse.org> 2010-03-02 15:09:02 UTC --- ok.. let me investigate... if the script is fine, and i have to double check it, i'm afraid gcc4.5 broke something... let see -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c andrea florio <andrea@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c5 Guido Berhörster <guido+opensuse.org@berhoerster.name> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |guido+opensuse.org@berhoers | |ter.name --- Comment #5 from Guido Berhörster <guido+opensuse.org@berhoerster.name> 2010-05-19 19:25:16 UTC --- I've done some testing on M6, here's my findings so far: * only if there is an active X session the invocation of rcxdm stop spawns an lxdm-greeter-gtk process which remains alive, the lxdm daemon gets killed though * without an active session both the lxdm daemon and the greeter get killed as expected * kill -SIGTERM $(cat /var/run/lxdm.pid) reliably kills the daemon and greeter process If I find time I'll look into rcxdm and and lxdm's signal handling code tomorrow. Andrea, could you try the above on your 11.2 installation in the meantime and see if it matches my findings? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c6 Dr. Werner Fink <werner@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |werner@novell.com --- Comment #6 from Dr. Werner Fink <werner@novell.com> 2010-05-20 11:29:37 UTC --- IMHO the daemon who has startded lxdm-greeter-gtk (which is lxdm AFAICS) should stop also it. This is done normally in that way that a variable is used for that, e.g. volatile sig_atomic_t stopped = 0; static void sighandle(int sig __attribute__((unused))) { stopped = 1; } int main() { if (chkpidfile()) exit(1); daemon(0, 0); atexit(rmpidfile); dopidfile(); signal(SIGTERM, sighandle); while (!stopped) { do_job(); } rmchilds(); } -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c7 --- Comment #7 from Guido Berhörster <guido+opensuse.org@berhoerster.name> 2010-05-20 22:51:16 UTC --- I think I got it, there seems to be a race condition between between the session and lxdm, lxdm sets up a signal handler (lxdm.c: sig_handler) and sets a g_child_watch_add exit callback (lxdm.c: on_session_stop) for the session If lxdm's signal handler kicks in first it kills the session and exits, however if the session exits before that the on_session_stop kicks in and respawns lxdm. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c8 --- Comment #8 from Guido Berhörster <guido+opensuse.org@berhoerster.name> 2010-05-21 22:48:41 UTC --- I have a patch which removes the on_session_stop callback in the signal handler before trying to kill a possibly still alive session. IMHO the way signal handling is done in lxdm, that is using signal(2) in combination with atexit(3) with lots of code calling non-reentrant (glib) functions, is inherently unsafe and just asking for more trouble. The whole code actually is a giant hack and I'd prefer not to touch more than I need to. For reference, the old GTK tutorial contains a nice example on how to safely deal with POSIX signals in GTK/Glib apps which might have more activity in their main loop than lxdm (see http://web.archive.org/web/20070617072739/http://wwwtcs.inf.tu-dresden.de/~t...). Anyway, it'd be nice to get some feedback and testing, the patched package is in home:gberh:branches:X11:lxde. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c9 --- Comment #9 from andrea florio <andrea@opensuse.org> 2010-05-22 08:08:17 UTC --- (In reply to comment #8)
I have a patch which removes the on_session_stop callback in the signal handler before trying to kill a possibly still alive session. IMHO the way signal handling is done in lxdm, that is using signal(2) in combination with atexit(3) with lots of code calling non-reentrant (glib) functions, is inherently unsafe and just asking for more trouble. The whole code actually is a giant hack and I'd prefer not to touch more than I need to. For reference, the old GTK tutorial contains a nice example on how to safely deal with POSIX signals in GTK/Glib apps which might have more activity in their main loop than lxdm (see http://web.archive.org/web/20070617072739/http://wwwtcs.inf.tu-dresden.de/~t...). Anyway, it'd be nice to get some feedback and testing, the patched package is in home:gberh:branches:X11:lxde.
it works for me, please submit a request -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c10 --- Comment #10 from Guido Berhörster <guido+opensuse.org@berhoerster.name> 2010-05-22 10:02:42 UTC --- I'll summarize the signal handling a bit more. During initialization it first sets up an atexit(3) handler and after that signal handlers using signal(2). The signal handler for SIGINT and SIGTERM calls exit, thus triggering the exit handler which is then supposed to do the cleanup (mainly removing the g_child_watch handlers for the session, greeter, and X and killing them if they are still alive and closing the PAM session). This is fundamentally broken in multiple ways: * while on Linux signal seems to block further instances of the same signal from being delivered, this is not portable and since it uses the same signal handlers for SIGINT and SIGTERM, the handler might be interrupted and recursively called * this is a problem since the handler itself is non-reentrant because it uses non-async-safe, non-reentrant glib and pam functions and the signal can be delivered at any time while building the UI, setting up PAM etc., which means that e.g. my call to g_source_remove to prevent the child watch handler from being triggered when killing the session might produce something completely unexpected because the glib's data structures on the heap are in an unpredictable state * not even exit(3) is according to signal(7) async-safe So my bandaid patch might mitigate the race condition there are many possibilities for races and crashes in the signal-handling code. While I'm not an expert on this I still conclude that there seems to be a complete lack of understanding on this upstream which makes me feel very uncomfortable. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c11 andrea florio <andrea@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #11 from andrea florio <andrea@opensuse.org> 2010-05-22 10:49:24 UTC --- submitreq #40499 to factory is pending -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=584573 http://bugzilla.novell.com/show_bug.cgi?id=584573#c12 --- Comment #12 from Bernhard Wiedemann <bwiedemann@suse.com> --- This is an autogenerated message for OBS integration: This bug (584573) was mentioned in https://build.opensuse.org/request/show/40512 Factory / lxdm -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com