Automatically appropriote socket when dangling socket is found?

[Ambrevar]

By default when Nyxt crashes and the socket is left behind, it won't be possible to start Nyxt again without deleting the dangling socket.

But do we really need to be that "polite"? We could very well just check if anyone is listening on the socket and if not, appropriate it. I don't see how it could cause any trouble.

@aadcg @aartaka @jmercouris

[aartaka]

Yes, that would also likely solve lots of instances of Nyxt "mysteriously" not starting :D

[Ambrevar]

Oh, actually this is what we've already been doing for a while.

@jmercouris You told me Nyxt refuses to start up if a dangling socket is there. But I can't reproduce. @aartaka Same question to you, in which case exactly is nyxt "mysteriously" not starting?

Recipe:

• Start Nyxt, the shell log should show

  [10:47:42] Listening to socket: #P"/run/user/1000/nyxt/nyxt.socket"

• SIGKILL Nyxt.

• Check that the aforementioned socket file still exists.

• Start Nyxt again.

[aartaka]

@Ambrevar, in my case force-killing (kill-window command in StumpWM; there should be something like this in EXWM too) hanged (meaning some problem on renderer thread) Nyxt is guaranteed to leave a socket behind, and this socket is guaranteed to mess up Nyxt starting properly.

[Ambrevar]

Try pkill -KILL nyxt instead.

Are you sure that the process is gone? Maybe it's a zombie that still holds the socket.

How does it "mess up" the start up? Can you report the shell output?

[aartaka]

Try pkill -KILL nyxt instead.

But then, window system killing should be mostly equivalent to process destruction. I'm pretty sure there's some X server handler we can hook into to properly destroy all the dangling things...

Are you sure that the process is gone? Maybe it's a zombie that still holds the socket.

No, not sure. Some WebKit processes stay, for one.

How does it "mess up" the start up? Can you report the shell output?

It messes up by simply not starting and saying that "Nyxt already started" :D

[Ambrevar]

Then you are not really killing Nyxt. Try with pkill -KILL, it should make a difference.

But then, window system killing should be mostly equivalent to process destruction. I'm pretty sure there's some X server handler we can hook into to properly destroy all the dangling things...

We cannot anticipate how the program will terminate, it's the halting problem... ;)

At least not from Nyxt's side. I'm not aware of a X feature that we can hook into, but should we do that, this would be a remote process instruction.

[jmercouris]

It doesn't matter whether the program is being cleanly killed or not. Somehow someway the program can't start, and the user is frustrated :-D

[jmercouris]

If Artyom and myself are making this mistake, I am sure many others are as well. I frequently use my WM to kill a misbehaving program rather than exec'ing pkill xyz.

[Ambrevar]

The reason I'm asking is not because "the user is making a mistake", but because I can't reproduce it, and I'd like to understand the difference.

Ever since we programmed Nyxt to appropriate the socket, Nyxt has never failed to start on my end.