'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/ _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
