Colorful ways to run things as root after the user logs in?

looking to run a root script post-login to set nvidia-smi -pl to 80, but pointing /etc/lightdm/lightdm.conf sessionsetupscript= to a script with this command just… doesn’t seem to actually run any command from the script at all?
I told it to spit out a terminal, and it wouldn’t even do that much.
It breaks the login process if it doesn’t point to anything, but if it does, it just doesn’t seem to run whatever it points to. The script it’s self works, if manually run after logging in. I’d wager it also works fine if run from another session. The values don’t reset on login or logout afaik, but might during the boot process in general.

Running a cronjob @restart also doesn’t seem to work, and I’d like to avoid setting power limits every however many minutes.

At a loss for what to do.

Does it matter if you take a while to log in, and the script starts in the background?

Maybe you could add a “sleep” to the script, then create a systemd service to run it?

Not sure there is a way to check for logged in users, but the system can run the script every 3 mins (180 secs?)

You might also find this useful,
Even though you aren’t setting a resolution, you might pay attention to answer 11, part of which starts:

14.04 and above

Falconer’s answer helped me very much, but lightdm changed for Ubuntu Trusty 14.04. There is no longer a
/etc/lightdm/lightdm.conf file on my system. lightdm has now gone the “Debian way” and had its configuration broken up into a conf.d directory. You now need to create the following file:


display-setup-script=xrandr -o right

As suggested in [Electric Head]> ('s answer, the xrandr command can go right in this file, no need to create a separate script.

Sorry, I forgot to specify I’m using Manjaro/Arch with XFCE.
Unfortunately, I can no longer edit the OP with this information.

Have you checked the archwiki?
Like if you make the script into a service,

apparently I already tried at one point
I just messed around with it again, and it also doesn’t seem to work unless started manually post-login. checking the status of the service has the command logged, but the tdp is still set to the default after logging in.

Setuid - can’t do it direct to the script, but if it’s just a sequence of commands, you can make up a very simple C program, compile it, and then set it up with the right ownership for setuid to handle it.

Sudo - I’m fairly sure you can configure sudo to allow a command to run as root without prompting for passwords. Use extreme caution - anyone with permission to edit your script has access to root.

SSH to localhost with passwordless keys - Rube Goldberg style solution.

Best practice these days with any systemd distribution would be to write a .service file. The philosophy here is that because you write and enable the service as root, that it is happy to run as root. As long as you write it into /etc/systemd/system/ and enable it with sudo.
Read up here:

I tried with SystemD, and the status says the command was run but it doesn’t do anything for some reason. Just sets right back to default TDP before I can get to the desktop.

Digging into C is a bit much for me right now, but I’ll look into it if I get desperate.
It looks like Setuid might work on it’s own, though, if I give the user permission to run nvidia-smi as root and use something else to issue the command when the desktop loads?

Could you post your script and .service file so I can see what’s wrong with it?

Description="Set nVidia Power Limit"

ExecStart=/usr/bin/nvidia-smi --id=1 -pl 100.0 


The script has changed a dozen or more times to try and get it to work with something or other, right now it’s just nvidia-smi -i 1 -pl 80 and run manually via sudo ~/pwrcfg
I tried adding sleep before, when trying to run it via lightdm, but that didn’t help.

next time I restart, I’ll try to remember to grab the status of the service before I set the power limits.

If you change to it should run when the x server starts. If you enable it while inside x then it will run right away and you can check it’s status with ‘systemctl status example.service’

Same as before.
I’ve also tried as well.