p2p listen keep job running

[Hazematman]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

It would be nice if ipfs p2p listen kept a process running in the foreground or had an option to leave a process running in the foreground. This way you could add it to a systemd service for example to have it automatically forward connections when a machine turns on or when it connects to the internet.

I'm not sure how kubo handles p2p listens in the background and if it tries to keep it running if connectivity drops or if the daemon shutdown.

[amias-channer]

i recently wondered about this and in my application i resolved to just use the rpc api to control the listeners

you can get systemd to run

curl -X POST "http://127.0.0.1:5001/api/v0/p2p/listen?arg=&arg=&allow-custom-protocol=&report-peer-id="

its documented here
https://docs.ipfs.tech/reference/kubo/rpc/#api-v0-p2p-listen

[Hazematman]

I'm sort of doing something similar. I wrapped launching the ipfs daemon with a script and that script will start the listen after the daemon comes up. My concern was more around if the listen fails for some reason. To check if it fails the only method I know of is the to check with p2p ls and then restart it. In my use case I want the listen to run when the machine starts up forever basically.

[lidel]

You can write your own scripts with CLI or curl talking to HTTP Kubo RPC API, as noted in #11087 (comment), but having a flag that keeps p2p tunnel in foreground, and shuts it down when command exits makes sense for scripting and services like systemd.

I had a PoC for this very thing in a local branch, this issue motivated me to finish it:

• feat(p2p): add --foreground flag to listen and forward commands #11099

Would be very useful if you've built that PR and tested ipfs p2p listen --foreground + comment on that PR.

[Hazematman]

@lidel Thanks, I tried that PR and it seems to work! Reading the code there a bit though I realized that the forwarding/listening is managed all through the daemon. Will the daemon keep the forwarding/listening running if the ipfs connection is lost and then reconnects? If so I think this feature might not be needed for my use case. I can just add a oneshot systemd job.

My main concern was making sure the p2p listen is relaunched if for some reason it dies.

[lidel]

@Hazematman thats the point of --forgeround (to give you visibility and full control).

If you don't pass it, then the tunnel will work as long daemon is running or until someone ipfs p2p close it. You will not know when it breaks without active probing. If you pass --foreground, then you will see when tunnel breaks (due to any reason, manual close, process being killed, or daemon shutting down).