Very slow response of brightness controls in gnome

I also tested this with Ubuntu 18.10 and it worked like a charm.

So, all in all I have tested the same in:

  1. Fedora 29 (gnome 3.30)
  2. Ubuntu 18.10 (gnome 3.30)
  3. Up to date Arch linux with gnome 3.30 installed (both with and without gdm)
  4. Latest Manjaro Gnome Edition with every provided kernel

In some cases I tested it under wayland and under xorg. The only distro having the reported problem (very slow pkexec execution, at least for the reported use case) is Manjaro.

I think I will wait for the next release (with the upcoming gnome 3.32) and keep using arch meanwhile. But I don't believe this will be magically fixed because it's not clear that is a kernel or gnome or arch issue that will vanish because of upstream updates. Evidence is against Manjaro so most probably the problem is related to Manjaro specific configuration or addons instead.

In which gitlab project should I file a bug?

Try to remove the manjaro-gdm-theme and reinstall gnome-shell ...

Ok, but why do you think that might be related to slow execution of pkexec (at least when calling brightness controls)?

Because of few inconsistencies i encountered, also for Audio Volume, other sliders, when using some themes.


but there are other post as yours too

I'm trying to make sense of it, as other users do not have this behavior and brightness works fine, but there are some particular instances, like yours and those mentioned, that do have a problem.
My guess, if was a polkit thing, all users should have the issue ...

Probably related:

Have you found a solution yet? I have the same issue but in my case it is exaggerated even more because every brightness change is executed twice on my system.


So the delay doubles.

Sadly this is still happening in [Testing] Manjaro Gnome 18.1.0 Juhraya pre2 ISO, which is keeping me from installing Manjaro.

It's not a minor bug and I haven't found something similar in months in:

  1. Ubuntu 19.04.
  2. Fedora 30.
  3. Arch Linux daily updated since I reported this.

It's clearly a bug in Manjaro Gnome edition.

Bug is still present in RC1 and also reproducible in Manjaro Budgie. Any news how to fix it?

@mmplx and @anon81571404 please can you test if this pkg fix the issue?

sudo pacman -U http://linux.rz.rub.de/archlinux/extra/os/x86_64/polkit-0.116-2-x86_64.pkg.tar.xz

Report back please.

Can confirm bug still present on Manjaro 18.04 + Gnome 3.32.2, tried the acpi_backlight kernel option with all possible values but unfortunately it didn't help.

@Ste74 tried the package you suggested - sadly the issue still persists.

Laptop is a Dell XPS 15 9570 4K.

Hi @Ste74, I have the same issue with slow brightness controls and other apps wher pkexec is used.

The easiest way to test is:

~ >>> time sudo pkexec echo "1"
1
sudo pkexec echo "1" 0.41s user 0.24s system 98% cpu 0.661 total

I have tried the newer polkit you suggested above but the bug is still there.

I have traced the command above (before trying new polkit), and it seems there is an endless loop of file operations which cause the delay:

clock_gettime(CLOCK_REALTIME, {tv_sec=1564437418, tv_nsec=192998854}) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1564437418, tv_nsec=193319811}) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1564437418, tv_nsec=193631934}) = 0
clock_gettime(CLOCK_REALTIME, {tv_sec=1564437418, tv_nsec=194109182}) = 0
futex(0x7f500cce6a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 7
write(7, "\1\0\0\0\0\0\0\0", 8)         = 8
write(6, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x55563d1a7030, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55563d1a6d40, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55563d19d078, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=7, events=POLLIN}], 1, -1)    = 1 ([{fd=7, revents=POLLIN}])
read(7, "\1\0\0\0\0\0\0\0", 16)         = 8
poll([{fd=7, events=POLLIN}], 1, -1)    = 1 ([{fd=7, revents=POLLIN}])
read(7, "\1\0\0\0\0\0\0\0", 16)         = 8
clock_gettime(CLOCK_MONOTONIC, {tv_sec=20680, tv_nsec=277077310}) = 0
futex(0x7f500cce6a48, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(7, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x55563d1e32b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
close(7)                                = 0
getuid()                                = 0
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024*1024, rlim_max=1024*1024}) = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
fcntl(7, F_SETFD, FD_CLOEXEC)           = -1 EBADF (Bad file descriptor)
fcntl(8, F_SETFD, FD_CLOEXEC)           = -1 EBADF (Bad file descriptor)
fcntl(9, F_SETFD, FD_CLOEXEC)           = -1 EBADF (Bad file descriptor)
fcntl(10, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(11, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(12, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(13, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(14, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(15, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(16, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(17, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(18, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(19, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(20, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(21, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(22, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
fcntl(23, F_SETFD, FD_CLOEXEC)          = -1 EBADF (Bad file descriptor)
*** goes on until
fcntl(1048556, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048557, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048565, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048566, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048567, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048568, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048569, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048570, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048571, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048572, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048573, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048574, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
fcntl(1048575, F_SETFD, FD_CLOEXEC)     = -1 EBADF (Bad file descriptor)
stat("/etc/pam.d", {st_mode=S_IFDIR|0755, st_size=678, ...}) = 0
openat(AT_FDCWD, "/etc/pam.d/polkit-1", O_RDONLY) = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=155, ...}) = 0
read(7, "#%PAM-1.0\n\nauth       include   "..., 4096) = 155
openat(AT_FDCWD, "/etc/pam.d/system-auth", O_RDONLY) = 8
fstat(8, {st_mode=S_IFREG|0644, st_size=441, ...}) = 0
read(8, "#%PAM-1.0\n\nauth      required  p"..., 4096) = 441

Please find the full strace here (https://transfernow.net/73kb84s24zky) and let me know if you have any idea!

Looking at the code, it seems to be due to a loop through all file descriptors (see https://github.com/freedesktop/polkit/blob/master/src/programs/pkexec.c#L256)

Here is another strace with fnctl ignored and timestamps, you can see there is a 20s delay where that loop is running (https://transfernow.net/3593e1v4esj3)

I saw that on my system ulimit is set pretty high, : ~ >>> ulimit -n
1048576

Not sure that should be an issue - maybe i have a bigger I/O problem?

BTW, the limit is set when installing steam:

/etc/systemd/user.conf.d/40-fd-limits.conf

# Alter FD limis: is needed by Steam Play esync
[Manager]
DefaultLimitNOFILE=1048576

Update:
I've changed the limit to 1024, this improves the lag a lot, but it does not disappear completely. However the pkexec lag seems gone

~ >>> time sudo pkexec echo "1"
1
sudo pkexec echo "1" 0.05s user 0.02s system 89% cpu 0.082 total

Update #2:

Submitted issue to polkit: https://gitlab.freedesktop.org/polkit/polkit/issues/87

I have the same issue. let me know if there is any debug info i can supply to help fix this. Im running Manjaro gnome wayland on a Razer Blade Stealth. All function keys work fine and quickly except brightness. Changing the brightness from the slider in the settings screen is instant, only the keys are slow

Hi @kynrai if you want to check whether the issue is related to the max number of open files, check the setting with 'ulimit -n'. It was 1048576 and the delay is much better when the setting is back to 1024.

Interesting.. i don't have steam installed now so i never see this issue ..
btw you can provide a patch like the canonical iteration for fd to test in our packages?

Thanks, that did lower the lag a bit. Still some there but its a lot better to work with. Its still clearly a bug, and supports the debugging others have done related to the looping through file descriptors in part of the code.

Its a shame, this only seems to affect gnome as KDE was fine. Sometimes we need high file descriptor limits, like watching code repos for auto rebuild etc.

I can try to do that over the week end, it does not look to hard but it has been years since I've done some linux development :slight_smile:

Take your time and ping me when ready.. :+1:

Hey - I am seeing the same issue..
Shame that this has been on for so long now..

I am having the same issue on both of my ThinkPad E580 and ThinkPad X250. The delay isn't too bad though, maybe a second or two, I can live with that.

It worked on XFCE, now I am on Gnome (X11).

I'd offer help, but reading through the thread I doubt I'd be of much use.

Forum kindly sponsored by