Hide Forgot
This is upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=756539 the symptom is described at: https://bugzilla.gnome.org/show_bug.cgi?id=759414#c2 which is marked as a dupe. Regardless of power mode setting, journalctl -f is flooded with these messages: Mar 30 15:49:22 photon2 gnome-settings-daemon.desktop[2118]: Error executing command as another user: Not authorized Mar 30 15:49:22 photon2 gnome-settings-daemon.desktop[2118]: This incident has been reported. Mar 30 15:49:23 photon2 pkexec[26203]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 927] Mar 30 15:49:23 photon2 gnome-settings-daemon.desktop[2118]: Error executing command as another user: Not authorized Mar 30 15:49:23 photon2 gnome-settings-daemon.desktop[2118]: This incident has been reported. Mar 30 15:49:24 photon2 pkexec[26209]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 927] Mar 30 15:49:24 photon2 gnome-settings-daemon.desktop[2118]: Error executing command as another user: Not authorized Mar 30 15:49:24 photon2 gnome-settings-daemon.desktop[2118]: This incident has been reported. Mar 30 15:49:25 photon2 pkexec[26216]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 927] Mar 30 15:49:25 photon2 gnome-settings-daemon.desktop[2118]: Error executing command as another user: Not authorized Mar 30 15:49:25 photon2 gnome-settings-daemon.desktop[2118]: This incident has been reported. Mar 30 15:49:27 photon2 pkexec[26222]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 927] Mar 30 15:49:27 photon2 gnome-settings-daemon.desktop[2118]: Error executing command as another user: Not authorized Mar 30 15:49:27 photon2 gnome-settings-daemon.desktop[2118]: This incident has been reported. Mar 30 15:49:27 photon2 pkexec[26229]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 927] there does not seem to be any way of stopping this behavior. Automatic brightness control is disabled and even if I turn off the "power" plugin under dconf it continues. It seems upstream fix in https://bugzilla.gnome.org/show_bug.cgi?id=756539 would resolve.
looks like this was fixed in 3.18.3, verifying now that it works...
nope, the patch from the upstream bug is present but the issue persists. I'll try to get their attention on the upstream.
additional upstream bug added w/ new patch
I have this problem also. Is this what's causing the enormous memory leak: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1463 gdm 20 0 7723460 4.326g 5352 S 22.7 56.3 84:29.46 gnome-settings- 13949 me 20 0 2873536 1.086g 55012 S 7.0 14.1 158:52.80 firefox ... This is after nearly 3 days of uptime.
still happening in F24.
installing gnome-settings-daemon-3.20.1 which per upstream was to resolve the issue by itself did not resolve it for me, however a corresponding update to gnome-shell-3.20-3 and gnome-session-3.20.2 seems to have resolved. the automatic brightness feature is probably not actually working even if I turn it on but it at least seems to not be dumping errors.
false alarm, the problem resumes once the desktop resumes the screen from inactivty.
Are you sure gnome-settings-daemon is at fault here? I can't imagine it being correct for gdm to screw with the brightness while I'm already logged in.
I've no idea. If you're deeply familiar with these components, the linked upstream bugs refer to the behavior I'm seeing and the leading one is categorized as gnome-settings-daemon. From my POV nothing has changed w/ this issue, after restart, then laptop lid close and reopen, journalctl is flooded with these messages until I "systemctl stop iio-sensor-proxy" (and it seems like gnome starts this service directly, disabling the service has no effect). Asus has a lot of brightness issues w/ the linux kernel including that the f5/f6 keys don't work (see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1348890 for the ongoing years of pain on that one).
progress, more activity upstream
Still happening in Fedora 25 too, but I don't have the rights to edit the bug to reflect that.
The just released 4.9 kernel update added automatic brightness control for the ThinkPad X1 Yoga, and now my logs are getting flooded with this permission error.
This is an upstream bug.
*** Bug 1359481 has been marked as a duplicate of this bug. ***
Bastien, the upstream bug has been fixed. Please reopen this and apply the upstream patch: https://git.gnome.org/browse/gnome-session/commit/?id=73dba36
Correction: it seems that commit is already part of gnome-session 3.22.3, which is in Fedora 25, but this does not fix the issue.
Issue is still happening in F26 beta. So it either does not fix the issue, or the patch is not included. gnome-settings-daemon-3.24.2-2.fc26.x86_64 gnome-session-3.24.1-1.fc26.x86_64
issue is not fixed in gnome-session 3.22.3, can confirm here as well
Same here, Fedora 26
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I'm also seeing this with updated F26 on a gen1 lenovo thinkpad x1 yoga
I'm also seeing this with F26 installation media on a 1st generation Lenovo Thinkpad X1 Yoga (OLED)
Still happening on Lenovo Thinkpad X1 Tablet.
This also happens on my Lenovo Yoga 710 (11in model). Aside from rebooting the laptop, logging out and back in to the current Gnome session also seems to fix the backlight cycling and logs (definitely not ideal). Unlike bug 1468833, which only occurs after a suspend caused by closing the laptop lid (but not a suspend initiated by the power button), this bug also occurs after a power button suspend. Without a workaround in place, this bug continues to make my laptop borderline useless (at least when running the latest versions of Fedora).
Also happens with Fedora 26 & Asus UC305CA.
I can confirm #25 - logging out and back in again seems to resolve this issue. For how long I was unable to determine.
(In reply to René Kraneis from comment #27) > I can confirm #25 - logging out and back in again seems to resolve this > issue. For how long I was unable to determine. FYI, "killall gnome-settings-daemon" should have the same effect without requiring a logout. This sends SIGHUP to the gnome-settings-daemon process owned by the user, which causes that process to terminate; then it gets restarted (not sure if it's immediately or eventually). This is of course only a workaround.
I'm running Fedora 26 with the latest updates on my Yoga 710 and killall gnome-settings-daemon doesn't match any processes when this issue is occurring. BUT, this does work to stop the described issue: killall gsd-power
"killall gnome-settings-daemon" doesn't match any processes, but killall gsd-power kills my Fedora 26 Gnome ("oops - something went wrong"). Also, what makes this really miserable, is that whenever I encounter this problem, I have to cold reboot the laptop since the screen stays blank and does respond to brightness changes (via hotkeys) and I haven't found any other way to reset it back to working condition.
I believe this was fixed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=786164 https://bugzilla.gnome.org/show_bug.cgi?id=766067 The patches should be backported.
Perhaps I did something wrong, but after installing gnome-settings-daemon-3.24.3-3.fc26 from koji to test, the problem seems to be worse. Now the backlight changing happens right away after a clean reboot...not just after I sleep and wake my Yoga 710. Also, killall gsd-power no longer has an effect for me. Can anyone else confirm whether this new package fixes the symptoms? https://koji.fedoraproject.org/koji/buildinfo?buildID=962449
(In reply to Eric Kerby from comment #32) > Perhaps I did something wrong, but after installing > gnome-settings-daemon-3.24.3-3.fc26 from koji to test, the problem seems to > be worse. Now the backlight changing happens right away after a clean > reboot...not just after I sleep and wake my Yoga 710. You also changed the kernel, I'm guessing. The race that broke sensors on boot is fixed in newer kernels. So yay. > Also, killall > gsd-power no longer has an effect for me. Can anyone else confirm whether > this new package fixes the symptoms? I have no idea what you'd expect this to do. I'd expect gsd-power to be restarted...
Which kernel should we be running? I just updated to kernel-4.12.9-300.fc26.x86_64 from updates-testing and the issue is still occurring, and as Eric said, worse then before.
Not sure what negative side-effects this may have, but here's a process to kill which seems to disable the ambient sensor (and I imagine also rotation sensing) and keeps the backlight changing/error-logging from happening: sudo killall iio-sensor-proxy
gnome-settings-daemon-3.24.3-3.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-59962d8ed3
Issue is not resolved with the update, another update is required for the kernel and it is unclear which kernel is needed, or if the required patch has even been merged upstream or not.
Commented upstream in https://bugzilla.gnome.org/show_bug.cgi?id=772537 This does not seem to be fixed. # uname -a Linux box 4.12.9-200.fc25.x86_64 #1 SMP Fri Aug 25 13:23:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux # rpm -q gnome-shell gnome-settings-daemon gdm | sort gdm-3.22.3-1.fc25.x86_64 gnome-settings-daemon-3.22.2-1.fc25.x86_64 gnome-shell-3.22.3-1.fc25.x86_64 # ps axuwww | grep setting[s] user 12089 0.6 0.5 1383012 47672 tty2 Sl+ 08:35 0:05 /usr/libexec/gnome-settings-daemon gdm 20308 0.7 0.4 1144196 32832 tty1 Sl+ 08:47 0:01 /usr/libexec/gnome-settings-daemon # journalctl -f [...] Sep 02 08:49:03 box pkexec[22275]: pam_unix(polkit-1:session): session opened for user root by (uid=8000) Sep 02 08:49:03 box pkexec[22275]: tele: Executing command [USER=root] [TTY=unknown] [CWD=/home/tele] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 843] Sep 02 08:49:03 box pkexec[22274]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 843] Sep 02 08:49:03 box gnome-settings-daemon.desktop[20308]: Error executing command as another user: Not authorized Sep 02 08:49:03 box gnome-settings-daemon.desktop[20308]: This incident has been reported. Sep 02 08:49:04 box pkexec[22290]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 843] Sep 02 08:49:04 box gnome-settings-daemon.desktop[20308]: Error executing command as another user: Not authorized Sep 02 08:49:04 box gnome-settings-daemon.desktop[20308]: This incident has been reported. Sep 02 08:49:04 box pkexec[22291]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session Sep 02 08:49:04 box pkexec[22291]: pam_unix(polkit-1:session): session opened for user root by (uid=8000)
A workaround is: $ sudo bash -c 'echo "blacklist hid_sensor_als" > /etc/modprobe.d/als.conf' Reboot.
gnome-settings-daemon-3.24.3-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
as noted by others, latest release gnome-settings-daemon-3.24.3-3.fc26 now makes the issue worse. journalctl fills with messages immediately on boot as well as after wake from suspend: Sep 04 19:15:29 photon2 pkexec[3799]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 290] Sep 04 19:15:29 photon2 org.gnome.SettingsDaemon.Power.desktop[2317]: Error executing command as another user: Not authorized Sep 04 19:15:29 photon2 org.gnome.SettingsDaemon.Power.desktop[2317]: This incident has been reported. Sep 04 19:15:29 photon2 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-localed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 04 19:15:30 photon2 pkexec[3807]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 299] Sep 04 19:15:30 photon2 org.gnome.SettingsDaemon.Power.desktop[2317]: Error executing command as another user: Not authorized Sep 04 19:15:30 photon2 org.gnome.SettingsDaemon.Power.desktop[2317]: This incident has been reported. Sep 04 19:15:30 photon2 pkexec[3813]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 299]
On my ASUS UX303L, with automatic brightness turned OFF in GNOME settings: $ cat /etc/redhat-release Fedora release 26 (Twenty Six) $ uname -a Linux mylaptop 4.12.11-300.fc26.x86_64 #1 SMP Thu Sep 7 18:32:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q gnome-settings-daemon gnome-settings-daemon-3.24.3-3.fc26.x86_64 $ journalctl --since today | egrep 'pkexec|SettingsDaemon' |tail -9 syys 16 10:58:50 gogo pkexec[17830]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 749] syys 16 10:58:50 gogo org.gnome.SettingsDaemon.Power.desktop[1423]: Error executing command as another user: Not authorized syys 16 10:58:50 gogo org.gnome.SettingsDaemon.Power.desktop[1423]: This incident has been reported. syys 16 10:58:51 gogo pkexec[17836]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 740] syys 16 10:58:51 gogo org.gnome.SettingsDaemon.Power.desktop[1423]: Error executing command as another user: Not authorized syys 16 10:58:51 gogo org.gnome.SettingsDaemon.Power.desktop[1423]: This incident has been reported. syys 16 10:58:53 gogo pkexec[17842]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 749] syys 16 10:58:53 gogo org.gnome.SettingsDaemon.Power.desktop[1423]: Error executing command as another user: Not authorized syys 16 10:58:53 gogo org.gnome.SettingsDaemon.Power.desktop[1423]: This incident has been reported.
Still seeing this in F27 with Lenovo Yoga Pro 2 Sep 23 21:28:13 y2 pkexec[27036]: bkelly: Executing command [USER=root] [TTY=unk Sep 23 21:28:13 y2 pkexec[27037]: gdm: Error executing command as another user: Sep 23 21:28:13 y2 org.gnome.SettingsDaemon.Power.desktop[2871]: Error executing Sep 23 21:28:13 y2 org.gnome.SettingsDaemon.Power.desktop[2871]: This incident h Sep 23 21:28:15 y2 pkexec[27049]: pam_systemd(polkit-1:session): Cannot create s Sep 23 21:28:15 y2 pkexec[27049]: pam_unix(polkit-1:session): session opened for Sep 23 21:28:15 y2 audit[27049]: USER_START pid=27049 uid=1000 auid=1000 ses=13 Sep 23 21:28:15 y2 pkexec[27049]: bkelly: Executing command [USER=root] [TTY=unk Sep 23 21:28:15 y2 pkexec[27050]: gdm: Error executing command as another user: Sep 23 21:28:15 y2 org.gnome.SettingsDaemon.Power.desktop[2871]: Error executing Sep 23 21:28:15 y2 org.gnome.SettingsDaemon.Power.desktop[2871]: This incident h
This appears to be related to authorization for pkexec to run /usr/libexec/gsd-backlight-helper. If I login as a user through gdm and attempt to run the command with pkexec it executes without any problem, $ pkexec /usr/libexec/gsd-backlight-helper --set-brightness 380 $ echo $? 0 But if I sudo into that user and attempt to run the command it fails, $ sudo su - foo $ pkexec /usr/libexec/gsd-backlight-helper --set-brightness 380 Error executing command as another user: Not authorized This incident has been reported. $ echo $? 127 So some kind of pkexec auth magic has been done when one authenticates through the login process (using gdm) but that isn't done when using sudo (or ssh). Something interesting to note is shown with strace, $ strace pkexec /usr/libexec/gsd-backlight-helper --set-brightness 380 ... fstat(3, {st_mode=S_IFREG|0644, st_size=26254, ...}) = 0 mmap(NULL, 26254, PROT_READ, MAP_SHARED, 3, 0) = 0x7fb3de7ad000 close(3) = 0 futex(0x7fb3dd7d1888, FUTEX_WAKE_PRIVATE, 2147483647) = 0 write(2, "pkexec must be setuid root\n", 27pkexec must be setuid root ) = 27 exit_group(127) = ? +++ exited with 127 +++ But that is odd since it looks to me that pkexec is setuid root, $ ll /usr/bin/pkexec -rwsr-xr-x. 1 root root 23496 Apr 13 13:29 /usr/bin/pkexec But that might be an artifact of using strace. Regardless, it seems the problem here is one to do with authentication for gdm, or rather, lack of authentication in whatever agent pkexec is using to allow it to run this command as root.
(In reply to Steeve McCauley from comment #44) > This appears to be related to authorization for pkexec to run > /usr/libexec/gsd-backlight-helper. If I login as a user through gdm and > attempt to run the command with pkexec it executes without any problem, > > $ pkexec /usr/libexec/gsd-backlight-helper --set-brightness 380 > $ echo $? > 0 > > But if I sudo into that user and attempt to run the command it fails, > > $ sudo su - foo > $ pkexec /usr/libexec/gsd-backlight-helper --set-brightness 380 > Error executing command as another user: Not authorized > > This incident has been reported. > $ echo $? > 127 For me on Fedora 26 it behaves differently. Executing both as a gdm logged in user and using "sudo su" work correctly and give a zero return value: $ pkexec /usr/libexec/gsd-backlight-helper --set-brightness 937 $ echo $? 0 $ sudo su - myself $ pkexec /usr/libexec/gsd-backlight-helper --set-brightness 937 $ echo $? 0 > $ ll /usr/bin/pkexec > -rwsr-xr-x. 1 root root 23496 Apr 13 13:29 /usr/bin/pkexec This looks similar: $ ll /usr/bin/pkexec -rwsr-xr-x. 1 root root 23K Apr 13 19:29 /usr/bin/pkexec
(In reply to Steeve McCauley from comment #44) ...but if I SSH into my account, I do get the same behavior as you: $ ssh myself@localhost myself@localhost's password: Last login: Tue Sep 26 18:11:35 2017 from ::1 $ pkexec /usr/libexec/gsd-backlight-helper --set-brightness 927 Error executing command as another user: Not authorized This incident has been reported. $ echo $? 127 Would this configuration file be related to this issue (translations redacted)? $ cat /usr/share/polkit-1/actions/org.gnome.settings-daemon.plugins.power.policy <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"> <policyconfig> <vendor>GNOME Settings Daemon</vendor> <vendor_url>http://git.gnome.org/browse/gnome-settings-daemon</vendor_url> <icon_name>battery</icon_name> <action id="org.gnome.settings-daemon.plugins.power.backlight-helper"> <description>Modify the laptop brightness</description> <message>Authentication is required to modify the laptop brightness</message> <defaults> <allow_any>no</allow_any> <allow_inactive>no</allow_inactive> <allow_active>yes</allow_active> </defaults> <annotate key="org.freedesktop.policykit.exec.path">/usr/libexec/gsd-backlight-helper</annotate> </action> </policyconfig> I changed all <allow_*> tags to "yes" and now I can run the pkexec command line in an SSH session. But I still get this in my logs: pkexec[17977]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session audit[17977]: USER_START pid=17977 uid=42 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' pkexec[17977]: pam_unix(polkit-1:session): session opened for user root by (uid=42) pkexec[17977]: gdm: Executing command [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 927]
FWIW, I'm also on F26 now. did you reboot and try again? Since it's gdm that seems to be responsible for the issue it could be that it is considered "inactive", perhaps this config is stored on boot for gdm. It would be interesting to know if allow_inactive is sufficient. I'll give it a go.
Okay, I tried this too and can confirm that it allows an ssh session to run the pkexec command. It sure seems like it's something to do with uid 42 attempting to run this command as root.
So... what now? Bastien closed every bug upstream, but I still have it going full force on F26. Logs are basically unreadable! gnome-settings-daemon-3.24.3-2.fc26.x86_64 gdm-3.24.2-1.fc26.x86_64
Yeah I agree this is a problem. Been reporting this bug for 18 months now, upstream issues constantly get closed and none affect the problem at all (except to make it worse). This is not an issue that can be fixed without access to a reproduction case to confirm it's fixed.
Still same problem here on F26, trying to read logs is a disaster. Let me know if there is anything I can do to assist in narrowing this down.
Same issue on Fedora 27.
Created attachment 1342078 [details] gsd-backlight-helper frontend script My asus laptop was almost unusable because of the constant flickering caused by use gdm (uid 42) changing brightness. I wrote a front-end script for gsd-backlight-helper to prevent uid 42 from running the actual binary with the command line option --set-brightness. This doesn't prevent the spam in the logs but it at least allows me to use my laptop. To install this frontend script you can do something like, $ cd /usr/libexec $ sudo mv gsd-backlight-helper gsd-backlight-helper.bin $ sudo mv ~/gsd-backlight-helper . $ sudo chmod +s gsd-backlight-helper One thing I noticed while experimenting with this was that turning on "automatic brightness" in gnome power settings would cause this kind of journal spamming from my user so it would seem that my laptop isn't very good at detecting automatic brightness. If it is true that this is an issue with an automatic brightness setting for user gdm then it might be as simple as disabling that setting for that user, but I'm not sure how to go about doing that at this juncture.
The key for this is /org/gnome/settings-daemon/plugins/power, Enable ALS sensor, ambient light sensor. Unfortunately I didn't find any setting for this in user gdm using, $ dconf dump /org/gnome/
As mentioned by Steven in comment 39, the following command should disable the ambient light sensor: $ sudo bash -c 'echo "blacklist hid_sensor_als" > /etc/modprobe.d/als.conf' and then reboot. This fix has worked for me across several updates until the root issue is addressed.
Unfortunately this tweak from comment 39 doesn't work for me. I still have the journal spamming with calls to gsd-backlight-helper --set-brightness for user gdm, $ cat /etc/modprobe.d/als.conf blacklist hid_sensor_als ... reboot ... $ journalctl -f Oct 25 11:46:30 slim.home pkexec[6083]: pam_unix(polkit-1:session): session opened for user root by (uid=42) Oct 25 11:46:30 slim.home pkexec[6083]: gdm: Executing command [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 402] Oct 25 11:46:32 slim.home pkexec[6095]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session Oct 25 11:46:32 slim.home pkexec[6095]: pam_unix(polkit-1:session): session opened for user root by (uid=42) Oct 25 11:46:32 slim.home audit[6095]: USER_START pid=6095 uid=42 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' Oct 25 11:46:32 slim.home pkexec[6095]: gdm: Executing command [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 449] Oct 25 11:46:33 slim.home pkexec[6106]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session Oct 25 11:46:33 slim.home audit[6106]: USER_START pid=6106 uid=42 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' Oct 25 11:46:33 slim.home pkexec[6106]: pam_unix(polkit-1:session): session opened for user root by (uid=42) Oct 25 11:46:33 slim.home pkexec[6106]: gdm: Executing command [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 449] ...
Note also that, as per comment 46, I have changed the settings to "yes" in, /usr/share/polkit-1/actions/org.gnome.settings-daemon.plugins.power.policy <defaults> <allow_any>no</allow_any> <allow_inactive>yes</allow_inactive> <allow_active>yes</allow_active> </defaults> (changing allow_any to yes seems to be equivalent to changing allow_inactive/allow_active to yes). Without this setting I get the authorization failures discussed at that time. What it all seems to boil down to is: why is user gdm running gsd-backlight-helper? And how can we stop it from doing so?
Another observation, when the screen went to sleep these messages stopped flooding the logs. When I woke it up the journal spam returned.
Looks like the real issue: «why is user gdm running gsd-backlight-helper?» Does not happen on ArchLinux and Debian: [gnumdk@arch ~]$ ps -u gdm|grep backlight [gnumdk@arch ~]$
*** Bug 1510181 has been marked as a duplicate of this bug. ***
FYI, I am having this issue too. I have not tried anything yet. Was wondering if anyone has an update from upstream? thanks
still happening in Fedora 27. Might be worse than ever. Dec 30 08:35:54 slim.home gsd-backlight-helper[17030]: LOGNAME=gdm PKEXEC_UID= : /usr/libexec/gsd-backlight-helper.bin --get-max-brightness : command=--get-max-brightness Dec 30 08:35:54 slim.home pkexec[17032]: gdm: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/var/lib/gdm] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 121] Dec 30 08:35:54 slim.home org.gnome.SettingsDaemon.Power.desktop[16488]: Error executing command as another user: Not authorized Dec 30 08:35:54 slim.home org.gnome.SettingsDaemon.Power.desktop[16488]: This incident has been reported. It seems that everytime --get-max-brightness is called from gsd-power it attempts to set the value, and this is where the pkexec failure comes from I did find a possible culprit in gpm-common.c where it calls gsd-backlight-helper to get the max value and then uses that to compute a percentage value to set it (backlight_set_percentage).
Same issue here. Dell XPS 13 (9333) with Fedora 27.
(In reply to Steeve McCauley from comment #63) > I did find a possible culprit in gpm-common.c where it calls > gsd-backlight-helper to get the max value and then uses that to compute a > percentage value to set it (backlight_set_percentage). Why is gdm doing that while I'm logged in? I can understand gdm playing with brightness while it presents the login dialog. But it should cease thereafter.
Note I've not read all 65 comments, sorry. I believe this may be caused by the auto-brightness adjustment code running on devices with a laptop. Can those of you affected by this run: "monitor-sensor" and see if it reports an ambient light sensor. You may very well have auto brightness adjustments disabled in your user session, but that setting will only affect your user-session and not the gdm session behavior.
Yes, this is probably the reason. MacBookPro11,1 here with a light sensor detected.
Agreed. I have tried to tweak gdm user to disable auto-brightness but without any success. I also detect iio sensor on Asus UX305F. Interestingly, it hasn't been spamming the journal for 2 days now.
just a reminder for everyone suffering w/ this that I have an autostart job that does "systemctl stop iio-sensor-proxy" on startup which prevents me from getting the journalctl messages.
(In reply to Hans de Goede from comment #66) > I believe this may be caused by the auto-brightness adjustment code running > on devices with a laptop. Can those of you affected by this run: > "monitor-sensor" and see if it reports an ambient light sensor. [zaitcev@lembas ~]$ monitor-sensor Waiting for iio-sensor-proxy to appear +++ iio-sensor-proxy appeared === No accelerometer === Has ambient light sensor (value: 112.000000, unit: lux) Light changed: 107.000000 (lux) Light changed: 108.000000 (lux) Light changed: 109.000000 (lux) <------- about 2 times a second > You may very well have auto brightness adjustments disabled in your user > session, but that setting will only affect your user-session and not the gdm > session behavior. Quite so. At this point I'm very afraid that an enterprising developer will say "Ah-ha!" and work around this by adding some hysteresis, so that the brightness change is not happening every second, instead of making it so that gdm is not tinkering with the brightness when a user is logged in.
Simple workaround: - Disable auto brightness in your gnome session - Logout and stop gdm - Copy ~/.config/dconf/user to /var/lib/gdm/.config/dconf/user
A little more complicated workaround that doesn't require overwriting the whole dconf database is to run the following command as "gdm" user: gsettings set org.gnome.settings-daemon.plugins.power ambient-enabled false Unfortunately, this only works with an X11 display, so one needs to temporarily log in as gdm user to do that. I did that by temporarily setting bash as gdm's shell, enabling ssh logins (chmod 750 /var/lib/gdm, adding my ssh key to /var/lib/gdm/.ssh/authorized_keys and setting the correct SELinux context on it).
Reading dconf(7) it looks like there's a better, official way to do this (untested): # cat << __EOF__ >> /etc/dconf/profile/gdm user-db:user system-db:gdm __EOF__ # cat << __EOF__ >> /etc/dconf/db/gdm.d/00-no-ambient [org/gnome/settings-daemon/plugins/power] ambient-enabled=false __EOF__
Unfortunately, the method described in comment #73 doesn't work. I think I'm missing something.
(In reply to Pete Zaitcev from comment #70) <snip> > At this point I'm very afraid that an enterprising developer will say > "Ah-ha!" and work around this by adding some hysteresis, so that the > brightness change is not happening every second, instead of making it > so that gdm is not tinkering with the brightness when a user is logged in. It would be so much easier to debug those problems if the IIO subsystem didn't break on the hardware I have available for months, or years at a time. It was broken between 4.3 and 4.12, and has been broken again a few months afterwards: https://marc.info/?l=linux-iio&m=151136436026918&w=2 Maybe you can do something there, instead of posting passive aggressive blog entries. Fedora 27 scratch builds are available here for those of you who still have working light sensors, I don't: https://koji.fedoraproject.org/koji/taskinfo?taskID=24116653
Bastien, i know exactly what you mean. I couldn't find the root cause for the current problem yet, but i could work around it by using your polling driver instead of the buffered one.
Bastien, Thank you for taking a look at this.
Resetting the needinfo flags, please don't remove it until you've tested the packages mentioned in comment 75.
I'm sorry this was a mistake as the checkbox is ticked on by default. As an excuse my feedback with the above package installed: Only changes for the current user is logged on my tablet, no more gdm messages.
Anyone else?
I "downgraded" to the posted gnome-settings-daemon-3.26.2-1.bug1322588.fc27.x86_64 and rebooted. With this the constant flow of GDM authorisation errors are gone on my ThinkPad X1 Yoga. I also tested by suspending and resuming and the errors did not return. I still think the backlight helper is too aggressive and spamming the journal doing so when changing brightness, but that is another issue...
gnome-settings-daemon-3.26.2-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-bd7652ec93
gnome-settings-daemon-3.24.3-4.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-ba521808e0
(In reply to Robert de Rooy from comment #81) > I "downgraded" to the posted > gnome-settings-daemon-3.26.2-1.bug1322588.fc27.x86_64 and rebooted. With > this the constant flow of GDM authorisation errors are gone on my ThinkPad > X1 Yoga. I also tested by suspending and resuming and the errors did not > return. Thanks for testing. As you've seen, updates are available for f26 and f27, as well as in rawhide. > I still think the backlight helper is too aggressive and spamming the > journal doing so when changing brightness, but that is another issue... It is indeed. Can you please file a bug at: https://bugzilla.gnome.org/enter_bug.cgi?product=gnome-settings-daemon about this? There's some movement/changes happening in that part of the code, but removing the helper altogether might not be feasible. Would be good to figure it out upstream though.
OK, with the test package, I no longer see the messages coming in checking journalctl -f on reboot, then doing a sleep + wake I still don't see the messages (as of yet). For fun I tried actually turning on the "adjust screen brightness" setting to see what that does, as that didn't used to work originally due to other asus/brightness related issues that have been fixed. With auto brightness on, the system is still "working" in that it actually adjusts the brightness too, however it seems to send out a brightness command every second unconditionally even if it is using the same value over and over again, plus it is very erratically bumping the brightness up and down in response to what I suppose is sensor noise, there's apparently no smoothing algorithm helping out, so the automatic brightness feature is still kind of useless and still spams the journal with constant and often repeated commands, however at least we can now turn that off. definitely the first version of this fix that seemed to change things.
gnome-settings-daemon-3.24.3-4.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-ba521808e0
gnome-settings-daemon-3.26.2-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-bd7652ec93
This update has resolved the issue on my Latitude 7350, which I confirmed with journalctl following suspend + resume cycles, compared to before the update was applied.
(In reply to David Ward from comment #88) > This update has resolved the issue on my Latitude 7350, which I confirmed > with journalctl following suspend + resume cycles, compared to before the > update was applied. Thanks for testing. Don't hesitate to add that feedback to the errata that have been filed if you have the opportunity, this will make sure the bug fixes get to users as soon as possible.
gnome-settings-daemon-3.26.2-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
gnome-settings-daemon-3.24.3-4.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
# dnf list all | grep gnome-settings-daemon gnome-settings-daemon.x86_64 3.26.2-2.fc27 @updates gnome-settings-daemon.i686 3.26.2-2.fc27 updates gnome-settings-daemon-devel.i686 3.26.2-2.fc27 updates gnome-settings-daemon-devel.x86_64 3.26.2-2.fc27 updates # tail -n 10 /var/log/messages Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: Error executing command as another user: Not authorized Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: This incident has been reported. Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: Error executing command as another user: Not authorized Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: This incident has been reported. Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: Error executing command as another user: Not authorized Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: This incident has been reported. Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: Error executing command as another user: Not authorized Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: This incident has been reported. Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: Error executing command as another user: Not authorized Apr 30 15:00:36 phoenix org.gnome.SettingsDaemon.Power.desktop[2575]: This incident has been reported. polkitd using ~20% most of the time. Screen brightness changing back and forth all the time in certain light conditions, which is really rather irritating.
I had reported this was fixed, but I'm seeing the behavior again. However, it's the message at the bottom of comment 46 (after the polkit policy file for gnome-settings-daemon was adjusted), rather than the message in comment 1. Is this considered a separate issue? Yesterday it was happening with Fedora 27. Today I wiped the disk and installed Fedora 28; the message can be seen in the journal after the first boot, as soon as gnome-initial-setup launches: May 01 11:05:05 localhost.localdomain /usr/libexec/gdm-x-session[1153]: (II) modeset(0): EDID vendor "SHP", prod id 5151 May 01 11:05:05 localhost.localdomain /usr/libexec/gdm-x-session[1153]: (II) modeset(0): Printing DDC gathered Modelines: May 01 11:05:05 localhost.localdomain /usr/libexec/gdm-x-session[1153]: (II) modeset(0): Modeline "1920x1080"x0.0 138.50 1920 1968 2000 2080 1080 1083 1088 1111 -hsync -vsync (66.6 kHz eP) May 01 11:05:05 localhost.localdomain /usr/libexec/gdm-x-session[1153]: (II) modeset(0): Modeline "1920x1080"x0.0 138.50 1920 1968 2000 2080 1080 1119 1156 1387 -hsync -vsync (66.6 kHz e) May 01 11:05:05 localhost.localdomain dbus-daemon[1162]: [session uid=981 pid=1162] Activating service name='ca.desrt.dconf' requested by ':1.19' (uid=981 pid=1330 comm="/usr/libexec/gsd-wacom " label="system_u: system_r:xdm_t:s0-s0:c0.c1023") May 01 11:05:05 localhost.localdomain dbus-daemon[1162]: [session uid=981 pid=1162] Successfully activated service 'ca.desrt.dconf' May 01 11:05:06 localhost.localdomain pkexec[1501]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session May 01 11:05:06 localhost.localdomain audit[1501]: USER_START pid=1501 uid=981 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' May 01 11:05:06 localhost.localdomain pkexec[1501]: pam_unix(polkit-1:session): session opened for user root by (uid=981) May 01 11:05:06 localhost.localdomain pkexec[1501]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 74] May 01 11:05:06 localhost.localdomain pkexec[1514]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session May 01 11:05:06 localhost.localdomain audit[1514]: USER_START pid=1514 uid=981 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' May 01 11:05:06 localhost.localdomain pkexec[1514]: pam_unix(polkit-1:session): session opened for user root by (uid=981) May 01 11:05:06 localhost.localdomain pkexec[1514]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 74] May 01 11:05:07 localhost.localdomain pkexec[1521]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session May 01 11:05:07 localhost.localdomain audit[1521]: USER_START pid=1521 uid=981 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' May 01 11:05:07 localhost.localdomain pkexec[1521]: pam_unix(polkit-1:session): session opened for user root by (uid=981) May 01 11:05:07 localhost.localdomain pkexec[1521]: gnome-initial-setup: Executing command [USER=root] [TTY=unknown] [CWD=/run/gnome-initial-setup/] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 65] After I create a user account, the messages contian my home directory in CWD instead.
(In reply to David Ward from comment #93) > I had reported this was fixed, but I'm seeing the behavior again. Given this error, this is another problem that's unrelated to gnome-settings-daemon.
Hi, I know this one is closed. I have the same kind of spew in audit.log, and when I grepped ps to see what was calling pkexec I get 32046 tty2 Rl+ 0:00 pkexec /usr/libexec/gsd-backlight-helper --set-brightness 1049 it seems like gsd-backlight-helper is respawning ad nauseum, check this out [root@pandariomh audit]# ps ax | grep pkexec 32046 tty2 Rl+ 0:00 pkexec /usr/libexec/gsd-backlight-helper --set-brightness 1049 32050 pts/3 S+ 0:00 grep --color=auto pkexec [root@pandariomh audit]# ps ax | grep pkexec 32118 tty2 Sl+ 0:00 pkexec /usr/libexec/gsd-backlight-helper --set-brightness 1049 32122 pts/3 S+ 0:00 grep --color=auto pkexec [root@pandariomh audit]# ps ax | grep pkexec 32309 tty2 Sl+ 0:00 pkexec /usr/libexec/gsd-backlight-helper --set-brightness 1049 32311 pts/3 S+ 0:00 grep --color=auto pkexec [root@pandariomh audit]# ps ax | grep pkexec 32395 tty2 Rl+ 0:00 pkexec /usr/libexec/gsd-backlight-helper --set-brightness 1049 32401 pts/3 S+ 0:00 grep --color=auto pkexec [root@pandariomh audit]# ps ax | grep pkexec 32488 tty2 Sl+ 0:00 pkexec /usr/libexec/gsd-backlight-helper --set-brightness 1049 32491 pts/3 S+ 0:00 grep --color=auto pkexec [root@pandariomh audit]# ps ax | grep pkexec 32575 pts/3 S+ 0:00 grep --color=auto pkexec [root@pandariomh audit]# ps ax | grep pkexec 32649 tty2 Sl+ 0:00 pkexec /usr/libexec/gsd-backlight-helper --set-brightness 1049 32653 pts/3 S+ 0:00 grep --color=auto pkexec here's a sample of my audit.log spew type=USER_START msg=audit(1537551862.085:79015): pid=4444 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1537551862.136:79016): pid=4452 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1537551862.183:79017): pid=4459 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' This is on F28, gnome-settings-daemon-3.28.1-1.fc28.x86_64 Any ideas?
and fwiw, i walked away for an hour, came back, there's no gsd-backlight-helper when i grep for it in ps, and tail -f audit.log shows nothing. before tail -f was just a limitless ongoing scroll of the above messages.
Same here, all was fine on Fedora 28 (at one point at least), but after moving to Fedora 29 (fresh install, but copy of home) this problem resurfaces: Nov 04 16:54:07 regulus-milkyway pkexec[17462]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session or user slice Nov 04 16:54:07 regulus-milkyway audit[17462]: USER_START pid=17462 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' Nov 04 16:54:07 regulus-milkyway pkexec[17462]: pam_unix(polkit-1:session): session opened for user root by (uid=1000) Nov 04 16:54:07 regulus-milkyway pkexec[17462]: rene: Executing command [USER=root] [TTY=unknown] [CWD=/home/rene] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 0] Nov 04 16:54:09 regulus-milkyway pkexec[17475]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session or user slice Nov 04 16:54:09 regulus-milkyway audit[17475]: USER_START pid=17475 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' Nov 04 16:54:09 regulus-milkyway pkexec[17475]: pam_unix(polkit-1:session): session opened for user root by (uid=1000) Nov 04 16:54:09 regulus-milkyway pkexec[17475]: rene: Executing command [USER=root] [TTY=unknown] [CWD=/home/rene] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 0] Nov 04 16:54:10 regulus-milkyway pkexec[17482]: pam_systemd(polkit-1:session): Cannot create session: Already running in a session or user slice Nov 04 16:54:10 regulus-milkyway audit[17482]: USER_START pid=17482 uid=1000 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix acct="root" exe="/usr/bin/pkexec" hostname=? addr=? terminal=? res=success' Nov 04 16:54:10 regulus-milkyway pkexec[17482]: pam_unix(polkit-1:session): session opened for user root by (uid=1000) Nov 04 16:54:10 regulus-milkyway pkexec[17482]: rene: Executing command [USER=root] [TTY=unknown] [CWD=/home/rene] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 0]
Can confirm that the problem is back. Fedora 29. I have again blacklist hid_sensor_als to prevent the flood of syslog messages, and 20-30% of continuous CPU usage resulting from failed DBUS messages.
It did not "come back". Those messages aren't errors, they're logging by system components, unrelated to gnome-settings-daemon.