go-init's Introduction

go-init

go-init is a minimal init system with simple lifecycle management heavily inspired by dumb-init.

It is designed to run as the first process (PID 1) inside a container.

It is lightweight (less than 500KB after UPX compression) and statically linked so you don't need to install any dependency.

Download

You can download the latest version on releases page

Why you need an init system

I can't explain it better than Yelp in dumb-init repo, so please read their explanation

Summary:

Proper signal forwarding
Orphaned zombies reaping

Why another minimal init system

In addition to init problematic, go-init tries to solve another Docker flaw by adding hooks on start and stop of the main process.

If you want to launch a command before the main process of your container and another one after the main process exit, you can't with Docker, see issue 6982

With go-init you can do that with "pre" and "post" hooks.

Usage

one command

$ go-init -main "my_command param1 param2"

pre-start and post-stop hooks

$ go-init -pre "my_pre_command param1" -main "my_command param1 param2" -post "my_post_command param1"

docker

Example of Dockerfile using go-init:

FROM alpine:latest

COPY go-init /bin/go-init

RUN chmod +x /bin/go-init

ENTRYPOINT ["go-init"]

CMD ["-pre", "echo hello world", "-main", "sleep 5", "-post", "echo I finished my sleep bye"]

Build it:

docker build -t go-init-example

Run it:

docker run go-init-example

go-init's People

Contributors

Stargazers

Watchers

go-init's Issues

Request: supress SIGTERM and SIGINT signals

Hi,

If I understand correctly (I am illiterate in go :) ) you are now exiting with an error if anything "bad" happens with the child commands. But this means that when you trigger a shutdown from outside, which is in a form of SIGTERM or SIGINT go-init exits with an error.

This is unfortunate, because some child processes might not suppress the signal which floats up to docker, and it shouldn't, because the container exited because I asked it to do so.

My actual use-case is that I am running tests with docker-compose. There is a bunch of services in it, and one of them is actually executing the tests on the others.
I am using --abort-on-container-exit and --exit-code-from . This terminates all containers if one stops (which the test runner does, once it finishes). This unfortunately is sometimes not enough: if a service fails to start up correctly the testrunner might return 0, and I think all is green. I therefore want to inspect all exit codes, but some services that run go-init unfortunately pass over the sigterm signal, and I get an exit code 1 always. I'd rather get a 0 :)

Also, it probably would be good to pass on the error code from the child instead of a hardcoded 1.

thanks!

No need for `-main` flag

os.Args can be used directly as main command.

The advantage of this that you can create a base image with:

ENTRYPOINT ["/bin/go-init", "-pre", "echo starting..."]

Then you can use CMD as usual in derived images:

CMD ["echo", "foo"]

Otherwise, I have to pass the main command as single string which looks weird in my opinion.

Please add bash-like parsing of commands

Presently executables and arguments with spaces are not supported. This is a limitation not present in dumb-init for example.

Help with Argo Workflows

@pablo-ruth I see you seem to understand this problem well. Would you be interesting in helping the Argo Workflows community by bringing Zombie reaping to our code base please?

argoproj/argo-workflows#7259

Recommend Projects

pablo-ruth / go-init Goto Github PK