Yelp/dumb-init

Is there a way to start runit

Ilyes512 opened this issue · 7 comments

Hi,

I was wondering if it was possible to combine this with runit, explicitly making this container work: https://github.com/dockage/alpine-runit/blob/master/Dockerfile#L29 I have tried all kind of things like replacing the CMD with:

ENTRYPOINT ["/usr/bin/dumb-init", "--"]
CMD ["/sbin/runit-init"]

But when I use the above and I start the container I get usage: /sbin/runit-init 0|6.

I could get it to work with CMD ["runsvdir", "-P", "/service"], but I would like to use the files that are being used by the image in /etc/runit (see https://github.com/dockage/runit-scripts/tree/master/alpine/etc/runit).

So is there a way to get this to work?

I've used runit a lot with dumb-init but only in the runsvdir-style invocation.

Looking at http://smarden.org/runit/runit-init.8.html, it seems like it might be hard to use -- it appears to check whether it is PID 1 (which it won't be if you're using dumb-init) and vary its behavior based on that. There doesn't seem to be a mode where it acts "like" the init system without actually being PID1.

I'm sort of curious -- if you're going to use runit-init why do you want to use dumb-init? I expect they perform most of the same functionality in this circumstance.

https://github.com/vulk/runit/blob/1c7b1a313e38eec5fafc3ea42fcd5474dfc30e39/src/runit-init.c#L49 is sort of interesting -- it seems to just exec runit when it's PID 1? Maybe you can just call runit? I'm not very familiar with this, so not sure if it will produce the behavior you're looking for.

Just using CMD ["/sbin/runit-init"] does work, but the reason I want to do the above is because a) it won't respond to ctrl+c (it wont exit/stop) and b) I think it does not "reap" zombie process like dumb-init would do. Maybe I should just use runsvdir. Oh, and also, when using /sbin/runit-init it seems to output what its doing when its existing (when you do a docker stop <container>, because ctrl-c does not work).

When using runit-init directly (output of starting and then stopping):

- runit: $Id: 25da3b86f7bed4038b8a039d2f8e8c9bbcf0822b $: booting.
- runit: warning: unable to open /dev/console: file does not exist
- runit: enter stage: /etc/runit/1
- runit: leave stage: /etc/runit/1
- runit: enter stage: /etc/runit/2
- runit: leave stage: /etc/runit/2
- runit: enter stage: /etc/runit/3
Waiting for services to stop...
ok: down: /service/foobar: 1s, normally up
- runit: leave stage: /etc/runit/3
- runit: sending KILL signal to all processes...
- runit: power off...
- runit: system halt.

(anecdotally) at lyft we use dumb-init (almost exclusively) with runsvdir and it works really well for us :)

Were there any specific problems you were seeing with runsvdir?

Do you guys set the docker config STOPSIGNAL to anything else? ie

STOPSIGNAL SIGCONT
# or
STOPSIGNAL HUP

It find this about the stopsignals when using runsdvir:

If runsvdir receives a TERM signal, it exits with 0 immediately.
If runsvdir receives a HUP signal, it sends a TERM signal to each runsv(8) process it is monitoring and then exits with 111.

I do not now what the default STOPSIGNAL being used by docker, but I think that setting stopsignal to TERM does not give time to services to stop and the return value 111 by runsdvir would probably also be a problem when using HUP.

dumb-init has a signal mapping function, if that's helpful: https://github.com/Yelp/dumb-init#signal-rewriting

Also, you can get dumb-init to print a verbose dump of what's happening with signals. Just use the --verbose option in your dumb-init command.

@Ilyes512 I have explained how to start runit in another issue. #158 (comment)

I realize you’re trying to use runit differently but just adding another concrete example of runsvdir.

@samrocketman I already solved this and I probably came across your answer back then :).

Thanks! I am closing this.