11–20 of 27 posts
Is there a site for this or some nature of docs? I'm still searching for a process manager that I can love for use with Docker (I've played with runit and am currently playing with s6), but the total lack of readme or docs makes this link fairly unhelpful.
Thanks for putting this out there.
@chubot mentions the thread-per-process overhead. Runit does process-per-process so in that aspect Runsit should be a bit lighter. Then again, Runit is extremely tiny, its statically compiled binaries taking up next to nothing. The wait(-1) trick sounds good, but there must be a reason why for example Runit doesn't use it, since afaik Runit only runs on POSIX systems.
Keep up the good work!
EDIT: a web interface, that's pretty spiffy! (though I've made something similar work for Runit by querying the status of a service and serving up a dashboard, with a Go webserver of course).
FWIW I also started writing a init-like server in Go. One thing I ran into was that Go's APIs sort of coerce you into having an extra thread per process. runsit also has this issue. See line 489 of runsit.go, pasted below. You can do it non-portably in Go by using os.ForkExec and Wait4(-1). The portable exec package assumes you will call Wait(pid), and not Wait(-1), which basically implies using a thread per process.…
Is there a site for this or some nature of docs? I'm still searching for a process manager that I can love for use with Docker (I've played with runit and am currently playing with s6), but the total lack of readme or docs makes this link fairly unhelpful.
Huh. I have somehow never heard of s6 but it looks very promising. What did you find when using it for this purpose?
Now that I've got it build, the next hurdle is making init scripts in execline. It's a fairly simple language, and I enjoy the premise behind it, where scripts should be clear and deterministic.
Overall, s6 provides a lot more helper tools for daemon management than runit did, so it looks like it's gonna be great for my use case. I've got an automated build set up to handle making a Docker image with s6 prepared:
FWIW I also started writing a init-like server in Go. One thing I ran into was that Go's APIs sort of coerce you into having an extra thread per process. runsit also has this issue. See line 489 of runsit.go, pasted below. You can do it non-portably in Go by using os.ForkExec and Wait4(-1). The portable exec package assumes you will call Wait(pid), and not Wait(-1), which basically implies using a thread per process.…
A goroutine is not a thread. That only ties up that one goroutine.
Re-read what I wrote. If that doesn't convince you, then download and run the code. Run "pstree" on it and observe how many child processes and threads there are. You'll learn something useful about the relationship of the Go runtime to the OS.
FWIW I also started writing a init-like server in Go. One thing I ran into was that Go's APIs sort of coerce you into having an extra thread per process. runsit also has this issue. See line 489 of runsit.go, pasted below. You can do it non-portably in Go by using os.ForkExec and Wait4(-1). The portable exec package assumes you will call Wait(pid), and not Wait(-1), which basically implies using a thread per process.…
A goroutine is not a thread. That only ties up that one goroutine.
Earlier quoted context omitted.
Huh. I have somehow never heard of s6 but it looks very promising. What did you find when using it for this purpose?
My initial thoughts were less than positive, just because building it is a less-than-stellar process. Part of that is because it has a couple of deps that must also be compiled (skalibs and execline), and part is because it follows the slashpackage conventions ( http://cr.yp.to/slashpackage.html ). Now that I've got it build, the next hurdle is making init scripts in execline. It's a fairly simple language, and I enj…
I guess I am asking for a lot, no need to indulge, but if you do, much appreciated.
@akerl_19 Thanks. I have but two upvotes to give.
Earlier quoted context omitted.
My initial thoughts were less than positive, just because building it is a less-than-stellar process. Part of that is because it has a couple of deps that must also be compiled (skalibs and execline), and part is because it follows the slashpackage conventions ( http://cr.yp.to/slashpackage.html ). Now that I've got it build, the next hurdle is making init scripts in execline. It's a fairly simple language, and I enj…
Seems you are knowledgeable about these matters, I am not. So could you put in perspective why would runsit be interesting. I have run into several names that claim to handle this problem, you have mentioned s6 and runit, then there is monit, launchd, supervisor... Are there some glaring lacks that needs to be filled. Do they all do the same thing or do they have specialized niches ? I guess I am asking for a lot, no…
As far as the variety of other tools:
launchd is an interesting concept but hasn't picked up a ton of adoption by things other than OSX.
I've used supervisord for some other projects, but never as the main init system, and the python dependency has thus-far prevented me from doing so: I like my init process to be statically compiled so that the initial system startup has as few deps as possible.
I really enjoyed runit; I'm only trying out s6 now because it has a few more helper tools for controlling process startup and management, and appears to have better support for log handling. Runit was very powerful as an ultra-light-weight init system, and both runit and s6 have very thorough docs, with runit having a large catalog of community-provided initscript examples.
FWIW I also started writing a init-like server in Go. One thing I ran into was that Go's APIs sort of coerce you into having an extra thread per process. runsit also has this issue. See line 489 of runsit.go, pasted below. You can do it non-portably in Go by using os.ForkExec and Wait4(-1). The portable exec package assumes you will call Wait(pid), and not Wait(-1), which basically implies using a thread per process.…
Have one goroutine loop forever:
* wait for SIGCHLD
* take the childlock
* do nonblocking Wait() until no unwaited child remains
* release the childlock