Automatically running a command that requires sudo after suspend

General Linux Question
1

some possibly helpful specs: bodhi linux 5.1 (based on ubuntu 18.04) on a thinkpad w540 (i7, 16 gigs o’ ram) with a synaptics branded touchpad and the synaptics input driver installed.

my issue is almost identical to the one posted here. in brief, my touchpad doesn’t work correctly when i wake my system up from suspend. i decided to open a new thread to explore one possible solution. i have tried other unsuccessful methods and can expand on them if need be, but figured i would save making anyone wade through possibly unhelpful details if possible.

the functionality that i lose is that if i keep one finger on the keypad and drag another across it to and highlight text or files in a file manager (which i apparently do often enough that its loss is usually noticeable within 10 minutes after waking my system), the second finger is ignored and the highlight action does not occur. keeping one finger on the pad and dragging it does highlight, but is limited to how far my finger can move and is more complicated to pull off in general. neither lsmod, xinput nor synclient list any differences between the state of the touchpad before or after suspending. luckily i found a similar solution to the one in the post linked above. after i modprobe the entire psmouse array (sudo modprobe -r psmouse - the array includes my touchpad and a couple of other components) and then back on i can highlight as explained.

it doesn’t take much of an effort to run an alias to wake the pad back up correctly with modprobe, but after reading some suggestions and other threads like this one both here and on other sites i have attempted unsuccessfully to get the system to run the two modprobe commands. the crux of the question (as i see it after spending what feels like way too much time staring at this situation) at this stage is:

when a command that my user needs to run with sudo is placed in a file in /lib/systemd/system-sleep does it make a difference to the system if i add sudo to the command in that file?

i have done so both ways, rebooted the system and there was no difference. one link suggested that the commands should be in a separate file. another said that my commands needed to added to the hdparm file in that directory in order to run with administrative rights.

none of those options worked so i began to wonder (it feels like i am overthinking things and over-analyzing the smallest details at this point, but thought i would post the question and see) is if i needed to an exception in the sudoers file so that the command could be run with sudo but without needing a password entered.

it may help to note that libinput is also installed, but has never affected synaptics functionality on a similar (t430s) system though that system doesn’t suffer from this malfunction after waking from suspend.

i have considered that there might possibly be some conflict between the two, but don’t know enough about what libinput does to decide removing it would be the solution. i could definitely try that, but wanted to see if it was possible to get they system to modprobe (which definitley works) itself since i had spent so much time tinkering with that particular option :slight_smile:

thanks in advance if anyone has any thought.

2

You need to run the command as root.

If you need to use sudo in a script, then it is always for running it as a different user. When someone is new to Linux they always get told by everyone “oh, if you want to run this as admin, just prepend sudo to your command!”. However, that is only half the truth of sudo. This command exists, to run a single command as another user on the system. It just happens to be the case, that root is the most requested user on any operating system, that is why sudo defaults to root when you don’t provide any arguments.

Now what you are theoretically doing when using sudo is this:

sudo -u root mycommand

That’s what sudo is for.
For this reason, sudo is used interactively most of the time. In a script, you just should run the script as root and adjust permissions with chown and chmod afterwards, if you need to.

Now, if you need to run your command as yourself, you would do this in a script like this:

if [[ "$EUID" != 0 ]]; then echo "Please run me as root."; exit 1; fi;
sudo -u myself mycommand

You can also just run the script as yourself, of course, but that is only handy, if everything in that script can be run by yourself and does not need any root permissions.

If you need to run it as root, as it is usually the case, you would do this:

if [[ "$EUID" != 0 ]]; then echo "Please run me as root."; exit 1; fi;
mycommand

Long story short, just run the script as root. This is usually needed anyway, for global changes, like loading a kernel module or something of that sorts. Normal user permissions are usually only suitable for stuff that only applies to the user who is the creator of those normal user permissions. Which means, nobody else on the system should be concerned with that.

2 Likes
3

thank you for your very informative and helpful answer.

this part

reminds me of when i was first reading about a lot of the basic commands to try and figure out what they do and why or how. one article was partly about what the “su” in sudo stood for. one option was superuser because (as you explained) most people associate it with root, but another was “secondary (or substitute) user” since you can use it to authenticate as any other user. the article didn’t declare one to be more or less correct than the other since apparently there was no historical documentation (if i am remembering correctly and if the article was factually sound) as to exactly what it stood for.

i will continue to reread and digest the second half of your post to get a better idea of what i need to do next. i just wanted to add that bit and say a quick thanks for the info.

1 Like
4

thank you again @Akito for the help and direction. it turns out the basis of my question (though well-intentioned i believe) was ill-formed. the reality in the end wasn’t about my personal user running the command. since the system was running them on resume, it was simply a matter of where those commands (and possibly the form used? function and /sh vs. /bash and separate sequential commands?) were placed: Lenovo Ideapad S340 touchpad inactive after resume