Might have some kind of bug here. I want to know if anybody else is seeing this. It's happened twice now, so I should be able to repeat it.
$ rpm -q centos-release centos-release-5-2.el5.centos
On my desktop, I "su -" to another user. Then "nohup thunderbird", it gets the mail and plays the announcement. ISTM this is an error right off the bat as this user is not the desktop owner. But that's not the main point. I really am OK with that behavior in my instance.
The problem is that the sound system goes muted, as indicated by the volume control on my desktop panel and I can't recover from it except by a reboot.
When I try to open the sound control panel, I get an error panel saying "No volume control GStreamer plugins and/or devices found". If I just try to un-mute, there's no error message but the status does not change.
I've attached a snapshot of the error panel.
Further, in chasing another problem that Jim (hce) had, we have done this:
# find . -type f -exec echo {} ; -exec cat {} ; >/tmp/asound.play.bug
Normally it acts as expected but now I get this.
cat: ./acpi/event: Device or resource busy cat: ./sys/net/ipv6/route/flush: Operation not permitted cat: ./sys/net/ipv4/route/flush: Operation not permitted cat: ./sys/fs/binfmt_misc/register: Invalid argument cat: ./sysrq-trigger: Invalid argument
and it hangs right there. <Ctl>-<C> breaks OK.
I feel it might be related to Jim's problem. I feel it might be a bug.
Can anybody reproduce? I think the T'bird step is coincidental. I think any sound played as another user should reproduce it. Hmmm ... I might be assuming to much if I assume another user is significant.
TIA
William L. Maltby wrote:
I feel it might be related to Jim's problem. I feel it might be a bug.
Can anybody reproduce? I think the T'bird step is coincidental. I think any sound played as another user should reproduce it. Hmmm ... I might be assuming to much if I assume another user is significant.
I don't see why the desktop owner would be the only one that can play a sound. But in any case have you checked to see if the sound device is locked by another process? When I have sound issues I usually run lsof | grep /dev/dsp to see what, if anything is using the sound card and kill it. To me it sounds like thunderbird from the other user is accessing the sound card directly, perhaps preventing other apps from accessing it. Some desktop setups include a sound daemon like esd or karts(?), to facilitate multiple things accessing the sound card simultaneously, but I'm not sure what their capabilities/limitations are as I rarely if ever use them.
nate
On Mon, 2008-07-07 at 09:13 -0700, nate wrote:
William L. Maltby wrote:
I feel it might be related to Jim's problem. I feel it might be a bug.
Can anybody reproduce? I think the T'bird step is coincidental. I think any sound played as another user should reproduce it. Hmmm ... I might be assuming to much if I assume another user is significant.
I don't see why the desktop owner would be the only one that can play a sound. But in any case have you checked to see if the sound device
I based my presumption based on past behavior (4.2-4.6, 5.0-5.1) and seeing the logic of why a desktop user might have exclusive use - if that user is first to use it. Before this, never tried to have another user use it first.
is locked by another process? When I have sound issues I usually run lsof | grep /dev/dsp to see what, if anything is using the sound card and kill it. To me it sounds like thunderbird from the other user is
I'll do that. But in the two cases so far, I had exited the T'bird after reading the mail and expected that that should remove any locks and close any open files.
accessing the sound card directly, perhaps preventing other apps from accessing it. Some desktop setups include a sound daemon like esd or karts(?), to facilitate multiple things accessing the sound card simultaneously, but I'm not sure what their capabilities/limitations are as I rarely if ever use them.
I'll check this out too. The sound daemon is available, esound-0.2.36-3, and I see a config file. I'll start checking the docs, configs, etc. to see what I can discover.
nate
<snip sig stuff>
Thanks for the time and thoughts Nate.
On Mon, 2008-07-07 at 09:13 -0700, nate wrote:
William L. Maltby wrote:
I feel it might be related to Jim's problem. I feel it might be a bug.
Can anybody reproduce? I think the T'bird step is coincidental. I think any sound played as another user should reproduce it. Hmmm ... I might be assuming to much if I assume another user is significant.
I don't see why the desktop owner would be the only one that can play a sound. But in any case have you checked to see if the sound device is locked by another process? When I have sound issues I usually run lsof | grep /dev/dsp to see what, if anything is using the sound card
That returned nothing. So I ran it w/o the dsp and manually extracted anything interesting. Got just these, which look normal.
mixer_app 10922 hardtolove 2u CHR 1,3 1604 /dev/null escd 10926 hardtolove 0r CHR 1,3 1604 /dev/null
A ps yielded (501 = hardtolove) the below. The user that ran the T'bird, which trumpeted mail arrival, was 502.
501 10906 1 0 07:35 ? 00:00:00 gnome-volume-manager --sm-client -id default5 501 10922 1 0 07:35 ? 00:00:00 /usr/libexec/mixer_applet2 --oaf -activate-iid=OAFIID:GNOME_MixerApplet_Factory --oaf-ior-fd=20 501 10926 1 0 07:35 ? 00:00:00 ./escd --key_Inserted="/usr/bin/ esc" --on_Signal="/usr/bin/esc"
Again, looking normal to me. That is *if* they should still be active, which I assume is the case.
Looking to reduce the scope of investigation (or conversely expand it beyond 5.2 a tad) I had booted this session with the previous (5.1) kernel. And experienced the same problem. So it seems to not be 5.2 kernel related. This would seem to indicate that it is X/Gnome related across 5.1 and 5.2 versions of libraries/applications.
A diff of the /proc/asound/ file contents from a previous normal situation with the contents after this problem was replicated shows only the kernel for significant differences.
432c432 < Kernel: Linux centos501.homegroannetworking 2.6.18-92.1.6.el5 #1 SMP Wed Jun 25 13:49:24 EDT 2008 i686 ---
Kernel: Linux centos501.homegroannetworking 2.6.18-92.1.1.el5 #1 SMP
Sat Jun 21 19:04:27 EDT 2008 i686
Slowly continuing investigation as opportunities arise...
and kill it. To me it sounds like thunderbird from the other user is accessing the sound card directly, perhaps preventing other apps from accessing it. Some desktop setups include a sound daemon like esd or
Clarification: the "other user" is me on the desktop, su'd to another user in gnome-terminal and "nohup thunderbird&".
Since *real* id, as opposed to *effective* id, may have effect here, I though I should mention it. Having done programming in many languages over an extended time, and having seen the general level of competence and attention to detail (the old 80/20 rule seem to apply), I don't trust them to do it right all that consistently.
karts(?), to facilitate multiple things accessing the sound card simultaneously, but I'm not sure what their capabilities/limitations are as I rarely if ever use them.
nate
<snip sig stuff>
William L. Maltby wrote:
That returned nothing. So I ran it w/o the dsp and manually extracted anything interesting. Got just these, which look normal.
How about lsof | grep /dev/snd
I'm used to using OSS, which usually means /dev/dsp, it seems that ALSA uses /dev/snd(or maybe another device..). I had a similar issue last night where the flash plugin in firefox prevented Cedega from being able to spit out sound and found it was using a device in /dev/snd, once I stopped the flash plugin I got sound back(and even with the sound device in use, XMMS was able to play sound no problem and it is configured to use ALSA, as is Cedega).
Worst case just run lsof | grep /dev that's how I found the issue last night, I wasn't sure what /dev device was in use.
mixer_app 10922 hardtolove 2u CHR 1,3 1604 /dev/null escd 10926 hardtolove 0r CHR 1,3 1604 /dev/null
These reference /dev/null which isn't related.
nate
On Wed, 2008-07-09 at 10:17 -0700, nate wrote:
William L. Maltby wrote:
That returned nothing. So I ran it w/o the dsp and manually extracted anything interesting. Got just these, which look normal.
How about lsof | grep /dev/snd
In my visual, I was on the lookout for that (or any variation). BJIC,
It returned nothing also.
I'm used to using OSS, which usually means /dev/dsp, it seems that ALSA uses /dev/snd(or maybe another device..). I had a similar issue last night where the flash plugin in firefox prevented Cedega from being able to spit out sound and found it was using a device in /dev/snd, once I stopped the flash plugin I got sound back(and even with the sound device in use, XMMS was able to play sound no problem and it is configured to use ALSA, as is Cedega).
I'll see if I can ID a plugin in the next pass.
Worst case just run lsof | grep /dev that's how I found the issue last night, I wasn't sure what /dev device was in use.
That's how I found the below.
mixer_app 10922 hardtolove 2u CHR 1,3 1604 /dev/null escd 10926 hardtolove 0r CHR 1,3 1604 /dev/null
These reference /dev/null which isn't related.
I ignored the dev/null bit because I just wanted to see anything that might be sound related that was running.
<snip sig stuff>
William L. Maltby wrote:
I'll see if I can ID a plugin in the next pass.
The plugins themselves won't show up, in my case it just said firefox was using it. And I recall getting audio from flash earlier in the day so thought it still might be using it, and I happened to be right, after disabling the plugin the lock on the device was released.
Since nothing is using the sound device, I'm not sure what else to check, short of permissions, at one point a few years ago it wasn't uncommon for the permissions of devices such as sound devices etc to get automatically changed to the person logged in. Not sure what caused it or why, or if anything still does it anymore. But if your user doesn't have access to the device I would think similar behavior would occur.
So, check permissions on /dev/snd/* and /dev/dsp, another thing I do to test is run a command line program that generates a sound(I use mpg123 out of habbit which plays mp3 files), and see if you notice any permission denied type errors.
nate
On Wed, 2008-07-09 at 11:25 -0700, nate wrote:
William L. Maltby wrote:
I'll see if I can ID a plugin in the next pass.
The plugins themselves won't show up, in my case it just said firefox was using it. And I recall getting audio from flash earlier in the day so thought it still might be using it, and I happened to be right, after disabling the plugin the lock on the device was released.
Since nothing is using the sound device, I'm not sure what else to check, short of permissions, at one point a few years ago it wasn't uncommon for the permissions of devices such as sound devices etc to get automatically changed to the person logged in. Not sure what caused it or why, or if anything still does it anymore. But if your user doesn't have access to the device I would think similar behavior would occur.
Well, that was involved partly. The other user owned all the devices /dev/{gpmctl,mixer,audio,adsp,snd} *and* floppies, HD, nvidia, ...
So I ran
find /dev -user bill -exec chown hardtolove {} ;
which I really shouldn't (I know better). But that did provide a small gain.
I can now open the Volume Control Panel (for a lurking friend, that is VCP ;-)
I still can't open the volume slider that drops down from the little speaker icon. So something is better, something still not fixed.
So, check permissions on /dev/snd/* and /dev/dsp, another thing I do to test is run a command line program that generates a sound(I use mpg123 out of habbit which plays mp3 files), and see if you notice any permission denied type errors.
Will do. Signing off to find out where I can get mpg123. I think I'll pop a CD in again first and see what I can doo-dah, doo-dah with that.
BRB
nate
<snip sig stuff>
Thanks for following up!
On Wed, 2008-07-09 at 15:20 -0400, William L. Maltby wrote:
On Wed, 2008-07-09 at 11:25 -0700, nate wrote:
<snip>
Well, that was involved partly. The other user owned all the devices /dev/{gpmctl,mixer,audio,adsp,snd} *and* floppies, HD, nvidia, ...
So I ran
find /dev -user bill -exec chown hardtolove {} ;
which I really shouldn't (I know better). But that did provide a small gain.
I can now open the Volume Control Panel (for a lurking friend, that is VCP ;-)
I still can't open the volume slider that drops down from the little speaker icon. So something is better, something still not fixed.
So, check permissions on /dev/snd/* and /dev/dsp, another thing I do to test is run a command line program that generates a sound(I use mpg123 out of habbit which plays mp3 files), and see if you notice any permission denied type errors.
Will do. Signing off to find out where I can get mpg123. I think I'll pop a CD in again first and see what I can doo-dah, doo-dah with that.
BRB
Ahhhhh! Music to my ears!
CD is playing alright. Volume Control Panel mute, volume, balance all work. In *my* original thread (not the one from ech - Jim?), I couldn't even open the Volume Cont... crap that's too long - VCP ;-) (you know who you are!)
So, I suspect we have achieved bug nirvana. ISTM that the problem is isolated to Gnome or it's interface to the system *or* a failure in some OS component.
1) Gave (properly?) ownership of the devices to a user other than the desktop owner (NB: *if* it is legal for a user other than desktop owner to use the facilities because the user is "in the desktop", being invoked from a Gnome terminal, then the device ownership should be given to the user of the device, just as with tty devices). 2) When the using application(s) are terminated, the devices ownership should be returned to root, as with tty devices, or back to the desktop user (if that user ever owned them *before* the devices were used - which they weren't in this case) allowing later allocation to another user again and making them also available for the desktop user. 3) When ownership of the devices were manually changed to root owner, *part* of the desktop facilities began operating normally. 4) Only part not working now is the volume control application out of the speaker icon on my panel. 5) As you suspected, lookie here!
# cd ~hardtolove;find . -user bill -ls 16646219 7948 -rwxr-xr-x 1 bill bill 8119784 Nov 20 2007 ./firefox/plugins/libflashplayer.so 16646218 8 -rw-r--r-- 1 bill bill 856 Dec 15 2006 ./firefox/plugins/flashplayer.xpt
The Q now is will changing ownership of these affect the volume slider? Shouldn't? First one is an LSB shared object, second one is data.
Anyway, with your (and all the others too) help, we have a reproducible situation and some clues.
Before I write a bug report (after seeing that one doesn't exist), anything else you think I could look for or try?
nate
<snip sig stuff>
Thanks again,
William L. Maltby wrote:
CD is playing alright. Volume Control Panel mute, volume, balance all work. In *my* original thread (not the one from ech - Jim?), I couldn't even open the Volume Cont... crap that's too long - VCP ;-) (you know who you are!)
I'm not sure it's a bug though, it may be a feature(tm) (the changing of permissions on devices). I don't think it should work that way.
I checked my Debian Etch desktop at home for any devices that were owned by my userid and the only ones that came up were terminal devices(/dev/pts/ stuff), which is normal if your logged in. It appears Debian hasn't adopted the stuff that changes the ownership of /dev devices and instead relies upon group access rights(what I think is the right way to do it). So any user in the audio group for example has a right to play audio. I don't have any RHEL or CentOS desktops, I have a Fedora 8 desktop in VMWare ESX but it doesn't appear to provide a virtual sound device so I can't check anything there either. My servers get a minimal version of gnome, not enough to login to a desktop with but enough to run some gnome or gtk related apps over a SSH tunnel.
- When the using application(s) are terminated, the devices ownership
should be returned to root, as with tty devices, or back to the desktop user (if that user ever owned them *before* the devices were used - which they weren't in this case) allowing later allocation to another user again and making them also available for the desktop user.
While this may be possible I can imagine the logic getting confusing if there are multiple people that are logged in.
The Q now is will changing ownership of these affect the volumeslider? Shouldn't? First one is an LSB shared object, second one is data.
No neither of these should impact volume. What impacts volumes with regards to flash is if the plugin is actually loaded(which requires going to a page that has a flash object), and actually plays some audio. Before that happens nothing with the audio subsystem is touched as far as I know..
Before I write a bug report (after seeing that one doesn't exist), anything else you think I could look for or try?
Not off the top of my head.. I guess last words would be don't be surprised if it doesn't get fixed(short of getting off the scheme of changing ownership of dev devices entirely for things like audio), which I don't think(hope) would happen until a major OS rev is issued.
nate
On Wed, 2008-07-09 at 13:32 -0700, nate wrote:
William L. Maltby wrote:
CD is playing alright. Volume Control Panel mute, volume, balance all work. In *my* original thread (not the one from ech - Jim?), I couldn't even open the Volume Cont... crap that's too long - VCP ;-) (you know who you are!)
I'm not sure it's a bug though, it may be a feature(tm) (the changing of permissions on devices). I don't think it should work that way.
I'll forgo my tendency to start a philosophical discussion about that. I'll just say that whatever method is chosen, I don't think correct behavior locks out the desktop user when the other current user (especially when that user was instantiated from the same desktop, implying that the *ending* ownership should be at least such that it allows the original gnome user access to the facilities) is finished with the device(s).
ISTM it is either a design flaw or an implementation flaw.
For an example of correct behavior, just think of ttys where multiple users can use the same device at different times. When a user logs on, ownership is given to that user. When the user logs out, ownership is returned to root.
System resources are *ultimately* managed by the system.
I checked my Debian Etch desktop at home for any devices that were owned by my userid and the only ones that came up were terminal devices(/dev/pts/ stuff), which is normal if your logged in. It appears Debian hasn't adopted the stuff that changes the ownership of /dev devices and instead relies upon group access rights(what I think is the right way to do it). So any user in the audio group for example has a right to play audio. I don't have any RHEL or CentOS desktops, I have a Fedora 8 desktop in VMWare ESX but it doesn't appear to provide a virtual sound device so I can't check anything there either. My servers get a minimal version of gnome, not enough to login to a desktop with but enough to run some gnome or gtk related apps over a SSH tunnel.
Sharing via group access rights is OK too. But it is not appropriate for all devices or even some uses. Think of 3 users printing to a non-spooled printer simultaneously. Or writing a CD/DVD.
Regardless, when one user of the group accessible device is finished, subsequent users are not locked out.
So even this scenario supports "buginess" of the RHEL/CentOS situation.
- When the using application(s) are terminated, the devices ownership
should be returned to root, as with tty devices, or back to the desktop user (if that user ever owned them *before* the devices were used - which they weren't in this case) allowing later allocation to another user again and making them also available for the desktop user.
While this may be possible I can imagine the logic getting confusing if there are multiple people that are logged in.
Not too bad. My background includes some extensive programming and early UNIX kernel internals. Shared devices start out owned by root, are allocated (implying ownership changes) when opened by the user and ownership returns to root when usage ends. There are use counts and associated structures that are checked to see if the device is in use.
With Linux it may be different, but some facility that implements some sort of similar control has to exist as a general purpose resource for management of the system.
The Q now is will changing ownership of these affect the volumeslider? Shouldn't? First one is an LSB shared object, second one is data.
No neither of these should impact volume. What impacts volumes with regards to flash is if the plugin is actually loaded(which requires going to a page that has a flash object), and actually plays some audio. Before that happens nothing with the audio subsystem is touched as far as I know..
Yep. In my case, it was the T'bird mail notification that played the sound.
Before I write a bug report (after seeing that one doesn't exist), anything else you think I could look for or try?
Not off the top of my head.. I guess last words would be don't be surprised if it doesn't get fixed(short of getting off the scheme of changing ownership of dev devices entirely for things like audio), which I don't think(hope) would happen until a major OS rev is issued.
I agree. Since this would (apparently, based on what is seen) necessitate the changing of some important library routines and/or application logic.
It wouldn't surprise me if the response was something like "Why are you running as multiple users? That's stupid!".
nate
<snip sig stuff>
Regardless, your assistance has been most generous and helpful. I appreciate your selflessness.
Thanks,
-
nate -
William L. Maltby