Red Hat Bugzilla – Bug 1248152
systemd detects backlight (and fails to manipulate it) when no backlight exists
Last modified: 2016-07-19 13:15:25 EDT
Created attachment 1057376 [details]
I'm having an issue with a large number of desktops where systemctl status will show the state as "degraded" because systemd-backlight@backlight:acpi_video0.service fails at boot time. systemctl status shows:
Jul 28 12:53:00 ld61.e.math.uh.edu systemd: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0...
Jul 28 12:53:00 ld61.e.math.uh.edu systemd: systemd-backlight@backlight:acpi_video0.service: main process exited, code=exited, status=1/FAILURE
Jul 28 12:53:00 ld61.e.math.uh.edu systemd: Failed to start Load/Save Screen Backlight Brightness of backlight:acpi_video0.
Jul 28 12:53:00 ld61.e.math.uh.edu systemd: Unit systemd-backlight@backlight:acpi_video0.service entered failed state.
Jul 28 12:53:00 ld61.e.math.uh.edu systemd: systemd-backlight@backlight:acpi_video0.service failed.
Now, /sys/class/backlight is empty, so I'm not sure what method systemd is using to detect a backlight. I've attached dmesg output.
Hans suggested that there might be a race where a backlight exists momentarily only to be removed after systemd has already failed to manipulate it, and from looking at the kernel log it does appear to be a possibility. He asked me to file this ticket and CC him.
So what I believe is happening here is that the involved Asus mainboards suffer from a known Asus issue where Asus exports an acpi-video backlight interface on desktop/server mainboards.
The kernel has special Asus specific code to deal with this in drivers/platform/x86/asus_wmi.c, which
unregisters the acpi-video backlight if it has already registered and sets a flag telling the acpi-video code to not register it later on.
So depending on module load ordering the acpi-video0 backlight sysfs interface may briefly appear during module loading. Note that this is not unique to Asus. many of the vendor specific drivers/platform/x86/vendor-foo.c drivers do the same. It was decided long ago to have vendor specific handling in vendor specific drivers even if it involves removing the acpi-backlight interface because it is know to be broken for certain boards of that vendor.
I realize that this far from ideal from a systemd pov, but there is very little we can do about this in the kernel (if only firmware did not suck ...), so it would be good if a workaround could be added to systemd to not consider it a failure when an acpi_video# backlight interface disappears underneath it.
We should be able to deal with hardware going away at any time (for example being unplugged). So we should ignore missing devices in general.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.