View source for NinitInstructions

These instructions detail how to set up the <tt>ninit</tt> init system. It can be used for users of both Systemd and non-Systemd Linux (and possibly Unix) systems. 

If you are replacing Systemd with Ninit, then you should follow this article closely (unless you're an expert). If you're not migrating from Systemd, then obviously the systemd-specific instructions don't apply to you, but everything else does.

The steps, broadly, are:

# Uninstall systemd
# Install a "normal" init system like SysVinit as a starting point and "safety net"
# Build and install ninit
# Configure ninit
# Tweak ninit


==Init Systems Explained==

Traditionally, the init (initialisation) system is a series of steps
that a unix-like OS takes in order to get from being powered down to
being a functional operating system. A quick-and-dirty tour goes a
little something like this:

# The computer receives power.
# Inbuilt firmware on a motherboard triggers a probe of harddrives for a recognisably bootable partition in currently defined boot device (usually a hard drive, flagged as the primary boot device in BIOS or UEFI) 
# The code on the boot device is executed. For Linux. this is usually a boot loader such as GRUB or LILO.
# The kernel is loaded into memory. 
# The init sequence, as defined by the init application in <tt>/sbin</tt>, is launched. This usually means that a sequence of smaller daemons are launched such that important hardware becomes available to the computer and the user.
# A login shell or desktop login is presented to the user.

The stuff that goes on in the motherboard is external of the OS, and
still mostly proprietary. The boot loader is open source and
available, but not part of the init sequence, as it is deciding which
init sequence to spawn. The init process, proper, begins after the
kernel has been decompressed and loaded into memory, at which point
some executable binary on the system needs to be launched;
traditionally, the application that gets executed is <tt>/sbin/init</tt>.

You can see this on your own system right now:

<code>ps -p 1 </code>

As you can see, PID 1 is occupied by init (or <tt>systemd</tt>, depending on whether you've [[How_to_remove_systemd_from_a_Debian_jessie/sid_installation|removed it]] yet).


===Thoroughly Modern Init Systems===

The appeal in using a "modern" init system (instead of <tt>sysVinit</tt>) is twofold: dependency-based initialisation of services, and process monitoring or service supervision. 

Dependency-based initialisation is significant because processes that might take a long time to start (such as successfully getting a DHCP address) can not only delay the entire boot process, but it could also theoretically cause services that rely on having a network connection to fail.

Service supervision, rather than just launching a service once at boot time, creates a monitoring system that watches each service (or each one marked as supervisable) and ensures that it gets re-launched should it crash. 

So while it's an important process itself, there's nothing magical about init or an init system; it's just another executable application on your system which happens to be the first thing launched after you power up your computer. This means that you are free to use something other than what shipped with your distribution.

==Before Ninit==

If you are migrating away from Systemd on Debian or similar, you should [[How_to_remove_systemd_from_a_Debian_jessie/sid_installation|uninstall Systemd and install SysVinit]] ''before'' trying ninit. It seems redundant to switch from Systemd to SysVinit to ninit, but the default init scripts that get installed with SysVinit will be useful later.

Again, for emphasis:

Install SysVinit (or some native init process) on your machine ''before'' trying ninit. It will make the process much easier!


==Getting Ninit==

Ninit is a fork of the minit project. Your repository may offer ninit as an
installable package. If not, download tho stable release of the source
code. Its original website has more or less vanished, so at least for some time you can use a backup location (though there is no guarantee that the backup copies that exist will be maintained over time):

<code>
$ git clone https://gitlab.com/notklaatu/ninit
</code>

or

<code>
$ git clone https://gitlab.com/ShadowKyogre/ninit
</code>


==Building Ninit==

Ninit has the option of compiling against [https://www.fefe.de/dietlibc/ dietlibc], an optimised C
library (as opposed to glibc, for instance), but unless you have a
particular reason for doing that, it's a little simpler to just
compile against the C library you already have on your system:

<code>
$ make nodiet
</code>

To make sure everything worked as expected, run the inbuilt tests:

<code>
make tests
</code>

And finally, assuming all went well, install the application. How you
choose to install will depend on your distribution and how you manage
your own software. If your system uses a database-driven package manager, like RPM,
APT, or similar, use the application [http://asic-linux.com.mx/~izto/checkinstall/ checkinstall] to generate an RPM
or DEB package for you. Your repository should have <tt>checkinstall</tt>
available for install, but if not get it from the website directly. 

Once checkinstall is installed, just run it from within
the ninit source directory:

<code>
$ checkinstall
</code>

Follow the prompts to create a package and install ninit. 

If you're trying ninit out on Slackware, the native packaging tools do basically the same thing:

<code>
$ mkdir /tmp/ninit
$ make install distro
$ cd /tmp/ninit.distro
$ su -c 'makepkg -l y -c -n ninit-0.14-`uname -m`.tgz'
$ su -c 'installpkg /tmp/ninit*tgz'
</code>

Do not uninstall SysVinit yet. You want it to still be active so you can still reboot if you need to.


==Configuring Ninit==

Part of what makes ninit so easy to try is its very good init script
configuration script, <tt>ninit-inittab</tt>. As long as your current system
uses <tt>/sbin/init</tt> as its init process (that is, anything but systemd), you can easily
get the basic scripts required for a basic, minimal login. This only works if you installed SysVinit (or some other native init system) ''before'' trying ninit; if you are coming straight from systemd to ninit, there are no init scripts for this script to convert, so you will have to make them all yourself.

Assuming you did install some intermediary init system after uninstalling systemd (like this article advised), then you can run:

<code>
# mkdir /etc/ninit
# /sbin/ninit-inittab /etc/inittab /etc/ninit /tmp/ninit.sh
# /tmp/ninit.sh
</code>

This establishes the very basic necessities for a bootable system,
specifically the creation of a TTY (the text login screen you see when
you hit ctrl-alt-F{1,2,3,4,5,6}), and a few other basic services.

By this time, you should no longer be running systemd, but '''do not uninstall''' SysVinit (or whatever non-systemd init system you are using as an intermediate init) yet. 

Reboot your machine, just to test out whether or not your new init system will bring up a
somewhat usable OS. When you reboot, stop at your LILO or GRUB menu and choose to modify the boot command by appending this kernel arg:

<code>
init=/sbin/ninit 
</code>

Your computer should uncompress the kernel as usual, and then attempt
to launch the first process: <tt>/sbin/ninit</tt>. Assuming that works, your
computer should continue to boot more or less as usual.

You have not permanently changed how your computer boots, you just
used an override variable as part of your boot command. So if anything
goes wrong, you can shutdown and reboot without doing anything; your
computer will boot using <tt>/sbin/init</tt> as usual.


==Ninit Scripts==

Whether you succeeded or ran into problems, you might notice that your
<tt>/etc/ninit</tt> directory is pretty sparse compared to a traditional
SystemV or BSD init directory. That's because you have yet to write
init scripts for your system so that the computer knows what processes
to start for you upon boot.

If you are trying all of this on a Systemd computer, then you need to
build the entire init directory from the ground up.

Luckily, the ninit author has posted his personal stash of (n)init
scripts, available at https://gitlab.com/notklaatu/ninit/tree/master/examples (the [https://gitlab.com/notklaatu/ninit/tree/master/examples examples] directory of the ninit source code that you downloaded).

<code>
$ cd ~/path/to/ninit/examples/etc/ninit
</code>

The sample <tt>etc/ninit</tt> directory contains many of the most common init
scripts that most computer users need for day-to-day computer
use. Even so, you cannot just copy his scripts over to your system
without at least looking at them to make sure that they make sense for
your system (and unless you are running a qmail server, many will
not).

The example ninit scripts do provide a good starting
point. Specifically, they reveal the file structure of the ninit
infrastructure.

<code>
directory: name of service to start, containing one or more of these files:
 - environ: new-line delimited list of env variables to include when launching the service.
 - out: a symlink to a sensible destination for data sent to stdout.
 - params: new-line delimited list of arguments to include when
 launching the service.
 - run: a symlink to the executable binary that launches a
 service. Less often, a shell script that is itself the service being
 launched.
 - respawn: an empty file, the presence of which dictates that the service should be respawned
 upon failure.
</code>

Starting from the beginning: you need to be able to login. This is
handled, traditionally, by an application called <tt>getty</tt> (you can read
the man page for detail; it's an interesting read if you're not
familiar with it). Of course, getty has been around for a while so
naturally there are alternatives, many of which are in use by popular
Linux distributions, so you should see what is available to you. Most
distributions, even when using an alternative getty, link <tt>/sbin/getty</tt>
to whatever they are using, but it doesn't hurt to take a look in
<tt>/sbin</tt> just to see what you have available to you.
.

===TTY Login===

Create a getty directory in your <tt>/etc/ninit</tt> directory, and place one
directory within that for each login screen you want to have
available. Traditionally, <tt>X</tt> is launched at <tt>tty7</tt>, so providing six
getty screens would keep with this tradition:

# mkdir -p /etc/ninit/getty/{1,2,3,4,5,6}

Ninit's own <tt>pututmpid</tt> application handles the launching of getty, so
all you need do is create a symlink <tt>run</tt> to <tt>pututmpid</tt> and touch a
<tt>respawn</tt> file so that the tty's are supervised:

<code>
# for dir in getty/* ; ln \
  -s /sbin/pututmpid /etc/ninit/"${dir}"/run \
  && touch /etc/ninit/"${dir}"/respawn \
  ; done
</code>

Then create a <tt>params</tt> file for each. You can create a loop to automate
this or do it manually; the parameters required are:

<code>
c1
/sbin/agetty
tty1
</tt>

and so on for each tty (so 'c1' becomes 'c2' for the second tty, and
'tty1' becomes 'tty2', and so on).

Save this to the file <tt>params</tt> located in each directory.


===Halt===

Booting to a login prompt is a good start but at some point you want to turn your computer off. For that, you need
a way to stop PID 1 from running, preferably gracefully.

In ninit, all you need to do to create a new service is create a
directory in <tt>/etc/ninit</tt>. So first of all, create a directory called
<tt>level0</tt> (or similar) in <tt>/etc/ninit</tt>, and create a link to it called <tt>halt</tt>. It's
not necessary to provide both an init runlevel 0 and a halt service, but most
experienced unix users would expect to be able to call either <tt>runlevel 0</tt> or <tt>halt</tt>, so providing a service called <tt>halt</tt> is user-friendly and more backwards-referential.

<code>
# mkdir /etc/ninit/{level0}
# ln -s /etc/ninit/level0 /etc/ninit/halt
</code>

In the <tt>level0</tt> directory, create a link <tt>run</tt> that points to
<tt>/sbin/ninit-runlevel</tt>:

<code>
# ln -s /sbin/ninit-runlevel /etc/ninit/level0/run
</code>

And then create a setup file called <tt>/etc/ninit/level0/setup</tt>.

Service management with ninit is performed with the <tt>nsvc</tt>
command. Creating a shell script that stops each service that ninit
launched ensures that each service is kindly shut down before
turning off your computer.

Running the <tt>nsvc</tt> command with no arguments reveals some pertinent
options (this is only a selection; run the command to see a full list):

<code>
# /bin/nsvc
-u up
-d down
-L list services
</code>

So the contents of <tt>/etc/ninit/level0/setup</tt> file can be as simple as
listing all running services, and stopping each one: 

<code>
#!/bin/sh
all=`/bin/nsvc -L`
/bin/nsvc -C0 $all
</code>

Make it executable with <tt>chmod +x</tt>, and now create the final three files:

<code>
# echo "INIT_HALT=POWERDOWN" > /etc/ninit/level0/environ
# ln -s /sbin/ninit-runlevel /etc/ninit/level0/run
# echo "0" > /etc/ninit/level0/params
# echo "/etc/ninit/level0/halt" >> /etc/ninit/level0/params
</code>

The run script points to <tt>/sbin/ninit-runlevel</tt>, which more or less is
the ninit equivalent to init's <tt>telinit</tt>. As arguments (found in the
<tt>params</tt> file, of course), <tt>ninit-runlevel</tt> takes the level to switch to
(in the case of halting, that's <tt>0</tt>) and the file to execute as the system's final farewell.

In this example, I am calling the final script <tt>/etc/ninit/level0/halt</tt>
but you can call it anything you please, as long as it makes logical
sense to you and you remember to make <tt>/sbin/ninit-runlevel</tt> reference
it by way of <tt>/etc/ninit/level0/params</tt>.

There are very good examples of how to kindly shutdown a system
available from the Linux From Scratch documentation, Slackware's init
sources, and the old SystemV scripts that shipped with Debian and Red
Hat pre-Systemd. Use these examples to create your own halt script if
you do not have one on your system already.

In fact, if you already have a usable shutdown script on your system,
then you can just reference it. As long as the script is POSIXly
correct and does not require external services that you have not
launched in order to complete, then your computer will successfully
halt. There's certainly no shame in re-using scripts from your
previous init system where possible.

If you are stuck creating your own, keep it simple at first. Use an
example script and trim it down to the services you know apply to your
system. Here is a trimmed version of the default <tt>rc.0</tt> by Miquel van
Smoorenburg and Patrick Volkerding:

<code>
#!/bin/sh
PATH=/sbin:/etc:/bin:/usr/bin

# Save the system time to the hardware clock
/sbin/hwclock  $CLOCK_OPT --localtime --systohc

# turn process accounting off
/sbin/accton off

# Carry a random seed between reboots.
echo "Saving random seed from /dev/urandom in /etc/random-seed."
# Use the pool size from /proc, or 4096 bits:
if [ -r /proc/sys/kernel/random/poolsize ]; then
  /bin/dd if=/dev/urandom of=/etc/random-seed count=1 bs=$(expr $(cat /proc/sys/kernel/random/poolsize) / 8) 2> /dev/null
else
  /bin/dd if=/dev/urandom of=/etc/random-seed count=1 bs=512 2> /dev/null
fi
/bin/chmod 600 /etc/random-seed

# Before unmounting file systems write a reboot or halt record to wtmp.
$command -w
/bin/rm -f /var/lock/subsys/*
/sbin/swapoff -a
/bin/sync
/bin/umount -v -a -t no,proc,sysfs
/bin/mount -v -n -o remount,ro /
/bin/sync
/bin/sleep 3
# Ensure all procs have completed on SMP machines:
wait

# and halt:
/sbin/poweroff
</code>


==The Big Reboot==

Now, regardless of your previous init system, you can reboot your
computer and start it using the <tt>init=/sbin/ninit</tt> kernel argument to
see how you've done. If all goes well, you should find yourself able
to boot, to login, and to do any number of activities that do not
require special daemons to be running in the background. And in the
end, you should be able to halt your system.

Assuming all goes well, you've successfully set up a new init system for yourself.

==Make ninit the Default==

Make <tt>ninit</tt> your default init system by adding the kernel
arguments to your Lilo or GRUB configuration. See your distribution documentation to learn how to do that.

From that point, create new ninit scripts to handle
important services that you use (such as an NTP daemon, or SSH daemon, or HTTP, and so on). Use "prior art" as the basis for your work (Linux From Scratch and Slackware are excellent projects to "steal" from) and
remember to use <tt>respawn</tt> for those important ones that you want to
keep alive no matter what. After all, you're using a fancy
new init system, so you may as well take advantage of its benefits!


==Dependencies and More==

Ninit has many more features, such as dependency-based loading of
services, so explore it. And since there are so many more init systems
out there, and you now see how to modify your init system, you can now
freely explore other alternatives. 

Happy hacking!