> The reason that I wrote sleep 3 seconds is that I want to see how the kernel reacts when init dies.<p>That was my favorite line in the entire post. I love seeing this kind of fearless experimentation.<p>When I first learned to program, I desperately wanted everything to work and would try very hard not to break things. As I've matured into senior roles, I spend of a lot of effort creating "safe" development and testing environments like the author did here, just so that I can break things and make observations and then throw the environment away when I've learned what I needed to learn. Tools like vagrant and cheap cloud computing have made this easier to do than ever.
NOTE: You can't write an init without threads in Go, as you can in C. (I tried awhile back)<p>At least you can't with its portable interfaces such as exec.Command() and cmd.Wait():<p><a href="http://www.mustafaak.in/2016/02/09/forking-process-in-myinit-go.html" rel="nofollow">http://www.mustafaak.in/2016/02/09/forking-process-in-myinit...</a><p>You end burning a thread <i>per process</i>, which is pretty lame for an init. The wait() call blocks a goroutine AND OS thread, so the go runtime will have to start a new thread for the next wait().<p>Whereas in C you can do the entire thing from a simple thread (I call it "async processes"). You set SIGCHLD handler and get async exit notifications, and then process those in a single-threaded loop. I'm pretty sure there is a problem doing this in Go (besides resorting to the syscall module)... I think it has to do with the fact that Go turns signals into messages on a channel, but I don't remember right now...<p>EDIT: Now I remember. The problem with using the syscall module is that Go does not export Fork and Exec. It exports ForkExec, because it needs to ensure they run on the same thread.<p><a href="https://golang.org/pkg/syscall/#ForkExec" rel="nofollow">https://golang.org/pkg/syscall/#ForkExec</a><p>This severely limits the usefulness of your init program, because in Unix there are all sorts of important things that happen in between. It's how you set the child process state. You basically can't do anything with file descriptors or containers at all with this model.
The author might look at how a minimal (yet fully functional) init works:<p><a href="http://git.suckless.org/sinit/tree/" rel="nofollow">http://git.suckless.org/sinit/tree/</a> (look at config.def.h and sinit.c)<p>and build up from there. Given how minimal sinit is, it's a great place to start your functionality from, and see the power (and limitations) of a basic SystemV init system is.
Nice project! Even if you believe that systemd is too complicated, it's a great example on how to build an asynchronous, modern init system. Upstart uses some highly questionable tricks (ptrace!) to track processes across forks whereas systemd uses cgroups.
Part two is now up on his website:<p><a href="http://www.mustafaak.in/2016/02/09/forking-process-in-myinit-go.html" rel="nofollow">http://www.mustafaak.in/2016/02/09/forking-process-in-myinit...</a>
Writing init in Go probably have size issue compare to typical C implementation. Last golang helloworld I built was 1.4MB. The /sbin/init in my ubuntu dist is only 194k. Busybox version of init optimized for size/features can be much smaller.<p>Tough to use it in OpenWRT, DDWrt type of embedded system where system might only have a few megabytes of RAM/ROM.
@CSDude: Thanks for sharing this very interesting project!<p>From a technical point of view, what are the reasons you chose Go over alternatives, such as C, C++, OCaml or Rust?<p>(Just curious, as all those languages have compilers that produce fast, optimized, self-contained binaries.)
Although very different than a traditional Linux distribution, the init system for RancherOS might be worth taking a look at. It's written entirely in Go as well.
<a href="https://github.com/rancher/os/tree/master/init" rel="nofollow">https://github.com/rancher/os/tree/master/init</a>
Using Go even earlier in the boot stage in an initramfs (as a replacement for tools like dracut) crossed my mind recently. Go's statically linked binaries and fast builds make this particularly appealing to me. With (a lot of) work you could forego busybox entirely.
> Linux is mostly perfect as it is<p>Your critical thinking has not been engaged. Linux is a useful bit of code but "perfect" is not what it is known as everywhere.<p>My side of the room like this little ditty<p>Linux, by amateurs, for amateurs -- Dave Presotto [1]<p>Or<p>i’ve wondered whether Linux sysfs should be called syphilis -- Charles Forsyth [2]<p>Or if you like your detractors with a bit more fame<p>Unix has retarded OS research by 10 years and linux has retarded it by 20. -- Dennis Ritchie as quoted by by Boyd Roberts in 9fans.<p>I won't go on<p>[1] <a href="http://research.google.com/pubs/author4927.html" rel="nofollow">http://research.google.com/pubs/author4927.html</a><p>[2] <a href="http://www.terzarima.net/" rel="nofollow">http://www.terzarima.net/</a>