I’ve noticed some strange behaviour since doing a dnf update a few days ago. I have LACT running automatically using Autostart, but I’m now being asked for authentication to run the app as sudo. I also tried launching it indirectly by running an Autostart script with sleep 5 flatpak run io.github.ilya_zlobintsev.LACT to see if it was something with launching the app, but I still get the prompt. What’s strange is that if I delete the Autostart and manually launch the application after logging in I do not get prompted for any authentication. I do not think this is an issue with LACT because it hasn’t been updated in 15 days, and I didn’t notice the issue with the latest update until the aforementioned very recent system-wide update.
Has anyone else noticed issues with Autostart applications recently? F43, KDE 6.6.2, kernel 6.19.6-200.
I don’t use this app, but just looking at its documentation:
LACT uses a system daemon to interact with the GPU and manage configuration. For access to hardware and system settings the daemon needs to run as root.
When you run the flatpak and the daemon is not detected, you will get a prompt to install it outside of the sandbox. This will automatically set up and start the system service. It is installed at /etc/systemd/system/lactd.service.
Just guessing, but maybe there’s some kind of race condition here? When you launch it manually, the daemon is already running, so no permissions prompt. But maybe Autostart runs it before the daemon has a chance to start up, therefore the app thinks it has to reinstall the daemon, which needs superuser permissions.
But then, your sleep 5 doesn’t seem to make any difference, so I don’t know.
I think you’re correct because using sleep 30 consistently solves this. The systemd file has After=multi-user.target which hasn’t changed in 5 months (according to their GitHub) so I’m unsure why it’s happened recently. Thanks for this. I’ll do some more digging to see how long it takes to start the service on boot.
That’s seems odd; I sould have though that The After= is the problem.
You could try adding a systemd override to remove that setting and see if ther fixes the problem.
Use systemctl edit <service> to create and manage the override.
Add After= should clear the After setting.
I only just put the two together, but since that update the time taken between entering my LUKS password to reaching the login screen has dropped by ~7 s to ~9 s. If I stay on the login screen for at least 7 s I consistently do not get prompted. So it seems that the (admittedly fantastic) reduction in time to reach the login screen has uncovered this race condition. I can verify this because running systemctl status lactd after logging in as quick as possible shows that it is disabled, but is enabled a few seconds later.
