amixer timeout when muting sound card

[aschuring]

After dist-upgrading to intrepid, Ubuntu appears to hang when shutting down. I have traced this down to the ALSA shutdown script taking more than a minute (!) to save sound card state. More specifically:

root@neminis:~$ time amixer -c0 -q set Mic 0% mute

real 0m8.061s
user 0m0.003s
sys 0m0.012s

This is reproducable only in single-user mode. When I run the amixer command when logged in into X (I can even run the command from a console, as long as X is running), the same command takes only a few milliseconds as it should. I will attach an strace log from above call. Of interest is the following line:

 4.013297 ioctl(5, FIONREAD, [37]) = 0

which occurs twice in the script. It seems to be expecting data from a network socket, but I can't figure out why.

On a side note: why is amixer doing dns resolution, or any network activity for that matter?

[aschuring (aelschuring)]

I just found out the official live cd (ubuntu-8.10-desktop-amd64.iso) exhibits the same behaviour on a laptop I am currently testing on; as this is a bog-standard Sony Vaio laptop (Centrino platform, core2duo), I'm afraid this might be a much more widespread problem than just my system. Maybe a more alarming bug description might be warranted, along the lines of "Ubuntu freezes during shutdown process"...

[Chris (chris-morrone)]

I can confirm seeing this too, on both a laptop and a desktop machine.

Both machines report "HDA Intel" as the card type in /proc/asound/cards.

[raboof (arnouten)]

this might be the cause of bug 274995

[raboof (arnouten)]

Might this be pulseaudio-related? I saw some references to pulseaudio in the strace above, removed pulseaudio, and the problem doesn't seem to have occured for me since.

I can't quite explain why, yet, though ;).

[FlagMan (flagman)]

Well, my guess goes like this:

According to the default "/etc/default/pulseaudio.conf" pulseaudio is only started when somebody has logged in.

If pulseaudio is the default sound sink and you are logged into X, amixer will find the pulseaudio server, get the information it needs and be done with it quickly.

If pulseaudio is the default sound sink and you are NOT logged into X, amixer will search the pulseaudio server but there is none running on the local machine. Therefore, the network will be searched for a pulseaudio server. Most likely there is none on the local network either, and network timeouts are set to high values, so this may take some time and is the symptom we are seeing.

If you uninstall pulseaudio, it is no longer the default sink, and alsa will provide the information for amixer. Alsa does not search the network, so it will be quick to respond.

[aschuring (aelschuring)]

Yes, I agree that the problem seems to be related to pulseaudio (it is the only part of the sound system that includes networking), but I really like pulse and don't want to uninstall it.

Aside from that, I'm really not sure what the application is doing. In the strace above, you can see that amixer is talking on port 53, which is DNS, and is trying to resolve localhost. I have found that I had an incorrect entry in /etc/hosts (it mentioned localhost.localdomain while amixer was trying to resolve localhost.loos.site), which I thought would explain it. However, I have since corrected my /etc/hosts and the problem didn't go away.

There are a few things I'd still like to try, and I'll probably get to it this weekend:
- removing/commenting out everything in /usr/share/alsa/pulse.conf - which should prevent pulseaudio from being loaded
- removing the mdns references in /etc/nsswitch.conf - which I think is causing the slowdown
- removing the search-domain entry in /etc/resolv.conf - to see if it is the search entry that causes the spurious dns requests

[aschuring (aelschuring)]

It seems I can't help myself :)

Here are the results:
- commenting out everything in /usr/share/alsa/pulse.conf:
   amixer responds fast
- removing the mdns references in /etc/nsswitch.conf
   no change. However, removing "dns" does work. So the bug is likely in libnss_dns, which is part of glibc itself.
- removing the search entry in /etc/resolv.conf
   amixer responds fast

So it seems that the bug is that with a search-domain present in /etc/resolv.conf, the nameserver is always contacted, even when the correct information can be found in /etc/hosts. Removing the search statement is my workaround of choice, I don't think it will have any impact on home users. However, my guess is that /etc/resolv.conf is auto-generated by dhclient. Can anyone confirm that?

[FlagMan (flagman)]

aschuring,

yes, dhclient generates /etc/resolv.conf according to /etc/dhcp3/dhclient.conf and you could edit the latter.

BUT - before you go down that road:
Are you really shure your /etc/hosts contains _all_ the necessary information?
Mine was missing a plain "localhost" _for ipv6_ just like Robb suggested at
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/274995/comments/216

My /etc/hosts now looks like this:
########################
127.0.0.1 localhost
127.0.1.1 MyFancyLaptopName

::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
########################

This works for me, as amixer now always returns immediately! :)
G'luck!

[aschuring (aelschuring)]

Good catch! I hadn't thought about testing ipv6 resolution. It does explain why amixer tries to resolve localhost even though an IPv4 entry for it exists in /etc/hosts.

Perfect. I guess the missing search statement prevent dns lookup because the software didn't have an FQDN, only "localhost".

[Chris (chris-morrone)]

I concur, adding "localhost" to the ::1 line of /etc/hosts resolved the problem on my two machines.

Bug 295136 should probably not be marked a duplicate of bug 274995.

[raboof (arnouten)]

Why not? AFAICS, bug 274995 contains reports likely to be caused by several issues, including this one.

[Chris (chris-morrone)]

Then people should be directed to the correct bug for the correct issue. Munging multiple issues into one bug is a recipe for total confusion.

Bug 274995 has a whole lot of discussion about bios issues and hangs that don't interest me in the slightest.
I am only interested in tracking THIS bug (295136), which exactly the problem that I was seeing, and already has a simple workaround.

By incorrectly marking this bug as a duplicate of 274995, I am forced to receive much email about issues I care nothing about if I want to continue subscribing to bug 274136.