systemd-udev fails to execute alsactl during start-up if /usr and/or /var are separate volumes

Bug #1289730 reported by Dominik Kubla
62
This bug affects 12 people
Affects Status Importance Assigned to Milestone
alsa-utils (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

During system startup systemd-udev will print the following error messages:

[ 15.089778] systemd-udevd[683]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl -E HOME=/var/run/alsa restore 0': No such file or directory
[ 15.090130] systemd-udevd[684]: failed to execute '/usr/sbin/alsactl' '/usr/sbin/alsactl -E HOME=/var/run/alsa restore 1': No such file or directory

alsactl is present:

$ which alsactl
/usr/sbin/alsactl

but on a separate partition:
$ df -h /usr/sbin/alsactl
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/scaleo-usr 12G 6,6G 4,1G 62% /usr

$ df -h /var
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/scaleo-var 7,3G 2,5G 4,4G 37% /var

This suggests that systemd-udev is called before all local partitions have been mounted.

$ lsb_release -rd
Description: Ubuntu Trusty Tahr (development branch)
Release: 14.04

$ apt-cache policy udev
udev:
  Installiert: 204-5ubuntu13
  Installationskandidat: 204-5ubuntu13
  Versionstabelle:
 *** 204-5ubuntu13 0
        500 http://de.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

Kind regards,
  Dominik

Tags: patch
Revision history for this message
Martin Pitt (pitti) wrote :

Right, anything which wants to run at boot before /usr gets mounted needs to be in /bin or /sbin, not in /usr.

affects: udev (Ubuntu) → alsa-utils (Ubuntu)
Revision history for this message
David Henningsson (diwic) wrote :

Hi Martin / Dominik,

Just moving /usr/sbin/alsactl to /sbin/alsactl probably won't work, as alsactl uses stuff from /usr/share/alsa/init/* , and as already pointed out, there is also /var/run/* stuff that gets stored.

But can somebody point me to the set of rules here? I mean, what rule says /usr can be mounted on a separate partition but /sbin can not?

Changed in alsa-utils (Ubuntu):
status: New → Incomplete
Revision history for this message
David Henningsson (diwic) wrote :

Btw. There was something tricky about this. Like, if the sound card gets discovered before /usr, then alsactl would run as an upstart or systemd job. But if /usr gets mounted before the sound card (e g on hotplugging a USB headset), then the udev rule would run alsactl instead.

Does this make sense?

Revision history for this message
Marko.Esperanto (marco2710) wrote :

I installed Ubuntu 14.04 two days ago and I get the same error. But not always, I didn't understand why.

$ lsb_release -rd
Description: Ubuntu 14.04 LTS
Release: 14.04

$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 9.5G 364M 8.7G 4% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 1.8G 4.0K 1.8G 1% /dev
tmpfs 371M 1.2M 369M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 1.9G 80K 1.9G 1% /run/shm
none 100M 28K 100M 1% /run/user
/dev/sdb11 151G 142M 144G 1% /home
/dev/sdb7 19G 2.9G 15G 17% /usr
/dev/sdb8 9.1G 667M 8.0G 8% /var
/dev/sdb9 9.1G 22M 8.6G 1% /tmp
/dev/sda2 233G 229G 4.4G 99% /media/marco/HD_ext_02

Revision history for this message
Cherrot (cherrot) wrote :

Is there any way to fix this?

This problem would abort the system booting so what I can do is just reboot it and pray this time I would be the lucky one :(

Revision history for this message
David Henningsson (diwic) wrote :

So I think the right way to go here is to modify /lib/udev/rules.d/90-alsa-restore.rules and add a check of /usr/share/alsa and /var/run/alsa, so the entire file ends up like this (first line changed) :

-----
ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/share/alsa", TEST=="/var/run/alsa", GOTO="alsa_restore_go"
GOTO="alsa_restore_end"

LABEL="alsa_restore_go"
TEST!="/var/lib/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E HOME=/var/run/alsa restore $attr{device/number}"
TEST=="/var/lib/alsa/state-daemon.conf", RUN+="/usr/sbin/alsactl -E HOME=/var/run/alsa nrestore $attr{device/number}"

LABEL="alsa_restore_end"
-----

...because this udev rule is meant for hotplugging. In case this udev rule gets to run before /usr or /var is mounted, alsactl restore will instead be run for these cards later on, in /etc/init/alsa-restore.conf or /lib/systemd/system/basic.target.wants/alsa-restore.service.

Does that make sense?

Revision history for this message
David Henningsson (diwic) wrote : [RFC PATCH] alsactl: Do not run udev rule before datadir is mounted

The 90-alsa-restore.rules udev rule is primarily meant to handle hotplugging,
but sometimes it is also run before /usr is mounted,
and alsactl restore depends on /usr/share/alsa being present.

If /usr/share/alsa is not present, we're so early in the boot
process that alsa-restore.service (or upstart equivalent) will
run later on.

BugLink: https://bugs.launchpad.net/bugs/1289730
Signed-off-by: David Henningsson <email address hidden>
---

I'm not really sure of all quirks in the boot process, and I haven't tested the
patch either, hence the RFC above. Do you think it makes sense? Should we also
add @sbindir@ to the things to test for?

 alsactl/90-alsa-restore.rules.in | 2 +-
 alsactl/Makefile.am | 1 +
 configure.ac | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/alsactl/90-alsa-restore.rules.in b/alsactl/90-alsa-restore.rules.in
index c68119d..c83c6b5 100644
--- a/alsactl/90-alsa-restore.rules.in
+++ b/alsactl/90-alsa-restore.rules.in
@@ -1,4 +1,4 @@
-ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go"
+ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@datadir@", GOTO="alsa_restore_go"
 GOTO="alsa_restore_end"

 LABEL="alsa_restore_go"
diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am
index b862412..afbedb3 100644
--- a/alsactl/Makefile.am
+++ b/alsactl/Makefile.am
@@ -44,6 +44,7 @@ endif

 edit = \
  $(SED) -r -e 's,@sbindir\@,$(sbindir),g' \
+ -e 's,@datadir\@,$(mydatadir),g' \
     -e 's,@daemonswitch\@,$(ALSACTL_DAEMONSWITCH),g' \
        < $< > $@ || rm $@

diff --git a/configure.ac b/configure.ac
index 7e6894a..a4d2db3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -292,6 +292,7 @@ AC_DEFINE_UNQUOTED(SOUNDSDIR, "$soundsdir", [directory containing sample data])

 mydatadir="$dir/alsa"
 AC_DEFINE_UNQUOTED(DATADIR, "$mydatadir", [directory containing alsa configuration])
+AC_SUBST(mydatadir)

 AC_ARG_WITH(testsound,
   AS_HELP_STRING([--with-testsound=file], [give the path of test sound file for alsaconf]),
--
1.9.1

Revision history for this message
David Henningsson (diwic) wrote :

On 2014-06-13 10:26, Jaroslav Kysela wrote:
> Date 13.6.2014 10:15, David Henningsson wrote:
>> The 90-alsa-restore.rules udev rule is primarily meant to handle hotplugging,
>> but sometimes it is also run before /usr is mounted,
>> and alsactl restore depends on /usr/share/alsa being present.
>>
>> If /usr/share/alsa is not present, we're so early in the boot
>> process that alsa-restore.service (or upstart equivalent) will
>> run later on.
>>
>> BugLink: https://bugs.launchpad.net/bugs/1289730
>> Signed-off-by: David Henningsson <email address hidden>
>> ---
>>
>> I'm not really sure of all quirks in the boot process, and I haven't tested the
>> patch either, hence the RFC above. Do you think it makes sense?
>
> Yes, I think that's ok. Takashi?
>
>> Should we also add @sbindir@ to the things to test for?
>
> It shouldn't harm anything. Could you prepare a new patch?

Sure, please find it attached. I was also considering adding something
under /var as well, but I didn't do that, because I think it will fall
back to an "alsactl init" in that case (right?), so it still makes some
sense to run alsactl without /var.

>
>> alsactl/90-alsa-restore.rules.in | 2 +-
>> alsactl/Makefile.am | 1 +
>> configure.ac | 1 +
>> 3 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/alsactl/90-alsa-restore.rules.in b/alsactl/90-alsa-restore.rules.in
>> index c68119d..c83c6b5 100644
>> --- a/alsactl/90-alsa-restore.rules.in
>> +++ b/alsactl/90-alsa-restore.rules.in
>> @@ -1,4 +1,4 @@
>> -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go"
>> +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@datadir@", GOTO="alsa_restore_go"
>> GOTO="alsa_restore_end"
>>
>> LABEL="alsa_restore_go"
>> diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am
>> index b862412..afbedb3 100644
>> --- a/alsactl/Makefile.am
>> +++ b/alsactl/Makefile.am
>> @@ -44,6 +44,7 @@ endif
>>
>> edit = \
>> $(SED) -r -e 's,@sbindir\@,$(sbindir),g' \
>> + -e 's,@datadir\@,$(mydatadir),g' \
>> -e 's,@daemonswitch\@,$(ALSACTL_DAEMONSWITCH),g' \
>> < $< > $@ || rm $@
>>
>> diff --git a/configure.ac b/configure.ac
>> index 7e6894a..a4d2db3 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -292,6 +292,7 @@ AC_DEFINE_UNQUOTED(SOUNDSDIR, "$soundsdir", [directory containing sample data])
>>
>> mydatadir="$dir/alsa"
>> AC_DEFINE_UNQUOTED(DATADIR, "$mydatadir", [directory containing alsa configuration])
>> +AC_SUBST(mydatadir)
>>
>> AC_ARG_WITH(testsound,
>> AS_HELP_STRING([--with-testsound=file], [give the path of test sound file for alsaconf]),
>>
>
>

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Revision history for this message
Takashi Iwai (tiwai) wrote :
Download full text (4.8 KiB)

At Fri, 13 Jun 2014 11:05:52 +0200,
David Henningsson wrote:
>
>
>
> On 2014-06-13 10:26, Jaroslav Kysela wrote:
> > Date 13.6.2014 10:15, David Henningsson wrote:
> >> The 90-alsa-restore.rules udev rule is primarily meant to handle hotplugging,
> >> but sometimes it is also run before /usr is mounted,
> >> and alsactl restore depends on /usr/share/alsa being present.
> >>
> >> If /usr/share/alsa is not present, we're so early in the boot
> >> process that alsa-restore.service (or upstart equivalent) will
> >> run later on.
> >>
> >> BugLink: https://bugs.launchpad.net/bugs/1289730
> >> Signed-off-by: David Henningsson <email address hidden>
> >> ---
> >>
> >> I'm not really sure of all quirks in the boot process, and I haven't tested the
> >> patch either, hence the RFC above. Do you think it makes sense?
> >
> > Yes, I think that's ok. Takashi?
> >
> >> Should we also add @sbindir@ to the things to test for?
> >
> > It shouldn't harm anything. Could you prepare a new patch?
>
> Sure, please find it attached. I was also considering adding something
> under /var as well, but I didn't do that, because I think it will fall
> back to an "alsactl init" in that case (right?), so it still makes some
> sense to run alsactl without /var.
>
> >
> >> alsactl/90-alsa-restore.rules.in | 2 +-
> >> alsactl/Makefile.am | 1 +
> >> configure.ac | 1 +
> >> 3 files changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/alsactl/90-alsa-restore.rules.in b/alsactl/90-alsa-restore.rules.in
> >> index c68119d..c83c6b5 100644
> >> --- a/alsactl/90-alsa-restore.rules.in
> >> +++ b/alsactl/90-alsa-restore.rules.in
> >> @@ -1,4 +1,4 @@
> >> -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go"
> >> +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@datadir@", GOTO="alsa_restore_go"
> >> GOTO="alsa_restore_end"
> >>
> >> LABEL="alsa_restore_go"
> >> diff --git a/alsactl/Makefile.am b/alsactl/Makefile.am
> >> index b862412..afbedb3 100644
> >> --- a/alsactl/Makefile.am
> >> +++ b/alsactl/Makefile.am
> >> @@ -44,6 +44,7 @@ endif
> >>
> >> edit = \
> >> $(SED) -r -e 's,@sbindir\@,$(sbindir),g' \
> >> + -e 's,@datadir\@,$(mydatadir),g' \
> >> -e 's,@daemonswitch\@,$(ALSACTL_DAEMONSWITCH),g' \
> >> < $< > $@ || rm $@
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index 7e6894a..a4d2db3 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -292,6 +292,7 @@ AC_DEFINE_UNQUOTED(SOUNDSDIR, "$soundsdir", [directory containing sample data])
> >>
> >> mydatadir="$dir/alsa"
> >> AC_DEFINE_UNQUOTED(DATADIR, "$mydatadir", [directory containing alsa configuration])
> >> +AC_SUBST(mydatadir)
> >>
> >> AC_ARG_WITH(testsound,
> >> AS_HELP_STRING([--with-testsound=file], [give the path of test sound file for alsaconf]),
> >>
> >
> >
>
> --
> David Henningsson, Canonical Ltd.
> https://launchpad.net/~diwic
> >From 09a4abb5560448eb434a33fc237d578e14666940 Mon Sep 17 00:00:00 2001
> From: David Henningsson <email address hidden>
> Date: Fri, 13 Jun 2014 10:04:25 +0200
> Subject: [PATCH...

Read more...

Revision history for this message
David Henningsson (diwic) wrote :

On 2014-06-13 11:20, Takashi Iwai wrote:

>> +++ b/alsactl/90-alsa-restore.rules.in
>> @@ -1,4 +1,4 @@
>> -ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", GOTO="alsa_restore_go"
>> +ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="@sbindir@", TEST=="@datadir@", GOTO="alsa_restore_go"
>> GOTO="alsa_restore_end"
>
> IMO, it's better to use @mydatadir@ instead of @datadir@ here and...

Oops, sorry about that. Thanks for the review!

Attaching a fixup patch.

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

tags: added: patch
Revision history for this message
Marko.Esperanto (marco2710) wrote :

I changed the first line of the file "/lib/udev/rules.d/90-alsa-restore.rules" to

ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS!="card*", TEST=="/usr/share/alsa", TEST=="/var/run/alsa", GOTO="alsa_restore_go"

but sometimes it still crashes when booting. I undid the change of "90-alsa-restore.rules" and checked the dmesg log. The error "systemd-udevd[424]: failed to execute '/usr/sbin/alsactl' ..." always occurs. So, I suppose that another problem makes it to crash.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for alsa-utils (Ubuntu) because there has been no activity for 60 days.]

Changed in alsa-utils (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Michael Mikowski (kfocus) wrote :

Hey gang, I'm still seeing this on 14.04. I'm sorry there hasn't been "activity" for 60 days, but this bug is still very real and annoying. Can we reopen it?

This shouldn't be happening, and it is disconcerting for less experienced users who think their system is broken when (apparently) it really isn't.

Revision history for this message
Michael Mikowski (kfocus) wrote :

I have confirmed that the solution proposed in comment #6 completely resolves this issue. Can this be included in 14.10 perhaps?

Changed in alsa-utils (Ubuntu):
status: Expired → Confirmed
Revision history for this message
David Henningsson (diwic) wrote :

Hi!

I believe this is now fixed in Ubuntu 14.10, because the patches were included in upstream alsa-utils 1.0.28 which is in Utopic since end of July. Please confirm and reopen the bug if it is not. Thanks!

Reference:
http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=be4565c84163a158bec5380df6c0201f738c2013

Changed in alsa-utils (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.