Noticed issue when rebuilding dockerfile and running image:-
panic: standard_init_linux.go:178: exec user process caused "exec format error" [recovered]
panic: standard_init_linux.go:178: exec user process caused "exec format error"
goroutine 1 [running, locked to thread]:
panic(0x6f3080, 0xc4201393b0)
Did much digging, identified that when specifying a script as a CMD in the Dockerfile, this script now requires a proper hashbang (aka shebang) or the above panic results.
#!/bin/bash
rm -rf /run/httpd/* /tmp/httpd*
exec /usr/sbin/apachectl -DFOREGROUND
Rebuilding the docker image with –no-cache option ensures the updated file is included.
A dummy java executable (actually a jar) was required to develop init scripts without access to the client’s application. The process of creating a Java ‘sleep’ application and wrapping within a ‘jar’ complete with manifest was not obvious to me. The ‘thread.sleep’ also didn’t work as I expected, requiring an additional exception handler. Not to mention the requirement for the manifest to require multiple new lines before being syntactically correct (and no report otherwise when incorrectly parsed, except ‘no main manifest attribute’ when attempting to run). Why Java, WHY?
The following tgz contains both the compiled java executable plus source, manifest and instructions to build / compile the jar should the wait time (default 100 seconds) need to be modified.
WaitLoop.tgz (source and executable tgz)
WaitLoop (Github Project)
The .jar can be executed with:-
java -jar WaitLoop.jar
Only A̶m̶i̶g̶a̶ Linux Makes It Possible
