[systemd-devel] failed to store sound card state

[Felix Miata]

On 2014-03-28 11:45 (GMT) Colin Guthrie composed:

>Felix Miata composed:

>> 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.

Maybe the reason I didn't see it is because the behavior described in my OP 
did not result from a CAD.

>> 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).

It seems to me to make a load more sense for the state to be saved when a 
state change is made. I must be missing something about what the state is.

>>>> 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.

Maybe you could try what I was trying to describe:

1-Make a verbose Grub menu selection (no plymouth, no rhgb, no silent)
2-see kernel and initrd messages load in 80x25 mode
3-see mode switch to e.g. 1280x1024
4-see another screen or two of messages scroll along
5-realize an undesired Grub menu selection was made
6-CAD (and release)
7-see init continue proceeding instead of shutdown messages
8-CAD (but do not release keys)

In this scenario, the failed to store sound card state strings are repeated 
many times, along with other strings, and the system seems to think it needs 
to "start" things (e.g. a stop job for XXX is running) to reach halt/reboot 
state.

>>> 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!

Sure! All my systems are multiboot. Cristian provided an openSUSE package 
name for unknown reason. I provided same for Mageia and Fedora, which 
apparently use virtually the same alsa-utils version as openSUSE, implying 
similar behavior regardless which OS is booted.

> 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.

Again, I don't understand need to save any time other than when a change has 
been made, or why a save needs to be initiated at shutdown.

> 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.

I doubt what I need differs from what most users need, which is, CAD prior to 
mounting / filesystem, if not also after mounting / but before any user logs 
in, to be responded to by ceasing to start additional processes, terminate 
running processes, and reboot, all in short order with no waiting for jobs to 
finish starting. One should not need anything but keyboard to abort init -> 
reset button, power button or pulling the plug should not be required to 
abort startup.

> systemctl mask alsa-store alsa-restore alsa-state

> Job done.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/