jinit
jinit is based on an extended version of Richard
Gooch's need(8) scheme for inits. Currently there is no
provide(8) functionality, but that should not be difficult to
implement, if someone ever needs it.
The competition
| Name | How it communicates |
|
minit by Felix von
Leitner
|
Uses its own filesystem based service scheme.
|
| simpleinit by poe@daimi.aau.dk and apparently updated by Richard Gooch
(part of the util-linux package, available on kernel.org mirrors)
|
Fast need(8) based init. Uses /dev/initctl FIFO.
|
|
sysvinit by Miquel van Smoorenburg (metalab mirrors)
|
System V (inittab) style init. Uses /dev/initctl FIFO.
|
|
*BSD init (src/sbin/init in OpenBSD and FreeBSD, basesrc/sbin/init/ in
NetBSD).
|
BSD (ttys) style inits. Use signals.
|
Advantages of jinit over the competition
- Has complete service start and stop (rollback) support with
dependency tracking. If you stop the network service for
example, all network daemon services will also be stopped.
- You can tell it to respawn a command without editing
inittab or ttys (need --respawn tty1 /dev/command arguments).
The real reason for this I like to have a terminal started as
very first thing on boot on tty12, so I can login readonly when
the disks are being checked. The other terminals should not be
spawned yet, as the utmp records can't be made. I don't have
sysv init runlevels so I'd have a bit of trouble expressing this
in inittab.
- Communicates over SysV message queues, so it does not need
to touch a filesystem when it comes up.
- Will kill all processes and force umount filesystems
automatically on shutdown.
- If it receives a fatal error signal like SIGSEGV it will
fork a child to dump core, and exec itself (with the "panic"
option so no bootscripts are run). If the exec doesn't work
it'll pause and wait to receive a signal before trying
again. That means it should never bring your system down
unnecessarily.
Disadvantages of jinit over the competition
- jinit is currently not very tested (probably has bugs).
- It does not use a traditional (System V) inittab or (BSD)
ttys file so there is a bit of upgrade work needed. See the README
for details.
- sysvinit can dump state to and exec a later version of
itself, so no state is lost between upgrades. This is currently
impossible with jinit (though sending it a SIGSEGV will cause it
to exec the later version of itself).
- sysvinit can handle many more kinds of event (powerfail,
for example).
- jinit is bigger and more complex than other inits.
Internals
jinit is written in C++ (that works with GNU CC 2.95), but
uses many fairly lowlevel headers from glibc 2.2 for linux so it
probably won't work without minor modifications on anything except
linux. However, an autoconf/automake build framework exists
already to deal with possible system differences. It is already
has all strings enclosed in gettextisable constructs, but no
translations exist (that is, it is internationalised but not
localised).
Last modified: Tue Apr 22 00:24:03 BST 2003