Running KDE, suppose you install the "Sound Mixer" applet into KDE's `kicker'. Running `alsaconf' will kill kicker, even if you first remove the applet. However, if the applet was never installed into `kicker', then running `alsaconf' spares `kicker'. Reproducible: Always Steps to Reproduce: 1. Run KDE. 2. With ptr on kicker, rclick -> Add -> Applet -> Sound Mixer. 3. In a root shell, run `alsaconf' ...and stand back... . Actual Results: Kicker disappears; the `ps' cmd shows that it is gone.
This is not a tenshi bug. Please double-check the component when creating new bugs. Reassigning to bug-wranglers. Thx
Right you are. I realized my error soon after posting the bug and tried to use the "Reassign bug" line, but could not get it to work for me. I'm sorry about my slip.
kicker dies because alsaconf runs "/etc/init.d/alsasound stop" which in turn runs a command that kills all processes that opened the audio devices. We cannot do anything for it on the kde side, reassigning to the sound herd to see what they can do about this behavior of alsaconf.
That's the expected behavior. Short answer is don't use alsaconf... just edit /etc/modules.d/alsa yourself
Thanks for your comments, gentlemen. Gregorio Guidi, is the "Sound Mixer" itself a process? --why can't just it be killed, rather than all of kicker? Sure "Sound mixer" is running inside of kicker but, after all, kicker is running inside of KDE, and we'd probably all agree that it would be unreasonable for `alsaconf' to kill KDE if the user had, at some point, run the "Sound Mixer" applet. By the way, it is possible that thread http://forums.gentoo.org/viewtopic-t-331879.html is seeing this same issue but in a different context.
> is the "Sound Mixer" itself a process? --why > can't just it be killed, rather than all of kicker? it's not a separate process, it's loaded by the kicker process itself.
Well then that's a bad design decision on the part of kde...
