Epoch Init System

[Subsentient]

Alright, well Bacon seems to want me to create a thread here about my init system since I hard-crashed the party in the OpenRC thread (hurr derp). It's called Epoch.

I designed it because I wanted to avoid systemd in the second revision of my source-based distro, which I felt was past-due at the time. Little did I know it'd take me seven months to write Epoch before I could proceed with my source distro.

To help you understand Epoch, It's probably best that I state what I like in an init system, because this is what I've done.

* I like it to be small and not have any real deps, because an init system is a very important piece and it's not good to have it require a bunch of crap.
* I think it should have good service management so I can stop/start/restart services at will, and view their status as well. Epoch has good facilities for that.
* I don't like having configuration splattered everywhere, where systemd has /lib/systemd and /etc/systemd and soforth. It really complicates matters and reminds me of config monsters like GRUB 2 which I could never get to work right in anything but factory-fresh distro config, so I abandoned it for SYSLINUX.
* I don't care as much about parallel startup as I do the init system being understandable by the user. It should be easy to create new services without too much thought and deliberation.
* I don't like big binaries because I like to make initrds and tiny ramdisk distros, and with deps like it has, systemd is unacceptable for that.

So that's about what I've done with Epoch, is I've created the init system I wanted. It's a single threaded design that uses a custom IPC to provide nice, detailed status information and complex commands from the 'epoch' command, uses numeric priorities to start services with it's single-threaded model, and it literally needs only one config file, but as of 1.1 and up, it can also have as many as you like.
That file by default is /etc/epoch/epoch.conf.
One nice thing is that if a job gets stuck in shutdown or bootup, you can hit ctrl-alt-del and Epoch will kill it for you, and then continue the bootup or shutdown. During boot, if you hit ctrl-alt-del again in 5 seconds, it's going to switch gears, stop booting, and start shutting down.

The configuration is pretty simple and it probably reminds you of ini files or the ilk.
For me the binary is usually like 298K fully built dynamic in Linux i586.
Memory usage is pretty low I imagine but I've never measured it and it's going to vary on how many services' information it needs to load.
Right now RSS is ~800K for PID 1, which is the only process or thread that Epoch starts. It has a logging system, but it's a simple boot.log type deal that also logs manual service starts, errors, etc into /var/log/system.log. Epoch was also designed to be forgiving, so if you really bork the config somehow, it'll still offer to drop you to a shell.

It's written in mostly-ANSI C with Allman braces.

There are bootup screenshots and more on the official page at http://universe2.us/epoch.html.

[machinebacon]

Thanks Sub, I like the idea and I promise I will break try it in the next hours :)

[GekkoP]

Seems cool, thanks for the topic.
I'm pretty sure in less than a couple hours someone here will have it running and will be teasing me cause I'm still on busybox. ;)

[machinebacon]

Unpacked and built, now gotta switch the busybox off :D

[Subsentient]

For the help it will provide, here's my config file:
It will work in 1.1 and up.
Rename to /etc/epoch/epoch.conf.

[machinebacon]

Great, thanks a bunch. I have a quite noobish question though... if, as root, I run - for example - ./epoch reboot, it tells me that it cannot connect to the memory bus. Do I need to link the ./built/sbin and ./built/bin manually?

bbq@grill:~$ ls -l /sbin/init
lrwxrwxrwx 1 root root 12 Jun 10 16:28 /sbin/init -> /bin/busybox*

Thank you in advance and sorry if it is something very obvious ;) Didn't have lunch yet.

[Subsentient]

Yeh you need to boot from Epoch to connect to Epoch, that's all. reboot -f will still work however, as will epoch reboot -f, but make sure your disks are synced before you do that. killall5 -9 && mount -o remount,ro / works for me.

[machinebacon]

Yeah, I got you. So it means that right now (I did reboot after building epoch) epoch wasn't started. What might be the problem? I also tried to build with --binarypath set to /sbin/epoch , somehow the links don't follow, or I am too thick.

[dkeg]

Great stuff Sub! Looking forward to hearing and seeing some experiment results. Pidsley has been hard at work presenting different init systems lately and its been quite interesting.

[Subsentient]

machinebacon: You will need to specify init=/sbin/epoch or do ln -s /sbin/epoch /sbin/init.

dkeg: Thanks! :^3

[machinebacon]

Ha, thanks, I take the GRUB path first.

[machinebacon]

Just chiming in to report that Epoch booted me into a tty session with the grand usage of 17MB RAM. Now I have to read through the config/scripts part and recreate it on another BBQ (vanilla) install. Of course a bunch of things didn't work as they should, and I also know that is me being impatient and working on a OpenRC'ed busybox install, so I better start again from scratch (maybe abusing one of my source distro installations) ;) Thank you Sub, I like this a lot!

[Subsentient]

I'm so glad to hear that! Be sure to play with 'epoch status'! typing it with no argument dumps all statuses, and passing a service's objectid will list just that service.

[franksinistra]

welcome to the bbq forum Subsentient
i like your approach in init system , i'll try epoch in my debian box

[p120d16y]

I'm really liking the OS and init system so far. We'll play with it more tomorrow afternoon. Thanks again Subsentient.

[Alad]

Well, I ALMOST have it working on Arch. (Works fine on SubLinux, which I couldn't try much as it only boots on my XP laptop).

https://github.com/AladW/epoch-arch

Error messages: "Failed to mount /proc" and "Failed to mount /sys". Kernel is the stock Arch one with initramfs (3.12.26). It still boots, but stuff like eudev doesn't work.

[Subsentient]

If you are using an initrd/initramfs, those often mount /proc, /sys, /dev/pts etc for you. You can remove whatever ones it's complaining about safely. As far as eudev, I never got it to work right, period. I use udev 182 which works great. It's the last version before systemd ate udev. The eudev might be expecting something strange or something, I don't know. If you can find the cause and it IS an Epoch issue, I'll fix it.

[franksinistra]

i ran epoch and eudev without any hassle at all in crux 3.1, my udev script for epoch is something like this

Code: Select all

/bin/mount -t proc none /proc
/bin/mount -t sysfs none /sys

UDEVOPTS="exec,nosuid,noatime,mode=0755,nr_blocks=2048,nr_inodes=16384"
if /bin/mountpoint -q /dev ; then
        /bin/mount -n -o remount,${UDEVOPTS} dev /dev
else
        /bin/mount -n -t devtmpfs -o ${UDEVOPTS} dev /dev
fi

# mount /run directory
/bin/mount -n -t tmpfs -o mode=0755,nosuid,nodev,exec tmpfs /run

# make sure hotplugger is not set
echo > /proc/sys/kernel/hotplug

# copy devices from /lib/udev/devices
cp -ar /lib/udev/devices/* /dev

# launch udev daemon, make sure it's not running first
test -z "$(/bin/pidof -s udevd)" && /sbin/udevd --daemon

# coldplug devices and wait for the queue to be processed
/sbin/udevadm trigger --type=subsystems --action=add
/sbin/udevadm trigger --type=devices --action=add
/sbin/udevadm settle

[Alad]

^ Thanks for sharing, while I got eudev to work initially, it failed to set up permissions correctly.