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.