Here is the problem: # ./busybox timeout --help BusyBox v1.27.2 (2017-12-10 11:45:39 +07) multi-call binary. Usage: timeout [-t SECS] [-s SIG] PROG ARGS Runs PROG. Sends SIG to it if it is not gone in SECS seconds. Defaults: SECS: 10, SIG: TERM. # LANG=C timeout --help Usage: timeout [OPTION] DURATION COMMAND [ARG]... or: timeout [OPTION] Start COMMAND, and kill it if still running after DURATION. I think that better way is to use first arg as timeout if -t option is not specified (and ignore -k option that missing in busybox timeout).
It's more than just the missing options. coreutils timeout seems to require --foreground, when the command wants to read from the tty,... busybox' doesn't (it's able to do so with no action). Should anyone ever do something in this area than please note that coreutils' exit statuses and options are quite special in some cases: --kill-after=0 means actually: send no KILL signal (after the initial signal, which still might be KILL) at all ... and not send it immediately after the initial signal (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51128) with --foreground, at least as of current coreutils, the exit status is still 124 when a KILL was sent, even though without --forground, 137 would be used with KILL. (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51135)
An update on the thing with coreutil's 124 vs. 137 exit status when KILL is sent while --foregrund is used. Seem I was able to convince upstream to change the behaviour: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51135#25 So future version will apparently use 137 *whenever* KILL is sent.
DURATION discrepancy has been fixed: commit c9720a761e88e83265b4d75808533cdfbc66075b Date: Fri Aug 3 18:27:00 2018 +0200 timeout: fix arguments to match coreutils Was: timeout [-t SECS] [-s SIG] PROG ARGS Is: timeout [-s SIG] SECS PROG ARGS