I have an /etc/tmpfiles.d/vgaswitcheroo.conf file with the following content: w /sys/kernel/debug/vgaswitcheroo/switch - - - - OFF This is intended as a replacement for the old echo OFF > /sys/kernel/debug/vgaswitcheroo/switch from rc.local However, a cat /sys/kernel/debug/vgaswitcheroo/switch after boot reveals that the "OFF" has not been written. (This results in both graphic cards being powered, which is not much fun in terms of power consumption) But when I issue systemd-tmpfiles --create /etc/tmpfiles.d/vgaswitcheroo.conf manually, everything works as expected. I get absolutely no error / warning during boot (checked using journalctl) and /sys/kernel/debug gets (according to journalctl) mounted before anything corresponding to tmpfiles is executed. Changing the contents of the file to f /sys/kernel/debug/vgaswitcheroo/switch - - - - OFF results in an error at boot saying "no such file or directory" Additional information: [daniel@camino ~]$ systemctl --version systemd 194 arch +PAM -LIBWRAP -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ [daniel@camino ~]$ uname -a Linux camino 3.5.6-1-ARCH #1 SMP PREEMPT Sun Oct 7 19:30:49 CEST 2012 x86_64 GNU/Linux dump of journalctl: Oct 12 08:21:15 camino systemd[1]: Mounted Debug File System. Oct 12 08:21:15 camino systemd[1]: Started Remount Root and Kernel File Systems. Oct 12 08:21:15 camino systemd[1]: Starting Local File Systems (Pre). Oct 12 08:21:15 camino systemd[1]: Reached target Local File Systems (Pre). Oct 12 08:21:15 camino systemd[1]: Mounting /tmp... Oct 12 08:21:15 camino systemd-vconsole-setup[143]: Cannot open font file latarcyrheb-sun16 Oct 12 08:21:15 camino systemd[1]: Starting Load Random Seed... Oct 12 08:21:15 camino systemd[1]: Mounted /tmp. Oct 12 08:21:15 camino systemd[1]: Starting Local File Systems. Oct 12 08:21:15 camino systemd[1]: Reached target Local File Systems. Oct 12 08:21:15 camino systemd-modules-load[141]: Inserted module 'acpi_cpufreq' Oct 12 08:21:15 camino systemd[1]: Starting Recreate Volatile Files and Directories... Oct 12 08:21:15 camino systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage... Oct 12 08:21:15 camino systemd[1]: Started Load Random Seed. Oct 12 08:21:15 camino kernel: fuse init (API version 7.19) Oct 12 08:21:15 camino systemd-modules-load[141]: Inserted module 'fuse' Oct 12 08:21:15 camino systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. Oct 12 08:21:15 camino systemd-modules-load[141]: Inserted module 'kvm' Oct 12 08:21:15 camino systemd-modules-load[141]: Inserted module 'kvm_intel' Oct 12 08:21:15 camino systemd-tmpfiles[166]: Failed to create file /sys/kernel/debug/vgaswitcheroo/switch: No such file or directory Oct 12 08:21:15 camino systemd[1]: Started Recreate Volatile Files and Directories.
Created attachment 68483 [details] Boot with w parameter Booted with w ... OFF in /etc/tmpfiles.d/vgaswitcheroo.conf I assume the real problem is that the radeon module is loaded some time AFTER tmpfiles is doing its job. Of course, the quick fix would be to create a unit to do the job. Is there any other way to get this working?
This is a general race between loading modules and applying the /sys change. Basically, "tmpfiles" is simply not the tool to make the change you are attempting. Instead, please use a udev rule that writes the file in question as the hw shows up. That's the only way how to properly serialize the actions. Which reminds me that I actually have had on my TODO list for a while to post a blog story about how to properly apply /sys and /proc/sys settings to a device without these races.
Hi, so writing an udev rule is the proper way to solve this? I haven't thought of this yet, thank you! :) Other ideas I came up with was adding the module to the initramfs (which is what I had done previously) or using a unit as others on the web have done (with varying quality) But both seems more like a hack to me, so I'll write a udev rule.
Closing, since an udev rule is the right solution here. And writing the blog story about this is in the systemd TODO file anyway, so we don't need this bug anymore.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.