Solved timeout hangs whereas gtimeout does not (for certain scripts)

I have a script that updates domain blocks for coredns and restarts coredns once done. If I invoke the script from the CLI, it completes quickly and exits. If I use the /usr/bin/timeout to invoke it, it hangs until the timeout is reached and exits with status 124. If I invoke it with gtimeout (gnu coreutils' timeout), it completes the same as if I invoke it directly.

I suspect it has something to do with the command perhaps redirecting stdin / stdout, but can't seem to find the culprit. At the end of the main script, I added a logger statement that says it reached the end. That log is written to syslog, but the script continues to hang until the timeout duration.

I tried using /bin/sh instead of /usr/bin/env bash, but that also had no impact.
 
If I use the /usr/bin/timeout to invoke it, it hangs until the timeout is reached and exits with status 124.
It doesn't "hang", it's simply waiting for the timeout (or the invoked command to exit). As for the status:

Code:
     If the timeout was reached and --preserve-status is set, the exit status
     of command is returned. If --preserve-status is not set, an exit status
     of 124 is returned.
timeout(1)
 
I found the culprit, if I invoke a service command within the script, that hangs:


service coredns restart

Even though that returns immediately, and subsequent commands after that are invoked (such as my logger statements), removing this command allowed the script to exit.

My script is essentially this:

Code:
#!/usr/bin/env bash

# lock invocation (prevent concurrent executions)
# aggregate domain blocks
# write updated /etc/hosts
# restart coredns
service coredns restart
# unlock

After service coredns restart, I had a logger statement just to help debug and I could see that it too was invoked nearly immediately after restarting coredns. Then, the command would wait before being killed. Oddly enough, if I use gtimeout (from gnu coreutils), I don't have any issues.

How can I restart coredns without blocking the script from exiting?
 
Ah, good catch, yes, I think you're right, but now (for my own edification), if I were to invoke any other subprocess here, then if that subprocess would take longer than the timeout, then this script would still exit without killing that one?
 
Yes, you're perfectly right, for these, I have already refactored them to /bin/sh locally. I just always used that across the board and am now cleaning that up to be more aware of dependencies.
 
Back
Top