I think there was a change, something to do with named pipes, that now requires the file being monitored and sent to stdout must already exist before dockerize runs. That was not the case in 0.5.0. We use dockerize as a wrapper in the command definition of our compose file, and the log file being monitored won't exist on a new deployment until after the application has started running, which is after dockerize executes (because dockerize wraps the application command).
This means we either get containers that fail to startup, the application never gets to start even once to create the log that we want to monitor and send to stdout. Instead, we have to somehow manually run another container with access to the same volume and touch the file (or make another wrapper script and bake it into the image and wrap dockerize).
I think there was a change, something to do with named pipes, that now requires the file being monitored and sent to stdout must already exist before
dockerizeruns. That was not the case in 0.5.0. We usedockerizeas a wrapper in thecommanddefinition of our compose file, and the log file being monitored won't exist on a new deployment until after the application has started running, which is afterdockerizeexecutes (becausedockerizewraps the application command).This means we either get containers that fail to startup, the application never gets to start even once to create the log that we want to monitor and send to stdout. Instead, we have to somehow manually run another container with access to the same volume and touch the file (or make another wrapper script and bake it into the image and wrap dockerize).