Help with getting ydotool to work

exup · 2023-04-09 08:03:34

Hi,
I am running Plasma and wayland and want to get ydotool to work.
I have installed it
Added user to the group "input"
Run the service as a user

systemctl --user enable  ydotool.service
systemctl --user start  ydotool.service

but then when I run

ydotool type TESTING
failed to connect socket `/run/user/1000/.ydotool_socket': Permission denied
Please check if the current user has sufficient permissions to access the socket file.

looking at the status of the service it is showing the following

× ydotool.service - Starts ydotoold service
     Loaded: loaded (/usr/lib/systemd/user/ydotool.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sun 2023-04-09 17:55:09 AEST; 6min ago
   Duration: 1ms
    Process: 35418 ExecStart=/usr/bin/ydotoold (code=exited, status=2)
   Main PID: 35418 (code=exited, status=2)
        CPU: 1ms

Apr 09 17:55:09 arhclinuxT14 systemd[740]: ydotool.service: Scheduled restart job, restart counter is at 5.
Apr 09 17:55:09 arhclinuxT14 systemd[740]: Stopped Starts ydotoold service.
Apr 09 17:55:09 arhclinuxT14 systemd[740]: ydotool.service: Start request repeated too quickly.
Apr 09 17:55:09 arhclinuxT14 systemd[740]: ydotool.service: Failed with result 'exit-code'.
Apr 09 17:55:09 arhclinuxT14 systemd[740]: Failed to start Starts ydotoold service.

I am getting a bit lost now as the git-hub site mentions ydotoold needs to be running as well?

Trilby · 2023-04-09 13:40:14

You need to run the service as systemwide/root not as a user-service.

exup · 2023-04-09 23:15:58

I read in the wiki that it had to be run as a user service see here Automations

Automation
ydotool (ydotool) - Generic command-line automation tool (not limited to wayland). Enable/start the ydotool.service user unit. See ydotoold(8), ydotoold(1).

Regardless I had already tried it as a system wide service but see below.

systemctl --user disable  ydotool.service

sudo systemctl enable  ydotool.service
Failed to enable unit: Unit file ydotool.service does not exist.

I searched in "/usr/lib/systemd/system" for a ydotool.service but nothing is there.
There is one in "/usr/lib/systemd/user/" as a test I just copied that into the system directory, seems odd that this is not documented?
Now the service starts ok.

But I still have to run the command as "sudo" is it possible to run it as normal user?

● ydotool.service - Starts ydotoold service
     Loaded: loaded (/usr/lib/systemd/system/ydotool.service; enabled; preset: disabled)
     Active: active (running) since Mon 2023-04-10 09:01:28 AEST; 6min ago
   Main PID: 40448 (ydotoold)
      Tasks: 1 (limit: 36973)
     Memory: 172.0K
        CPU: 1ms
     CGroup: /system.slice/ydotool.service
             └─40448 /usr/bin/ydotoold

Apr 10 09:01:28 arhclinuxT14 systemd[1]: Started Starts ydotoold service.

ydotool click 0xC0
failed to connect socket `/run/user/1000/.ydotool_socket': Connection refused
Please check if ydotoold is running.

sudo ydotool click 0xC0
c0 110 (executes correctly)

dogknowsnx · 2023-04-10 11:38:23

man newgrp

?

yttrium · 2023-04-22 13:01:30

Make sure ydotool is properly installed and the systemwide service is enabled and started. ydotool and ydotoold need root permissions to access the devices.

Running ydotool with sudo obviously is not practical, and hardly feasible in very likely circumstances, i.e., in scripts launched from shortcut keys. There will be better practices than that, but I solve this by setting the setuid bit on the executable:

sudo chmod +s $(which ydotool)

Then, ydotool started as user looks for the socket "/run/user/1000/.ydotool_socket" but the daemon as a systemwide service listenes to /tmp/.ydotool_socket. To make that work, you can link to the socket expected by ydotoold ("ln -s /tmp/.ydotool_socket /run/user/1000/.ydotool_socket"), but a way more elegant approach (in my opinion, that is), is to set the YDOTOOL_SOCKET variable during login: "YDOTOOL_SOCKET=/tmp/.ydotool_socket", e.g. in the bash profile file or systemwide.

galvez_65 · 2023-04-22 14:34:14

I don't know your use case but I found dotool (https://git.sr.ht/~geb/dotool) simpler to use than ydotool

yttrium · 2023-04-23 16:11:51

I was not aware of this tool, thanks!

yttrium · 2024-04-08 13:32:50

I (only now) moved to dotool!

It is indeed a lot easier to use, allowing key names instead of codes, and not requiring to explicitly indicate pressing a key then releasing a key. This very much reduces the friction to create a quick ad-hoc keyboard macro to automate a repeating task. I also find it performs very reliably.

Another asset is that no pause is required when triggering a script through a shortcut key. Thus, macros can start instantaneously. It does not matter if you are still holding down shortcut keys when the script started.

db47h · 2026-04-03 11:07:48

Sorry about the gravedigging but just I ran into this issue and found an actual working solution that, I think, is compliant with Arch's current security policies and does not require adding the user to the input group. For reference, https://wiki.archlinux.org/title/Users_ … emd_groups mentions that users should not be added to the input group but that the devices should be marked with the uallow tag in udev instead.

The solution is to rename /usr/lib/udev/rules.d/80-uinput.rules to /usr/lib/udev/rules.d/70-uinput.rules (see https://wiki.archlinux.org/title/Udev#A … e_devices) and add the uaccess tag:

KERNEL=="uinput", GROUP="input", MODE="0660", OPTIONS+="static_node=uinput", TAG+="uaccess"

then reload udev (as root):

# udevadm control --reload-rules && udevadm trigger

Finally, log out from your session so that logind applies the new acls.

Once logged back in, check that the ydotool user service is running

systemctl status --user ydotool

and that the proper ACLs have been applied to /dev/uinput (notice the two "user:" lines in the output):

$ getfacl /dev/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: input
user::rw-
user:YOU:rw-
group::rw-
mask::rw-
other::---

EDIT: there's a bug report that suggests using another user group. Using the above solution also addresses the security issue mentioned in this report.

Last edited by db47h (2026-04-03 11:16:50)

WorMzy · 2026-04-03 12:08:02

Thanks for sharing, I'll go ahead and close this old thread now.

Arch Linux

#1 2023-04-09 08:03:34

Help with getting ydotool to work

#2 2023-04-09 13:40:14

Re: Help with getting ydotool to work

#3 2023-04-09 23:15:58

Re: Help with getting ydotool to work

#4 2023-04-10 11:38:23

Re: Help with getting ydotool to work

#5 2023-04-22 13:01:30

Re: Help with getting ydotool to work

#6 2023-04-22 14:34:14

Re: Help with getting ydotool to work

#7 2023-04-23 16:11:51

Re: Help with getting ydotool to work

#8 2024-04-08 13:32:50

Re: Help with getting ydotool to work

#9 2026-04-03 11:07:48

Re: Help with getting ydotool to work

#10 2026-04-03 12:08:02

Re: Help with getting ydotool to work

Board footer