Bug#266760: KDE Logout Hang because realtime artsd: a followup
- To: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- Cc: Anthony Labarre <email@example.com>, Peder Chr. Nørgaard <Peder.Chr.Norgaard@ericsson.com>
- Subject: Bug#266760: KDE Logout Hang because realtime artsd: a followup
- From: Adeodato Simó <firstname.lastname@example.org>
- Date: Fri, 1 Oct 2004 05:01:45 +0200
- Message-id: <20041001030145.GA7144@chistera.yi.org>
- Mail-followup-to: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Anthony Labarre <email@example.com>, Peder Chr. Nørgaard <Peder.Chr.Norgaard@ericsson.com>
- Reply-to: Adeodato Simó <firstname.lastname@example.org>, email@example.com
[This is a crosspost to Debian Bug#266760 and KDE Bugs #88401 and #86426,
plus the debian-kde mailing list.]
hi all, I've been "playing" around with this bug for a couple of
hours, and after some hard reboots I've made some *little* findings
which I'll share hoping that people with more knowledge may find it of
for completeness sake, I'll restate what is already known:
- it only happens with 2.4.x kernels
- it only happens if arts is running with realtime priority
(which means: checkbox enabled in control center and artswrapper
is setuid root)
my little findings are:
- there has to be a sound associated with the "KDE is exiting"
event. I'm surprised this has never been mentioned; perhaps it is
that I'm wrong, but if you're looking for a workaround and
disabling realtime priority is not an option, having no sound with
the exit event seems to do the trick.
- the "culprit" of "root of all evil" seems to be kdeinit_shutdown
in /usr/bin/startkde: I'd say the hang is produced when kdeinit
(as per kdeinit_shutdown request) tries to shutdown an arts
process that is in the middle of playback. the lines in question
echo 'startkde: Shutting down...' 1>&2
# Clean up
artsshell -q terminate
adding a "sleep 10" statement just before the kdeinit_shutdown
invocation seems to prevent the crash, too. that'd be because
kdeinit makes arts terminate when the sound was already output.
note that is effectively kdeinit who kills arts: if one takes out
the "-q" from artsshell, it appears in the log: "unable to connect
to sound server". I ignore if this is the expected behavior (I
imagine it is), I just mention in case it may be relevant.
- finally, one thing that strikes me as unusual but that may be not
(and, again, I mention in case it's relevant): with the same KDE
3.3 setup, when using a 2.6 kernel there is just one artsd process
per user session; with a 2.4, though, there are *two* (one being
the child of the other).
I haven't been able to test if this happened with KDE 3.2, but if
it didn't, perhaps something weird is going in there. also, IIRC,
the child process did not respond to "kill -15", "kill -9" was
* * *
I would ask everybody who has experienced the problem if they can
check the above: (1), that having no sound associated with "KDE is
exiting" prevents the crash; (2), that the "sleep 10" statement in
the proper place does, too; (3), that there are two artsd processes
by user session when using Linux 2.4.
also, it'd be nice if someone with access to a KDE 3.2 installation
could check if (3) applies.
* * *
and that was all this time, please excuse my verbosity.
hoping some of the above may be of some help to somebody,
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Múm - Don't be afraid, you have just got your eyes closed
The true teacher defends his pupils against his own personal influence.
-- Amos Bronson Alcott