Anyone interested in a new init system?

Subsentient · 2013-12-30 09:22:54

Hi, a couple months back some guy posted about my init system-to-be in Gentoo forums, and it turned out that a lot of interest actually was out there for something like the Epoch Init System, so this time I'm taking the initiative.

Since July I've been working on a new init system to use with a homebrew distro I was going to build for me and friends, because I realized that I really didn't like my choices for init systems.

It's not very big, in fact, probably the smallest one out there right now besides busybox, but it's very fast.

It's at 1.0 RC2, but RC2 is pretty stable so feel free to take Epoch for a spin. :^)

It's:

* Very small
* Specifically designed to be unintrusive
* Has no deps besides libc, Linux 2.6, and /bin/sh is highly recommended.
* Has all services and configuration in one file, making it really easy to edit manually.
* Has a built-in logger (can be disabled)
* Has really nice service management capabilities and status commands

Hope someone finds it useful :^)

-Sub

Last edited by Subsentient (2013-12-30 10:41:41)

Trilby · 2013-12-30 12:53:16

Subsentient wrote:

Has no deps besides libc, Linux 2.6, and /bin/sh is highly recommended.

Really? That might make it a hard sell around here. Are you planning support for more recent kernels?

brebs · 2013-12-30 14:09:23

Trilby wrote:

might make it a hard sell

Should be pretty obvious that 2.6 is a minimum rather than a maximum

Subsentient, how is yours better than e.g. s6?

Trilby · 2013-12-30 14:36:54

Sorry for the noise if that is the case - it wasn't obvious to me. A linux kernel is an obvious requirement for a linux init system - so a specific versioned dependency seemed to imply that version was needed.

falconindy · 2013-12-30 16:10:54

An initial glance at the code makes me worry a bit. I suspect you haven't had much experience with the Linux API or systems programming.

* You seem to be using vfork instead of fork (and exit rather than _exit!!) when you detect MMU support. fork() on Linux is already CoW with MMU support, and vfork has been considered harmful since its introduction into the kernel in 2.2:
http://ewontfix.com/7/
https://lkml.org/lkml/1999/11/9/73

* Your IPC mechanism has no checks for zero-termination or truncation of written commands. I'll bet that you could easily segfault PID 1 by abusing this (or by writing to the wrong "side" of the shm).

* There's race conditions since the same memory segment is shared across all callers and the server (Your attempts with MEMBUS_NOMSG are really not sufficient to synchronize across multiple processes). I'm very curious why you chose to roll your own IPC rather than using something simple like a private AF_UNIX socket which exchanges datagrams with clients. You get ordered/guaranteed delivery (because it's AF_UNIX), clear message boundaries...

* Your use of volatile is wrong in membus.c. volatile means that the value itself can be changed at any time by, e.g. another thread or signal handler. You're polling an address and dereferencing it -- the address (aka the value of the pointer) will never change. The compiler can't optimize this out in a way that requires volatile.

* No support for running services as a user other than root or in a chroot, unless the services do this on their own. No support for resource management/control. It's hard for me to see how you support services which daemonize themselves -- I suspect this goes wrong much of the time and I can imagine services where it will never work.

Subsentient · 2013-12-30 16:21:28

brebs wrote:

Trilby wrote:
might make it a hard sell
Should be pretty obvious that 2.6 is a minimum rather than a maximum
Subsentient, how is yours better than e.g. s6?

Epoch has high level service management, runs as PID 1 (always), however it wakes up more often than any of the others. It's paranoid about it's PID tracking accuracy and rescans every minute, and it reaps dead system-wide processes on a VERY regular interval, along with scanning it's in-house messaging bus for client applets attempting to do something, and checking it's 'shutdown' timer. Epoch is a single-process single-threaded init system. It was very recently that all threading was stripped and coroutines used instead.

It's not intended to be used in embedded environments, but I imagine it'd be just fine in all but the most extreme cases. I designed it imagining it being used in systems like ttylinux to systems like Arch or Gentoo, perhaps even Debian or Fedora. I didn't have tiny, tiny systems in mind. So far, it's proven to be capable of doing a really great job keeping seven Fedora systems running.

Last edited by Subsentient (2013-12-30 16:23:20)

Subsentient · 2013-12-30 16:30:18

falconindy wrote:

An initial glance at the code makes me worry a bit. I suspect you haven't had much experience with the Linux API or systems programming.
* You seem to be using vfork instead of fork (and exit rather than _exit!!) when you detect MMU support. fork() on Linux is already CoW with MMU support, and vfork has been considered harmful since its introduction into the kernel in 2.2:
http://ewontfix.com/7/
https://lkml.org/lkml/1999/11/9/73
* Your IPC mechanism has no checks for zero-termination or truncation of written commands. I'll bet that you could easily segfault PID 1 by abusing this (or by writing to the wrong "side" of the shm).
* There's race conditions since the same memory segment is shared across all callers and the server (Your attempts with MEMBUS_NOMSG are really not sufficient to synchronize across multiple processes). I'm very curious why you chose to roll your own IPC rather than using something simple like a private AF_UNIX socket which exchanges datagrams with clients. You get ordered/guaranteed delivery (because it's AF_UNIX), clear message boundaries...
* Your use of volatile is wrong in membus.c. volatile means that the value itself can be changed at any time by, e.g. another thread or signal handler. You're polling an address and dereferencing it -- the address (aka the value of the pointer) will never change. The compiler can't optimize this out in a way that requires volatile.
* No support for running services as a user other than root or in a chroot, unless the services do this on their own. No support for resource management/control. It's hard for me to see how you support services which daemonize themselves -- I suspect this goes wrong much of the time and I can imagine services where it will never work.

You're right on a couple of counts. I'm fairly new to POSIX programming, and I'm aware of that bug in MemBus I never got around to fixing. It's not that I can't. Watch git.
MemBus was never intended to allow multiple connections, just not to crash if two commands are trying at the same time. I chose to write my own IPC because I had specific design goals in mind, though I admit I could have probably made sockets work fine. The use of volatile is there because I only recently ripped out the threading system and forgot to remove those. You'll probably find a variable called RunningChildCount somewhere, that's also obsolete and I need to snip it out. As far as causing a segfault, I made real sure that it's not easy to cause a kernel panic by segfaulting Epoch. Look up EmergencyShell() in actions.c, but yes, it could use a little more error checking. You can also segfault init with kill -11 1. :^)
Alas, I suppose I should indeed implement user/groups for each process, but that'll be pretty easy.

Epoch is not yet at 1.0, remember.

EDIT: https://github.com/Subsentient/epoch/co … 3e08824a9f
https://github.com/Subsentient/epoch/co … 27af3e0bde

EDIT 2: https://github.com/Subsentient/epoch/co … 6c3b341cab

Last edited by Subsentient (2013-12-31 00:11:26)

aaditya · 2015-01-01 17:32:29

Reviving an old topic, today after reading manjaro_experiments#pure_epoch_init_system, I decided to try the Epoch init system, and was able to get a running system up in a few hours.

So I decided to write a PKGBUILD which interested users could try out:
https://aur.archlinux.org/packages/epoch-init-system/

Upstream docs:
http://universe2.us/epoch.html

A disclaimer from my side: this is an experiment for me, and I may not maintain the package in the long run, so am willing to hand it over to an interested maintainer

I tried it out with eudev (which I already have installed on my system).
https://wiki.archlinux.org/index.php/Op … allation_2 (packages eudev and eudev-systemdcompat)

jasonwryan · 2015-01-01 18:23:53

Moving to Community Contributions...

aaditya · 2015-01-01 18:42:32

jasonwryan wrote:

Moving to Community Contributions...

Thanks

Last edited by aaditya (2015-01-01 18:43:14)

Arch Linux

#1 2013-12-30 09:22:54

Anyone interested in a new init system?

#2 2013-12-30 12:53:16

Re: Anyone interested in a new init system?

#3 2013-12-30 14:09:23

Re: Anyone interested in a new init system?

#4 2013-12-30 14:36:54

Re: Anyone interested in a new init system?

#5 2013-12-30 16:10:54

Re: Anyone interested in a new init system?

#6 2013-12-30 16:21:28

Re: Anyone interested in a new init system?

#7 2013-12-30 16:30:18

Re: Anyone interested in a new init system?

#8 2015-01-01 17:32:29

Re: Anyone interested in a new init system?

#9 2015-01-01 18:23:53

Re: Anyone interested in a new init system?

#10 2015-01-01 18:42:32

Re: Anyone interested in a new init system?

Board footer