Fresh install: several issues. (Touchpad behaves strangely, performance issues)

Got a new error now:

Oct 25 17:31:59 nona-dynabookportegex50g systemd[1]: Started My Excellent Go Touchpad Service.
Oct 25 17:32:00 nona-dynabookportegex50g sudo[1483]: pam_systemd_home(sudo:auth): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Oct 25 17:32:00 nona-dynabookportegex50g sudo[1483]: pam_unix(sudo:auth): conversation failed
Oct 25 17:32:00 nona-dynabookportegex50g sudo[1483]: sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
Oct 25 17:32:00 nona-dynabookportegex50g sudo[1483]: pam_unix(sudo:auth): auth could not identify password for [nona]
Oct 25 17:32:02 nona-dynabookportegex50g sudo[1483]: sudo: a password is required
Oct 25 17:32:08 nona-dynabookportegex50g systemd[1]: driver.service: Main process exited, code=exited, status=1/FAILURE
Oct 25 17:32:08 nona-dynabookportegex50g systemd[1]: driver.service: Failed with result 'exit-code'.

Crap, it does ask for a password.
Allow yourself to sudo that program passwordless in /etc/sudoers (or even better, a new file in /etc/sudoers.d/):

nona nona-dynabookportegex50g = (root) NOPASSWD: /usr/local/bin/main

(assuming nona is your username and nona-dynabookportegex50g the hostname)

edit:
careful with typos!
use sudo visudo to edit the main sudoers (it will check the syntax before replacing the original).

uh, what do i name the file in /etc/sudoers.d? what extension? editing sudoers just gives me a .tmp file and it doesnt get overwritten

You can call it whatever you want, no extension.


edit:
Strange you get that .tmp, perhaps it did not accept that syntax (did I give wrong advice? It happens...)
Hold on, let me check. I'd say man sudoers at this point but it's not easy reading indeed.

I still get a password prompt... really unsure what to do :S
I have no clue why there's so many roadblocks, but then running for the terminal returns no errors.

Permissions probably.
chown root:root /etc/sudoers.d/your-file then chmod 440 /etc/sudoers.d/your-file (you’ll have to sudo chmod it again if you need to edit it).


On a side note, I don’t know if it’s relevant for your case, but I saw this comment while reading the kernel bug report above:

Booting with psmouse.synaptics_intertouch=1 prevents the garbage events from being produced whenever the AccuPoint is touched.

It won’t make the buttons work, but perhaps helps with the misbehavior.
Worth trying I think.


edit:
for some reason I’m not getting it to work either, and my brain is on low battery :sleeping: :zzz: :sheep: :sheep: :sheep:

1 Like

Oh dear…I’m afraid we’ve gotten into the weeds a bit here. The Sudoers file should not have to be edited to make a systemd service run, that just can’t be right.

Running the process as a user running sudo does not make any sense to me. systemd runs stuff as root by default, and sudo is the user-equivalent of running a process as root. So what is happening here is:

Rootrunning asUserrunning asRoot:face_with_spiral_eyes:

Root should be able to run this program with no issues. To confirm, open up the terminal and log in as root by entering this command:

su

You will have to enter the root password. This may be the same as your user password (the one you enter to use sudo), but not necessarily so. The root password should have been set during installation.

Once you are root, run the command.

main

If it works, then I don’t think it is a user-related issue.

I can’t help thinking maybe the program is still launching too early. Try to add After=graphical.target to the bottom of the [Unit] piece, like this:

[Unit]
Description=My Excellent Go Touchpad Service
After=graphical.target

[Service]
Type=simple
ExecStart=/usr/local/bin/main

[Install]
WantedBy=graphical.target

That should at least hold off until the display manager is up before trying to run the program. If that is still to early, I think the next thing to try would be to scrap the system unit altogether and get a user unit set up: systemd/User - ArchWiki

Take a peek in /usr/lib/systemd/user/, you will find a lot of programs you probably recognize are deployed this way.

I’ve never set one up before, and as you can see the Wiki is a little dense here, but the benefit of setting up a unit this way is it will deploy after the user is logged in to the session. If the Go program you made needs a resource that is not available until you are logged in to work, then that is what we should do.

4 Likes