Zombie sockets left behind

[lalomartins]

Split off from #4 (comment)

Issue: if the daemon closes/crashes, sockets are left behind, and then it will refuse to start because the sockets exist.

Possibly only happens on Windows, due to the different way Windows implements sockets.

Possible workaround/fix:

• If trying to start/daemonize and the socket exists:
  • Attempt to connect to the socket and query status
  • If no response, assume zombie socket, delete, and take over

Keeping a pidfile might be an idea too, but I feel querying the socket might be simpler.

[quexten]

This is the behaviour on all platforms. But in my windows vm, the sockets get replaced on daemon restart. Still, I agree that this behaviour can be improved.

[quexten]

For Windows / SSH this should not apply anymore since we use the openssh named pipe now. (The goldwarden socket itself does still apply though).

[quexten]

Could you post the logs when the daemon "refuses to start"? Checking the code it should forcefully delete the existing socket, even if there is still a daemon listening there.

[lalomartins]

Would the log from 0.2.10 still be useful to you even if the code changed so much in the meantime?

I didn't really want to set up a Go dev environment to build it myself 😹 but I can if it would help.

[lalomartins]

~\Programs> .\goldwarden.exe daemonize
[INF] [09:30] [Goldwarden > Keyring] >>> Creating new memguard keyring
[WRN] [09:30] [Goldwarden > Agent] >>> Config is not locked. SET A PIN!!
listen error listen unix C:\Users\Lalo/.goldwarden.sock: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
panic: listen unix C:\Users\Lalo/.goldwarden-ssh-agent.sock: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

goroutine 23 [running]:
github.com/quexten/goldwarden/agent/ssh.SSHAgentServer.Serve({0xc000144000?, 0xc000104340?, 0xc00013e000?, 0xc00012a450?})
        D:/a/goldwarden/goldwarden/agent/ssh/ssh.go:198 +0x474
created by github.com/quexten/goldwarden/agent.StartUnixAgent
        D:/a/goldwarden/goldwarden/agent/unixsocketagent.go:258 +0xb93
~\Programs> ps goldwarden
Get-Process: Cannot find a process with the name "goldwarden". Verify the process name and call the cmdlet again.

(Adding a screenshot too for the sake of colorized output)

In contrast, this is what it looks like if I delete the sockets:

Worth of note: I haven't actually tried to run Goldwarden today before taking the first screenshot, so possibly the zombie sockets survived even a system reboot? I'll test later and let you know.

After running it successfully (second screenshot), stopping it with ctrl-C still leaves the sockets behind. Trying to run it again after that goes back to the top of the loop.

[quexten]

Possibly fixed in:
https://github.com/quexten/goldwarden/actions/runs/7770571485

[quexten]

I didn't really want to set up a Go dev environment to build it myself 😹 but I can if it would help.

You can download the binary from the github ci actions, no need to set up a dev environment.

[quexten]

To even log in at all, you need a newer version than you are running (such as the one I linked above), and install GPG4Win (https://gpg4win.org/download.html) to get the pinentry working.

[lalomartins]

Got it, I'll give it a shot. Already have GPG4Win here.

[lalomartins]

~\Programs> .\goldwarden.exe daemonize
[INF] [10:10] [Goldwarden > Keyring] >>> Creating new memguard keyring
[WRN] [10:10] [Goldwarden > Agent] >>> Config is not locked. SET A PIN!!
[FATAL] [10:10] [Goldwarden > SSH] >>> listen error:%!(EXTRA *fs.PathError=open \\.\pipe\openssh-ssh-agent: Access is denied.)

I'm not sure about that pipe path. Maybe it's looking for an env variable I don't have? Should I have openssh agent running or stopped?

[quexten]

The openssh agent should be stopped in services.msc , the pipe path look correct.

[lalomartins]

Ok. The service is stopped (it has been for a while, as I was using 1password's). I also stopped 1password's agent, but no change. For science, I even quit 1password completely, but still no go.

The path is correct? Where is it trying to create the pipe? “Access is denied” might indicate it's trying to create it somewhere my user doesn't have write permission, which is something that could conceivably be different between my setup and your test VM.

[quexten]

Hmm, so my VM is a fresh Windows 10 Home install. The socket is from the 1Password docs, and works (at least in my VM):

[lalomartins]

Hm. I think I found the issue. I had OpenSSH on “manual” instead of “disabled”, and something was starting it 🤔 with that out of the way, Goldwarden could start, set pin, and log in.

More importantly, closing it and running it again worked fine, so I can confirm this bug is fixed on Windows. 🎉

[quexten]

Thanks for testing and reporting!