Process unresponsive to SIGINT

[btwiuse]

This bug was discovered on the master branch after the merge at 9d149fa3cbba11f2985fbc8e42cd2cf6b9a679f7

Using ./examples/echo to reproduce, first set libp2p to the problematic version, the process can't be killed with ctrl-c

[root@railway echo]# go get github.com/libp2p/go-libp2p@9d149fa3cbba11f2985fbc8e42cd2cf6b9a679f7 
go: upgraded github.com/libp2p/go-libp2p v0.33.1-0.20240321170946-39242a499ce6 => v0.33.1-0.20240321171834-9d149fa3cbba
[root@railway echo]# go run . -l 1234
2024/05/06 21:56:06 I am /ip4/127.0.0.1/tcp/1234/p2p/QmRvs2Uj3rkx9RUbawDPSTDkM6og4C4A4RtB15xdXjwSB9
2024/05/06 21:56:06 listening for connections
2024/05/06 21:56:06 Now run "./echo -l 1235 -d /ip4/127.0.0.1/tcp/1234/p2p/QmRvs2Uj3rkx9RUbawDPSTDkM6og4C4A4RtB15xdXjwSB9" on a different terminal
^C^C^C

Now downgrade libp2p to its parent commit, the process gets interrupted as expected

[root@railway echo]# go get github.com/libp2p/go-libp2p@39242a499ce6fcd64dd414b504f538ab329b87fc
go: downgraded github.com/libp2p/go-libp2p v0.33.1-0.20240321171834-9d149fa3cbba => v0.33.1-0.20240321170946-39242a499ce6
[root@railway echo]# go run . -l 1234
2024/05/06 22:02:58 I am /ip4/127.0.0.1/tcp/1234/p2p/QmZELJtUuWc255ytkFrPHSqEfpGJyJxZVswLRa2aEPVcoW
2024/05/06 22:02:58 listening for connections
2024/05/06 22:02:58 Now run "./echo -l 1235 -d /ip4/127.0.0.1/tcp/1234/p2p/QmZELJtUuWc255ytkFrPHSqEfpGJyJxZVswLRa2aEPVcoW" on a different terminal
^Csignal: interrupt

[MarcoPolo]

This issue is that uber fx (a dependency we have to construct the host) will register their own signal handler even if we stop the host.

We should be able to fix this once this issue is resolved: uber-go/fx#1197

As a workaround your program can listen for sigint.

[richard-ramos]

@MarcoPolo I ran into this issue recently.
I tried with latest go-libp2p commit which uses uber-go/fx v1.22.0 which should contain the fix to uber-go/fx#1197 yet the process is still unresponsive to SIGINTs :(

[MarcoPolo]

Did you stop the host and then do ctrl-c? Can you share a repro?

[richard-ramos]

I can try to extract an example!
I'm confused tho, shouldn't it be the other way around? i.e. having the Ctrl+C being the one that triggers the host stop?

[MarcoPolo]

Yeah. I think you're right.

I thought the issue here was that even if the host was stopped we still failed to stop on ctrl-c. But you're right, we should stop the host on ctrl-c as well. The original issue in this thread still fails because the example doesn't stop the host. I'll make that fix now.