I've run into a strange problem where sometimes, my monitors are forced to DPMS off and moving the cursor or pressing keys does not free it. I suspect this is a bug in my SwayWM configuration or a bug in Swaylock, but it resolves itself if I wait until the device again locks, which causes a second Swaylock instance to appear.
In any case, if you get yourself stuck and need to recover, you might want to be able to run swaymsg remotely. If you do, you might run into strange issues. swaymsg calls sway --get-socketpath to get the IPC socket, which... just returns the value of the SWAYSOCK environment variable. In my case, this also has the funny side-effect of starting a dbus session and SSH agent each time its invoked, because it is calling the NixOS-wrapped SwayWM binary. Probably should patch the NixOS version to explicitly call the unwrapped binary!
In order to recover the SWAYSOCK, one approach that should be relatively easy and does not require root (assuming you don't have a more locked-down system than I do) is to simply scan for other processes that do have a Sway IPC connection and steal it out of their environment. Here's a quick one-liner that does it for swaybg. Thanks to @niklasw for an improved snippet using GNU awk.
export SWAYSOCK=$(gawk 'BEGIN {RS="\0"; FS="="} $1 == "SWAYSOCK" {print $2}' /proc/$(pgrep -o swaybg)/environ)After having done this, swaymsg should work. Now you can, for example, do this:
swaymsg "output * dpms on"
Very useful information, thanks for sharing! :)
I wanted to execute some commands remotely and it's nice that it is so easily doable!
ps. For a quicker method that I can actually remember I decided that I will instead just do the following:
where after hitting tab the shell autocompletes the socket name.
Or, since I'm using powershell core as my default shell, I actually do it like this: