Seems like the breaking change in BusyBox ("timeout: fix arguments to match coreutils") make an issue

[ovc]

I have the same issue like here: https://github.com/vishnubob/wait-for-it/issues/71 in tools/wait-for-it.sh

$ docker logs --details vault_vault_1 
 timeout: unrecognized option: t
 BusyBox v1.30.1 (2019-06-12 17:51:55 UTC) multi-call binary.
 
 Usage: timeout [-s SIG] SECS PROG ARGS
 
 Runs PROG. Sends SIG to it if it is not gone in SECS seconds.
 Default SIG: TERM.
 wait-for-it.sh: timeout occurred after waiting 20 seconds for consul:8500
 wait-for-it.sh: strict mode, refusing to execute subprocess

[ovc]

Loks like it works without -t in timeout option:

59 wait_for_wrapper()
60 {
61    # In order to support SIGINT during timeout: http://unix.stackexchange.com/a/57692
62    if [ $QUIET -eq 1 ]; then
63    #   timeout $BUSYTIMEFLAG $TIMEOUT $0 -q -c -h $HOST -p $PORT -t $TIMEOUT &
64        timeout $BUSYTIMEFLAG $TIMEOUT $0 -q -c -h $HOST -p $PORT $TIMEOUT &
65    else
66    #   timeout $BUSYTIMEFLAG $TIMEOUT $0 -c -h $HOST -p $PORT -t $TIMEOUT &
67        timeout $BUSYTIMEFLAG $TIMEOUT $0 -c -h $HOST -p $PORT $TIMEOUT &
68    fi
69    PID=$!
70    trap "kill -INT -$PID" INT
71    wait $PID
72    RESULT=$?
73    if [[ $RESULT -ne 0 ]]; then
74        echoerr "$cmdname: timeout occurred after waiting $TIMEOUT seconds for $HOST:$PORT"
75    fi
76    return $RESULT
77 }

...

118 if test "${TIMEOUT_PATH#*$BUSYBOX}" != "$BUSYBOX"; then
119    ISBUSY=1
120 #   BUSYTIMEFLAG="-t"
121     BUSYTIMEFLAG=""
122 else

And after docker-compose up -d:

$ docker logs vault_vault_1 
wait-for-it.sh: waiting 15 seconds for consul:8500
wait-for-it.sh: consul:8500 is available after 0 seconds
==> Vault server configuration:

[rubickcz]

I can confirm this issue, as well as the workaround posted by @ovc.

[tolitius]

great, thanks for the workaround and for confirming. do you want to submit a pull request? if not I can apply your fix. let me know.

[tolitius]

ok, it should be fixed now. let me know if it works for you