[Pkg-sysvinit-devel] Systemd, best parts

[Sergey]

Hello.

I wanted to share some init-related ideas with some smart people, and
could not find a better place for them than this list. Please correct
me if I'm posting to the wrong place.

I'll try to keep this email short so if I missed anything - feel free to
ask any questions.

In short, I like some ideas behind systemd but I don't like some
implementation decisions of it. In particular I don't like the idea of
breaking everything to create something new. IMHO init daemon should be
an invisible backward compatible tool that nobody should think about. So
the main idea is to take those good systemd ideas and implement them in
a backward compatible way.

I see two new major ideas behind systemd:

1. Dependency-based boot is already a common thing. And many init
daemons start services in parallel checking for their dependencies. But
"one service depending on another service" in many cases actually means
that it depends on the socket, provided by that service, but not on the
entire service. In that case init daemon can create that socket and then
actually start both services in parallel, passing the handle for created
socket to the first service. That increases number of services starting
in parallel, which allows a faster boot on modern multicore systems.

2. Offline mounting. To make boot process even faster all on-boot mounts
can be done in background (they even can be partially done in parallel,
but that's another story). The idea is that most of mountpoints are not
really used during boot process. And even if they're used only a few
processes use them. So the trick is to put an autofs mountpoint to all
directories that must get mounted and then check and mount them all in
background. If some process attempts to access such mountpoint autofs
will stop it and make it wait until FS is checked and mounted but other
processes will continue to run.

Both these ideas (with a lot of others) are implemented by systemd. But
without systemd these ideas themselves don't break any compatibility.
And I believe they can (and should) be implemented in two separate small
parts.

For example part #2 may be implemented with the following approach:
* find the part of init scripts that parses /etc/fstab, checks and
  mounts filesystems
* rewrite it in C as a separate program (let's call it `initmountd`)
  which does exactly same things but in C
* then change that `initmountd` in the way that it puts autofs
  mountpoints on all directories that are not marked as "noauto" and
  then goes background and continues to check/mount filesystems in
  background
That's all. One new program and a few init scripts changed. No new
configurations needed, nothing is broken, it's backward and forward
compatible, meaning that for systems that don't have autofs support
initmountd just won't go background and everything will be the same.

Part #1 is not that short to explain, but its idea is the same. If we
want to track dependencies between services with their sockets then...
let's track it. That's what LSB Header is for. The only change is that
socket must be explicitly shown there. So instead of:
  # Provides:          mysql
there would be:
  # Provides:          mysql
  # Provides:          unix:/var/lib/mysql/mysql.sock
  # Provides:          tcp:mysql
These sockets would be created by init daemon and passed to mysqld
on startup. And if another service have something like:
  # Required-Start:    unix:/var/lib/mysql/mysql.sock
it can be started in parallel to mysql server.
That's _almost_ all. An extension to LSB header and a patch to init
daemon for support of this extension and init-based sockets creation is
all that needed for the part #1. And again everything is backward and
forward compatible.

There're a lot of implementation details there. For example such parallel
startup still uses a fixed S??/K?? order of running services. And it's a
good thing because having services in order allows not to worry about
circular dependencies, there can be no circle in a straight line.

It also have an advantage that you can always tell whether particular
service is started or not: if there's rc.d S?? link - it's started on
boot. While for systemd you're having a hard time manually tracking
dependencies or have to use a separate tool to answer this simple
question.

This also leaves all the logic in place. No new on-demand inetd-like
start, no new configurations, no need to rewrite scripts for hundreds of
packages.

I believe that these features are the main systemd features worth
implementing. But existing sysvinit scripts system is flexible enough
to implement more. For example currently rc.d symlinks use only two
prefixes: S?? and K?? that, IIRC, stand for `Start` and `Kill` services.
And that's enough for init daemon. But if we want more, i.e. want to
add a third type of service, that starts on-demand, we can use O??
prefix for it. That adds a new feature still leaving everything backward
(but not forward) compatible. It's even possible to generalize this
scheme for respawn-gettys - use R?? prefix for them in rc.d.

Some people like systemd units because they're short. That feature
can also be implemented using existing scripts as another separate
mini-feature with something like this:
  #!/bin/sh
  ### BEGIN INIT INFO
  # Provides:             sshd
  # Required-Start:       $remote_fs $syslog
  # Required-Stop:        $remote_fs $syslog
  ### END INIT INFO
  ExecStart="/usr/sbin/sshd -D"
  source /etc/default/initscript-shortcut
It still makes everything backward compatible, and allows those who want
a great flexibility to write bash scripts, while allowing others to use
a shortcut /etc/default/initscript-shortcut which would implement the
rest for them.

There may be something else I forgot. The idea is that it's possible
to modify an init system making it even better than systemd is and still
don't break anything.

But the main problem is that I currently have neither time nor major
experience to implement that. I can answer any questions and I hope I
can suggest solutions to every possible problems related to these ideas.
But I'm not as fast coder as Lennart is and cannot promise that I'll
have anything even remotely working in the nearest future. That's why
I'm writing my ideas here, in hope, that someone much more experienced
than me will like them and may work (or maybe already working?) on
something similar.

What do you think? Is it right/wrong? Would debian accept such change
if it's actually implemented?
-- 
Thanks for reading