ReimuNotMoe / ydotool

Generic command-line automation tool (no X!)
GNU Affero General Public License v3.0
1.44k stars 79 forks source link

Needs sudo before each command #241

Open vdegenne opened 3 months ago

vdegenne commented 3 months ago

I enabled the service:

systemctl enable ydotool

But when I reboot, and try running ydotool ... I get the following:

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

The only way to get rid of this issue is to use sudo before every command, but now I can't use ydotool in scripts because the shell interupts the program asking for the password (which makes sense).

Versions:

cyber-sushi commented 3 months ago

If you launch ydotoold as a system service, you need to specify the directory and owner of its socket so that the ydotool executable can connect to it

Launch the daemon with the following arguments: --socket-path="<your_home>/.ydotool_socket" --socket-own="<your_user_id>:<your_group_id>"

g-h-97 commented 3 months ago

@cyber-sushi same issue here as well, the problem is that ydotool unlike ydotoold does not support socket path it's hard-coded to /run/user/.ydotool_socket so I had to set the path to that while starting the daemon.

Paiusco commented 3 months ago

@g-h-97 ydotool does support you defining the socket path, it actually queries for an env var named YDOTOOL_SOCKET. It only goes for the "hardcoded" one if you don't define the envvar

@vdegenne I'd like to ask you to check who is the owner of the socket? Please post the output of: ls -l <socket_path>, so I can try to help you out.

I'm considering that you don't have access to the socket, as it's by default owned by root... so you can change that, changing the ownership of the ydotoold socket creation. Using the --socket-own= parameter when starting the daemon (you can change this on the .service file)

I think this is issue is repeating itself too much, we should make in a way that ydotoold runs as root, opens the socket already considering the user ownership somehow.... maybe making it #230 can improve that, but I'm not completely sure, it has to be a better way

g-h-97 commented 3 months ago

@Paiusco , thanks for the heads-up. Still there is the issue of the service getting added as a "user" instead of a "system" service,

Paiusco commented 3 months ago

@g-h-97 not necessarily (even tho for now that forces you to recompile it), this was addressed at #237.

So you can make the service as a system with a CMake option, or if you don't want to recompile you can just move the file to the system location and systemd will consider it a system service instead