We have a use case where we start q using a custom parameter -port instead of -p. The idea is that after certain conditions are completed we will start listening on the port. We have a timer to check the conditions are completed.
The issue is that when we start q as a background job it terminates as soon as it is idle if it hasn’t opened any connections.
We have come up with several workarounds. Don’t let q be idle by repeatedly checking, start with a dummy port, etc.
Just thought I’d see what the community have to say about this.
We started listening on the original port but blocked incoming connections with a temporary overwrite to .z.pw. When all start up conditions were completed we returned to the original .z.pw.
My only concern is that this is a workaround for an issue that I don’t really understand. Why does a q application require a port to be active to prevent it from sending a zero exit status during idle time?
Perhaps the answer is in your question; if a q process is not actively executing e.g. a script, listening on a port to process some work or connected to stdin (interactive mode), then what is it’s purpose?
From the perspective of the process, there is nothing left to do and thus doesn’t need to be running. That would be my guess as to why this is the default behavior built into the binary.
Perhaps someone closer to core implementation will be able to share more insight.