Bug 1322588 - endless brightness / backlight error messages in journalctl
Summary: endless brightness / backlight error messages in journalctl
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rui Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1359481 1510181 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-30 19:55 UTC by Michael Bayer
Modified: 2019-02-21 08:54 UTC (History)
39 users (show)

Fixed In Version: gnome-settings-daemon-3.24.3-3.fc26 gnome-settings-daemon-3.26.2-2.fc27 gnome-settings-daemon-3.24.3-4.fc26
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-16 17:17:32 UTC
Type: Bug


Attachments (Terms of Use)
gsd-backlight-helper frontend script (1.07 KB, text/plain)
2017-10-23 11:18 UTC, Steeve McCauley
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 756539 None None None 2019-03-19 19:47:09 UTC
GNOME Bugzilla 764896 None None None 2019-03-19 19:47:09 UTC
GNOME Bugzilla 772537 None None None 2019-03-19 19:47:09 UTC
GNOME Bugzilla 773685 None None None 2019-03-19 19:47:09 UTC
GNOME Bugzilla 792409 None None None 2019-03-19 19:47:09 UTC

Description Michael Bayer 2016-03-30 19:55:32 UTC
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.

Comment 1 Michael Bayer 2016-03-31 18:23:02 UTC
looks like this was fixed in 3.18.3, verifying now that it works...

Comment 2 Michael Bayer 2016-03-31 18:34:24 UTC
nope, the patch from the upstream bug is present but the issue persists.   I'll try to get their attention on the upstream.

Comment 3 Michael Bayer 2016-04-11 16:03:26 UTC
additional upstream bug added w/ new patch

Comment 4 Stephen 2016-05-28 11:09:11 UTC
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.

Comment 5 Michael Bayer 2016-06-14 03:27:21 UTC
still happening in F24.

Comment 6 Michael Bayer 2016-07-21 14:39:05 UTC
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.

Comment 7 Michael Bayer 2016-07-21 14:51:54 UTC
false alarm, the problem resumes once the desktop resumes the screen from inactivty.

Comment 8 Pete Zaitcev 2016-10-17 16:53:38 UTC
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.

Comment 9 Michael Bayer 2016-10-17 17:05:00 UTC
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).

Comment 10 Michael Bayer 2016-10-31 13:40:51 UTC
progress, more activity upstream

Comment 11 Adrien Bustany 2016-11-28 09:24:24 UTC
Still happening in Fedora 25 too, but I don't have the rights to edit the bug to reflect that.

Comment 12 Robert de Rooy 2017-01-16 17:07:59 UTC
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.

Comment 13 Bastien Nocera 2017-01-16 17:59:39 UTC
This is an upstream bug.

Comment 14 Bastien Nocera 2017-01-16 18:02:05 UTC
*** Bug 1359481 has been marked as a duplicate of this bug. ***

Comment 15 David Ward 2017-05-08 19:32:48 UTC
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

Comment 16 David Ward 2017-05-08 20:28:06 UTC
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.

Comment 17 Robert de Rooy 2017-05-26 17:17:30 UTC
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

Comment 18 Michael Bayer 2017-05-26 18:03:56 UTC
issue is not fixed in gnome-session 3.22.3, can confirm here as well

Comment 19 Cédric Bellegarde 2017-05-30 16:36:29 UTC
Same here, Fedora 26

Comment 20 Boyd 2017-06-02 11:15:35 UTC
Same here, Fedora 26

Comment 21 Fedora Admin XMLRPC Client 2017-06-08 11:31:43 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 22 Tim Flink 2017-07-19 19:53:58 UTC
I'm also seeing this with updated F26 on a gen1 lenovo thinkpad x1 yoga

Comment 23 René Kraneis 2017-07-22 17:09:28 UTC
I'm also seeing this with F26 installation media on a 1st generation Lenovo Thinkpad X1 Yoga (OLED)

Comment 24 Robin Lee 2017-07-24 13:42:15 UTC
Still happening on Lenovo Thinkpad X1 Tablet.

Comment 25 Eric Kerby 2017-08-07 05:09:36 UTC
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).

Comment 26 mrummuka 2017-08-20 11:26:46 UTC
Also happens with Fedora 26 & Asus UC305CA.

Comment 27 René Kraneis 2017-08-21 15:25:58 UTC
I can confirm #25 - logging out and back in again seems to resolve this issue. For how long I was unable to determine.

Comment 28 David Ward 2017-08-21 16:13:24 UTC
(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.

Comment 29 Eric Kerby 2017-08-26 16:59:53 UTC
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

Comment 30 mrummuka 2017-08-26 18:13:40 UTC
"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.

Comment 31 Bastien Nocera 2017-08-28 11:29:32 UTC
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.

Comment 32 Eric Kerby 2017-08-29 04:29:56 UTC
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

Comment 33 Bastien Nocera 2017-08-29 11:01:11 UTC
(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...

Comment 34 Robert de Rooy 2017-08-29 15:55:58 UTC
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.

Comment 35 Eric Kerby 2017-08-31 01:16:14 UTC
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

Comment 36 Fedora Update System 2017-09-01 11:53:03 UTC
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

Comment 37 Robert de Rooy 2017-09-02 07:40:06 UTC
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.

Comment 38 Martin Dengler 2017-09-02 13:53:03 UTC
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)

Comment 39 Stephen 2017-09-02 14:31:28 UTC
A workaround is:

$ sudo bash -c 'echo "blacklist hid_sensor_als" > /etc/modprobe.d/als.conf'

Reboot.

Comment 40 Fedora Update System 2017-09-03 22:19:29 UTC
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.

Comment 41 Michael Bayer 2017-09-04 23:19:00 UTC
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]

Comment 42 Antti Kaihola 2017-09-16 08:00:29 UTC
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.

Comment 43 Boyd 2017-09-23 21:33:23 UTC
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

Comment 44 Steeve McCauley 2017-09-23 22:55:13 UTC
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.

Comment 45 Antti Kaihola 2017-09-26 16:07:37 UTC
(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

Comment 46 Antti Kaihola 2017-09-26 16:30:47 UTC
(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]

Comment 47 Steeve McCauley 2017-09-26 16:55:05 UTC
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.

Comment 48 Steeve McCauley 2017-09-26 17:05:02 UTC
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.

Comment 49 Steeve McCauley 2017-09-26 17:05:17 UTC
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.

Comment 50 Pete Zaitcev 2017-09-29 16:39:36 UTC
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

Comment 51 Michael Bayer 2017-09-29 17:27:16 UTC
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.

Comment 52 Erik Indresovde 2017-10-15 16:37:34 UTC
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.

Comment 53 Cédric Bellegarde 2017-10-23 08:27:04 UTC
Same issue on Fedora 27.

Comment 54 Steeve McCauley 2017-10-23 11:18:06 UTC
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.

Comment 55 Steeve McCauley 2017-10-23 11:33:22 UTC
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/

Comment 56 Eric Kerby 2017-10-24 01:21:21 UTC
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.

Comment 57 Steeve McCauley 2017-10-25 15:50:34 UTC
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]
...

Comment 58 Steeve McCauley 2017-10-25 16:00:57 UTC
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?

Comment 59 Steeve McCauley 2017-10-25 16:03:38 UTC
Another observation, when the screen went to sleep these messages stopped flooding the logs.  When I woke it up the journal spam returned.

Comment 60 Cédric Bellegarde 2017-10-25 16:06:21 UTC
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 ~]$

Comment 61 Rui Matos 2017-11-15 17:50:45 UTC
*** Bug 1510181 has been marked as a duplicate of this bug. ***

Comment 62 jvapr27 2017-12-17 18:31:27 UTC
FYI, I am having this issue too. 

I have not tried anything yet. Was wondering if anyone has an update from upstream? 

thanks

Comment 63 Steeve McCauley 2017-12-30 14:01:15 UTC
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).

Comment 64 Dominik 'Rathann' Mierzejewski 2018-01-02 21:38:04 UTC
Same issue here. Dell XPS 13 (9333) with Fedora 27.

Comment 65 Pete Zaitcev 2018-01-02 23:20:12 UTC
(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.

Comment 66 Hans de Goede 2018-01-04 09:32:08 UTC
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.

Comment 67 Adrien Bustany 2018-01-04 11:02:40 UTC
Yes, this is probably the reason. MacBookPro11,1 here with a light sensor detected.

Comment 68 Steeve McCauley 2018-01-04 12:31:17 UTC
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.

Comment 69 Michael Bayer 2018-01-04 15:00:48 UTC
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.

Comment 70 Pete Zaitcev 2018-01-04 15:58:17 UTC
(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.

Comment 71 Cédric Bellegarde 2018-01-05 16:05:52 UTC
Simple workaround:
- Disable auto brightness in your gnome session
- Logout and stop gdm
- Copy ~/.config/dconf/user to /var/lib/gdm/.config/dconf/user

Comment 72 Dominik 'Rathann' Mierzejewski 2018-01-07 16:47:55 UTC
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).

Comment 73 Dominik 'Rathann' Mierzejewski 2018-01-07 17:31:20 UTC
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__

Comment 74 Dominik 'Rathann' Mierzejewski 2018-01-07 17:54:11 UTC
Unfortunately, the method described in comment #73 doesn't work. I think I'm missing something.

Comment 75 Bastien Nocera 2018-01-10 17:27:28 UTC
(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

Comment 76 Jan-Michael Brummer 2018-01-10 17:46:07 UTC
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.

Comment 77 Hans de Goede 2018-01-10 18:45:13 UTC
Bastien, Thank you for taking a look at this.

Comment 78 Bastien Nocera 2018-01-11 10:32:55 UTC
Resetting the needinfo flags, please don't remove it until you've tested the packages mentioned in comment 75.

Comment 79 Jan-Michael Brummer 2018-01-11 10:51:30 UTC
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.

Comment 80 Bastien Nocera 2018-01-11 15:10:54 UTC
Anyone else?

Comment 81 Robert de Rooy 2018-01-11 22:28:47 UTC
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...

Comment 82 Fedora Update System 2018-01-12 15:53:42 UTC
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

Comment 83 Fedora Update System 2018-01-12 16:00:53 UTC
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

Comment 84 Bastien Nocera 2018-01-12 16:18:04 UTC
(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.

Comment 85 Michael Bayer 2018-01-13 21:43:04 UTC
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.

Comment 86 Fedora Update System 2018-01-14 01:04:02 UTC
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

Comment 87 Fedora Update System 2018-01-14 01:38:54 UTC
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

Comment 88 David Ward 2018-01-14 22:01:37 UTC
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.

Comment 89 Bastien Nocera 2018-01-15 14:11:34 UTC
(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.

Comment 90 Fedora Update System 2018-01-16 17:17:32 UTC
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.

Comment 91 Fedora Update System 2018-02-06 10:47:09 UTC
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.

Comment 92 Georg Greve 2018-04-30 13:10:23 UTC
# 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.

Comment 93 David Ward 2018-05-01 18:31:58 UTC
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.

Comment 94 Bastien Nocera 2018-05-30 13:51:02 UTC
(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.

Comment 95 Máirín Duffy 2018-09-21 17:45:16 UTC
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?

Comment 96 Máirín Duffy 2018-09-21 19:56:46 UTC
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.

Comment 97 René Kraneis 2018-11-04 15:56:05 UTC
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]

Comment 98 Robert 2019-02-20 18:02:50 UTC
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.

Comment 99 Bastien Nocera 2019-02-21 08:54:15 UTC
It did not "come back". Those messages aren't errors, they're logging by system components, unrelated to gnome-settings-daemon.


Note You need to log in before you can comment on or make changes to this bug.