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 _______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
