Is SELinux running? Do applications other than system-config-soundcard run when
run as root?

selinux is in permissive mode

of apps as root?   I've not noticed any problems.  e.g. yum, yumex are ok.

I meant applications that use sound. I figured the rest was working.

Ah, sorry, yes OK.

Running gnome-volume-control as root seems to work,   enabling aux input
allows sound from tvtime running as root.

David, what was the bug number for the problem with not setting sound device
nodes permissions properly?

It seems I should have added Console-Kit* to the above list!   Who knew!!

Console-kit wasn't running.


I'm still astounded by the complexity and the near impossibility for a regular
user to debug sound problems, and by the churn in in the packages related to
sound, but in this case the problem seems to be caused by me disabling Console-Kit.

Sorry.

re#5   #310721 perhaps?   I closed that one too as not-a-bug.

This bug is closed but there's an interesting bit here we may want to look at:
We really need to fix the OS so users don't randomly turn off critical system
services and then expect the system to work. And when it doesn't then bugs are
filed and that eats up developer time.

We can't really blame such users; after all we provide system-config-services
and there's little or no hint that service XYZ is a critical part of the
(desktop) OS or whether it's something that can be turned off. Users are left to
experiment and then sometimes files bogus bugs resulting in developer time being
wasted (I mean no offense John) . So perhaps we should look at starting identify
what the critical services are and then moving them to rc.sysinit?

Bill, what are your thoughts?

Also, the error messages from programs like gnome-volume-control could be
improved if an essential service is missing.

It doesn't help that the <F1> key in ntsysv doesn't work as advertised.

Nor that other new daemons like NetworkManager totally break previously working
configurations.

OK, OK, I guess this isn't the place for a general laundry list.   Just add my
+1 to comment #8.

(In reply to comment #9)
> Also, the error messages from programs like gnome-volume-control could be
> improved if an essential service is missing.

Feel free to file a bug, and I'll look into improving the error message for this
program. A good use of your time would be to go through all the default
installed programs that use sound and file bugs for those with error messages
that aren't so useful.

Hm, I suppose CK isn't really a good candidate for system activation, as it
relies on login state that it won't have if it's activated later. Or can the PAM
module activate it?

If we move to system activation for some of these services, it makes it harder
to fall into that trap.

(In reply to comment #11)
> Hm, I suppose CK isn't really a good candidate for system activation, as it
> relies on login state that it won't have if it's activated later. Or can the PAM
> module activate it?

Possibly.

> If we move to system activation for some of these services, it makes it harder
> to fall into that trap.

I'm saying that critical services for the desktop that can't be activated such as

 dbus-daemon --system
 ConsoleKit
 hald
 NetworkManager
 avahi
 cups

ought to be started from /etc/rc.sysinit (just like udevd is). Anything else
(such as Bluetooth daemon, smartd etc.) should be started only when the hardware
is detected or when it's used (ideally we'd move cups to that too) using udev or
hal.

(As a side-effect, the set of initscripts needed for a desktop system would
rapidly approach zero. We probably wouldn't boot any faster though.)