Current bug? "file /var/lib/alsa/asound.state lock error: No such file or directory"

upnort · 02-28-2021, 02:59 PM

I am testing updating 14.2 to Current on a Lenovo T400. With rc.alsa executable I always see the following error:

Code:

file /var/lib/alsa/asound.state lock error: No such file or directory

Both the directory and file exist. 0755 permissions and root:root ownership.

Using alsactl -L avoids the errors.

Both aplay and speaker-test function fine.

Booting with rc.alsa not executable also works.

What is causing the error?

Is rc.alsa needed any more?

Thanks.

chris.willing · 03-01-2021, 06:12 PM

Quote:

Originally Posted by upnort

I am testing updating 14.2 to Current

[snip]

Booting with rc.alsa not executable also works.

What is causing the error?

Is rc.alsa needed any more?

Thanks.

On a system born as -current (not upgraded from 14.2) rc.alsa is not executable, so my guess is that it's not needed but perhaps left there for those who have special alsa needs.

chris

bassmadrigal · 03-01-2021, 07:08 PM

In the alsa-utils package for -current, rc.alsa is not executable. It has 644 permissions (rw-r--r--). I think, like with rc.pulseaudio, you are to leave it not executable unless you have a reason to change it.

upnort · 03-02-2021, 02:22 PM

If there is no upstream remedy then perhaps the rc.alsa script should be modified to using the -L option.

bassmadrigal · 03-02-2021, 03:21 PM

Quote:

Originally Posted by upnort

If there is no upstream remedy then perhaps the rc.alsa script should be modified to using the -L option.

Possibly, or maybe the script should be modified to create the file. I'm not sure if one is better than the other.

However, since it isn't executable by default, it might be left as an exercise to the admin if they decide to make it executable.

upnort · 03-02-2021, 04:13 PM

On a system updated from 14.2 the files already exist.

While admins should always have final opinion, this is broken and I'd like to find an appropriate cure. Either there is a bug in the alsa code or the rc.alsa script should be modified to use -L.

A quick test in a fresh install VM indicates the lock file no longer exists. No stderr spew. Next time I update one of my test systems from 14.2 I'll delete the lock file and test rc.alsa.

bassmadrigal · 03-02-2021, 04:24 PM

Quote:

Originally Posted by upnort

On a system updated from 14.2 the files already exist.

While admins should always have final opinion, this is broken and I'd like to find an appropriate cure. Either there is a bug in the alsa code or the rc.alsa script should be modified to use -L.

A quick test in a fresh install VM indicates the lock file no longer exists. No stderr spew. Next time I update one of my test systems from 14.2 I'll delete the lock file and test rc.alsa.

So, it seems to be broken on just a 14.2 -> -current upgrade but works without error on a fresh -current install? If so, maybe the package and rc.alsa file don't need changes, but the CHANGES_AND_HINTS.TXT or UPGRADE.TXT should cover whatever needs to be changed to prevent the issue.

upnort · 03-02-2021, 06:02 PM

I completed another test run. Deleting the /var/lib/alsa files, directory, and /etc files/links does nothing to stop the stderr spew. Doesn't matter whether rc.alsa is +x.

This will be nominally frustrating for some users. The only cure I have found is using the -L option.