Error: "Failed to connect to socket: Connection refused (os error 111)"

[clemencyworld1]

Hello,
Thanks for this application. I installed it according to the readme instruction and added the command "swww init && swww IMG /path/to/image/file" to background command in wayfire.ini. when I logged out and logged in again it didn't work. I separated the two commands and it still did not work.

So I decided to try the command in the terminal and it worked. But after rebooting it didn't work again even in terminal giving the above error message. I can't figure out what went wrong or how to go about debugging.

I also noticed that the error keeps repeated while the command is active. Any help is appreciated.

Thanks

[LGFae]

Hi!

But after rebooting it didn't work again even in terminal giving the above error message.

I believe you forgot to paste the error itself? At least I can't find it in your comment.

I can't figure out what went wrong or how to go about debugging.

You could try running swww init --no-daemon in a terminal, and then sending the images from another one. This will let you see any warnings or errors reported by swww (though admittedly, the messages aren't that great sometimes).

---

EDIT: AH, my bad. I read this in a hurry and didn't notice the error is literally in the title.

[LGFae]

"Connection Refused" would imply that the socket exists, but no one is listening to it. This would mean that the daemon exited unexpectedly and left the socket file behind.

Can you please confirm if:

1. the file swww.socket exists in $XDG_RUNTIME_DIR (or /tmp/swww if that variable is not set)
2. the daemon is, in fact, not running despite the file existing
3. if you delete the file, and then try initing the daemon again, does it work?

[clemencyworld1]

Sorry, I uninstalled it after some tries. I will install it again when chanced so I can check your suggestions

[clemencyworld1]

Yes, the socket was there. I deleted it, restarted it again and it's working. Rebooted and it stopped working.

For now, I will have to delete it either on logout or bootup for it to work.

[LGFae]

I have a few ideas of what might be happening. Wayfire should send a SIGTERM during exit to all child processes. If it isn't doing that, and is sending SIGKILL instead, that could explain this behavior. Though, I am not sure of this as I haven't looked at Wayfire's code yet.

[Ivordir]

If it helps, I am running sway and having the same issue.
I can confirm that:

1. swww.socket exists
2. the daemon panics despite the file existing:

⮞ swww init --no-daemon
thread 'main' panicked at 'Couldn't bind socket: Os { code: 98, kind: AddrInUse, message: "Address already in use" }', src/daemon/mod.rs:345:37
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

⮞ swww init
Error: "Failed to connect to socket: Connection refused (os error 111)"

3. deleting the file and re-initializing the daemon works

[LGFae]

@Ivordir that's expected behaviour. swww should never leave behind the swww.socket file. The fact that it does is what's weird.

Because there should only be one swww.socket file at a time, associated with running daemon, trying to init the daemon twice will fail because we see that the socket already exists, which would imply another instance is already running. I should probably improve the error message to make this more explicit.

Now, one way we could try to get around this is doing the following:

1. check if the socket exists
   1.1 if it doesn't, init the daemon normally
   1.2 if it does, check to see if there is an instance of swww actually running
   • 1.2.1 if there isn't, delete the file ourselves and continue initialization (this would fix your problem)
   • 1.2.2 if there is, exit with a good, descriptive error message

[Ivordir]

@Horus645 thanks for clarification.

I just tested your SIGTERM vs SIGKILL theory, and I think it's right. SIGTERM works as intended, but sending SIGKILL leaves the socket file. So, I think what you described may be the best solution to this.

I'm still figuring out how/why SIGKILL is sent on sway exit, reboot, etc.

[Ivordir]

I've figured out the reason: swww crashes if started too early when the window manager launches.
I.e. sleep 1 before auto starting swww.
I don't think there's much to be done about that; it will vary from user to user and wm to wm.
Still, the solution mentioned before would be a nice workaround and quality of life improvement.
Maybe a warning should be given for whenever 1.2.1 happens?

[luigir-it]

Hi, I don't understand if the patch was supposed to fix this, but I still need to add sleep 1 before swww init, otherwise the daemon doesn´t start.

[LGFae]

No, I don't think we there's much we can do regarding the compositor itself. The compositor must be up and properly running before swww can start. What I "fixed" was the case of a leftover socket when the daemon crashed unexpectedly because of that.

[MythicalNewt]

Been experiencing the same
output of journalctl:

Feb 12 23:22:48 ethereal-pc systemd-coredump[60763]: [🡕] Process 60761 (swww-daemon) of user 1000 dumped core.

                                                 Stack trace of thread 60761:
                                                 #0  0x00007f11c37cb8ec n/a (libc.so.6 + 0x878ec)
                                                 #1  0x00007f11c377cea8 raise (libc.so.6 + 0x38ea8)
                                                 #2  0x00007f11c376653d abort (libc.so.6 + 0x2253d)
                                                 #3  0x0000555f677f77d7 n/a (swww-daemon + 0x607d7)
                                                 #4  0x0000555f677f77c6 n/a (swww-daemon + 0x607c6)
                                                 #5  0x0000555f67832606 n/a (swww-daemon + 0x9b606)
                                                 #6  0x0000555f67834912 n/a (swww-daemon + 0x9d912)
                                                 #7  0x0000555f67834584 n/a (swww-daemon + 0x9d584)
                                                 #8  0x0000555f678344ec n/a (swww-daemon + 0x9d4ec)
                                                 #9  0x0000555f678344c1 n/a (swww-daemon + 0x9d4c1)
                                                 #10 0x0000555f677a3ee2 n/a (swww-daemon + 0xcee2)
                                                 #11 0x0000555f677dd246 n/a (swww-daemon + 0x46246)
                                                 #12 0x0000555f677bfa53 n/a (swww-daemon + 0x28a53)
                                                 #13 0x0000555f677e392c n/a (swww-daemon + 0x4c92c)
                                                 #14 0x00007f11c3767790 n/a (libc.so.6 + 0x23790)
                                                 #15 0x00007f11c376784a __libc_start_main (libc.so.6 + 0x2384a)
                                                 #16 0x0000555f677a69e5 n/a (swww-daemon + 0xf9e5)
                                                 ELF object binary architecture: AMD x86-64

Feb 12 23:22:48 ethereal-pc systemd[1]: systemd-coredump@6-60762-0.service: Deactivated successfully.

swww.socket exists at $XDG_RUNTIME_DIR, even after removing it and running $ swww init
the Error: "Failed to connect to socket: Connection refused (os error 111)" is returned

If i run $ swww init --no-daemon the error returned is:

WARNING: socket file /run/user/1000/swww.socket was not deleted when the previous daemon exited
thread 'main' panicked at '[SCTK] A missing global was required: zwlr_layer_shell_v1', /home/shreyas/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.16.0/src/environment.rs:193:21
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Hope this helps

[LGFae]

[SCTK] A missing global was required: zwlr_layer_shell_v1, this would indicate the problem is your compositor does not implement the wlr-layer-shell protocol. Are you using a compositor based on wlr-roots?

[KaniDev]

Had this issue on Arch, couldn't solve it at all (even when killing all the processes by hand and deleting the socket), what fixed it for me watch switching to the binary release on the AUR instead of building current source.

No issues since then, apart from the transition starting point being incorrect when using the button in waybar

[KenChv]

another method rm -rf ~/.cache/swww/* has solved the question.

[Kojuma04]

I still get the same error on NixOS with Hyprland, though only when I have my drawing tablet connected.
I tried to delete the cache or the socket, both didn't help.
ERROR message after running RUST_BACKTRACE=full swww init --no-daemon:

02:44:27 [INFO] (main) Initialization succeeded! Starting main loop...
thread 'main' panicked at 'internal error: entered unreachable code: Iterators of zip_eq have different sizes: 3686400, 921600', /build/source/utils/src/comp_decomp.rs:207:9
stack backtrace:
   0:     0x55ec876f72df - <unknown>
   1:     0x55ec876bd73e - <unknown>
   2:     0x55ec87708514 - <unknown>
   3:     0x55ec876f6f8f - <unknown>
   4:     0x55ec877086ef - <unknown>
   5:     0x55ec87709301 - <unknown>
   6:     0x55ec876f76a4 - <unknown>
   7:     0x55ec876f7606 - <unknown>
   8:     0x55ec87708bc1 - <unknown>
   9:     0x55ec876751f2 - <unknown>
  10:     0x55ec876a3f24 - <unknown>
  11:     0x55ec876b3056 - <unknown>
  12:     0x55ec876918f3 - <unknown>
  13:     0x55ec876ba2c1 - <unknown>
  14:     0x7fb771c04ace - __libc_start_call_main
  15:     0x7fb771c04b89 - __libc_start_main@@GLIBC_2.34
  16:     0x55ec87677d65 - <unknown>
  17:                0x0 - <unknown>