Failed to send command to swhks through IPC.

[evesdropper]

Version Information:

• Distribution Information ( run uname -a ): Linux revise-arch 6.0.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 08 Dec 2022 11:03:38 +0000 x86_64 GNU/Linux
• swhkd version ( swhkd -V ): swhkd 1.2.1

Describe the bug: A clear and concise description of what the bug is.

None of the keypresses work - error code 2: failed to send command to swhks through IPC.

Expected behavior: A clear and concise description of what you expected to happen.

Upon pressing a hotkey keypress, the function should activate - e.g. Prnt takes a screenshot.

Actual behavior: A clear and concise description of the behavior.

Nothing happens, and this is the output log:

[2022-12-16T05:34:59Z ERROR swhkd] Failed to send command to swhks through IPC.
[2022-12-16T05:34:59Z ERROR swhkd] Please make sure that swhks is running.
[2022-12-16T05:34:59Z ERROR swhkd] Err: Os {
        code: 2,
        kind: NotFound,
        message: "No such file or directory",
    }

To Reproduce: Steps to reproduce the behavior.

Start swhkd:

swhks &
sudo pkexec swhkd --device "AT Translated Set 2 keyboard" --device "Compx 2.4G Wireless Receiver"  # added sudo to bypass silly pkexec thing which requests for authentication even when I changed settings, worked fine previously.

Additional information: Anything else you'd like us to know?

This happened after changing shell to zsh, so at first I thought it was a zsh issue, but it persists even after changing shell back to bash.

[Shinyzenith]

Hi, I think the policy file on your system was removed leading to the authentication problems. Can you try reinstalling swhkd once?

Regarding the failed to send over ipc, can you get us the swhks logs?

[evesdropper]

The policy file appears to still be there, though I edited some of the permissions since it would ask for password manually each time I restarted my WM.

Some logs I think that might be relevant - a majority of the log files were empty:

(zenity:17846): dbind-WARNING **: 12:54:29.962: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/1000/at-spi/bus: No such file or directory

(swappy:17870): dbind-WARNING **: 12:54:38.243: Couldn't connect to accessibility bus: Failed to connect to socket /run/user/1000/at-spi/bus: No such file or directory

[Shinyzenith]

We don't interact with at-spi accessibility bus so those logs are not relevant. Would you mind sharing the version information of your polkit installation?

[evesdropper]

Output of pacman -Q | grep "polkit":

polkit 122-1
polkit-gnome 0.105-9
polkit-qt5 0.114.0-1

[Shinyzenith]

I have figured out the problem. Since you are using sudo pkexec , the PKEXEC_UID env var is being set to 0 and hence its looking for swhks sock file in /run/user/0/.... So the first course of action would be to get pkexec working with our policy file and drop sudo usage.

Can you send the output of which swhkd?

[evesdropper]

Ahh I see. Policy file default asks for authentication which is pretty annoying, and the only way around it I have found to have "worked" is with sudo. I also did try changing the settings to "yes" for all actions (which I believe meant no authentication) but that also prompted me for authentication.

Output of which swhkd: /sbin/swhkd.

[Shinyzenith]

This is the source of the problem. which swhkd should point to /usr/bin/swhkd else the policy file won't take effect and skip authentication. It should be removed from sbin.

@ajanon do you think we can automatically change the path in policy file with make according to some variable such as BIN_PATH etc? That will remove this problem entirely where swhkd might get installed in different directories.

[ajanon]

We already have a TARGET_DIR path in our Makefile, we should be able to do this automatically.

Tentative implementation (in install target):

--- a/Makefile
+++ b/Makefile
@@ -25,6 +25,7 @@ install:
        @touch /etc/$(DAEMON_BINARY)/$(DAEMON_BINARY)rc
        @cp ./target/release/$(DAEMON_BINARY) $(TARGET_DIR)
        @cp ./target/release/$(SERVER_BINARY) $(TARGET_DIR)
+       @sed -i 's#/usr/bin/swhkd#$(TARGET_DIR)/$(DAEMON_BINARY)#' $(POLKIT_POLICY_FILE)
        @cp ./$(POLKIT_POLICY_FILE) $(POLKIT_DIR)/$(POLKIT_POLICY_FILE)
        @chmod +x $(TARGET_DIR)/$(DAEMON_BINARY)
        @chmod +x $(TARGET_DIR)/$(SERVER_BINARY)

Alternatively, we could have a small script generating the policy file:

#!/bin/bash
declare -r SWHKD_PATH="$1"

cat << EOF > com.github.swhkd.pkexec.policy
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
  <action id="com.github.swhkd.pkexec">
    <message>Authentication is required to run Simple Wayland Hotkey Daemon</message>
    <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">${SWHKD_PATH}</annotate>
  </action>
</policyconfig>
EOF

We could then call it in the Makefile:

build:
  ./build-policy-file $(TARGET_DIR)/$(DAEMON_BINARY)

Both seem fine to me, I don't have a strong preference for one or the other.

Side note: our PKGBUILD should probably use our Makefile.

[ajanon]

Much better implementation for the Makefile:

--- a/Makefile
+++ b/Makefile
@@ -25,6 +25,7 @@ install:
        @touch /etc/$(DAEMON_BINARY)/$(DAEMON_BINARY)rc
        @cp ./target/release/$(DAEMON_BINARY) $(TARGET_DIR)
        @cp ./target/release/$(SERVER_BINARY) $(TARGET_DIR)
+       @sed -i 's#\(<annotate key="org.freedesktop.policykit.exec.path">\).*\(</annotate>\)#\1$(TARGET_DIR)/$(DAEMON_BINARY)\2#' $(POLKIT_POLICY_FILE)
        @cp ./$(POLKIT_POLICY_FILE) $(POLKIT_DIR)/$(POLKIT_POLICY_FILE)
        @chmod +x $(TARGET_DIR)/$(DAEMON_BINARY)
        @chmod +x $(TARGET_DIR)/$(SERVER_BINARY)

This one will work even if the in the policy file has already been changed.

[Shinyzenith]

I already thought of the above but sed -i is a gnu extension to sed and not portable. The script you demonstrated seems better.

[ajanon]

I am very surprised to learn that this flag is not part of POSIX!

Should I change the script to be POSIX-compliant too? As-is, it is not and should only work on bash.

[Shinyzenith]

That would be great, yep!

[ajanon]

I will submit a PR later then!

[Shinyzenith]

Thank you ❤️

[ajanon]

184 and #185 should help in avoiding this kind of issue in the future.

Unless @Shinyzenith has any better idea, I unfortunately don't see a way out of your troubles except cleaning up all swhkd related stuff and reinstalling once the above two PRs get merged (and the AUR package gets updated).