[systemd-devel] failed to store sound card state

[Colin Guthrie]

'Twas brillig, and Felix Miata at 28/03/14 01:12 did gyre and gimble:
> On 2014-03-27 21:46 (GMT-0300) Cristian Rodríguez composed:
> 
>> Felix Miata composed:
> 
>>> I see this repeated often during reboot attempts that do not proceed as
>>> expected to swiftly do the deed. It seems to be prerequisite to
>>> shutdown/reboot. I can't recall ever seeing anything like it when
>>> sysvinit was employed.

The same code was ultimately called in sysvinit days. On Mageia, the
"sound-scripts" package effectively did this job.

> Why does rebooting require the storing of a sound

Because when a fresh system is powered on the sound card state is not
guaranteed. State about various bits of hardware is saved/restored like
this (e.g. screen brightness being another example).


>>> card state, particularly when there are no connected speakers and no
>>> sound system has been employed the entire time since booting (typical of
>>> multiuser rather than graphical startup, 3 on Grub cmdline)?
> 
>> Hey! :-)
> 
>> This is not a systemd issue.. but an implementation detail of the alsa
>> units instead.
> 
> Systemd controls startup and shutdown, right? Maybe what systemd
> requires it do is too obtuse for the alsa people to figure out how to
> prevent shutdown delays?

No, I don't think it's too obtuse! The units are super simple (just look
at them) and there is very little they could do that would introduce
delays because of the systemd units themselves. The binaries they spawn
can obviously take time, but that's very much in the domain of the alsa
guys.


> BTW, this is normally not a problem that I can recall. It occurs
> following CAD that follows quickly on the heels of making a Grub menu
> selection and realizing a selection error had been made, before any
> filesystems have been mounted, and before many if not most units have
> been triggered to start.

Not really sure what this is referring to as you were previously talking
about *storing* state, which happens on shutdown or reboot, but now you
seem to be talking about Grub menu selections, which implies bootup...
So perhaps you need to be more detailed about the errors you're seeing.

>> rpm -qf /usr/lib/systemd/system/alsa*.service | uniq
>> alsa-utils-1.0.27.2-4.2.1.x86_64
> 
> ???
> alsa-utils-1.0.27.2-2.mga4
> alsa-utils-1.0.27.2-5.fc21.i686

You have both installed on your system? This seems very wrong!

FWIW, assuming you're using an MGA4 system (for even F21 IIRC), the
units for save and restore should both NOT run. The presence of a file
/etc/alsa/state-daemon.conf is a condition that is checked in the unit
files and as such neither of them should run if the file exists. It's
created as part of a %pre script on alsa-utils.

In this case, these units simply shouldn't run and instead the
alsa-state.service should be running to do the same job as both units.
This acts as a daemon which periodically saves the state and saves it on
exit too.


Obviously this is the default behaviour that fits most users (everything
in a distro is ultimately a compromise!), and if you don't need this on
your system, then much like any systemd unit you don't want, you, as an
administrator, should just mask it.

systemctl mask alsa-store alsa-restore alsa-state

Job done.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/