Links to More Development
Links to various init systems:
Init Metadata
These are my thoughts on a generic init system description for our spells.
Currently (11 Oct 2005) Source Mage only support a single init system simpleinit-msb. There are several disadvantages to this. Firstly, Source Mage's "motto" is to be distro about choice, yet there is no choice when it comes to supported init systems. You're more than welcome to write and manage your own, however. Second simpleinit-msb is no longer maintained. The author has said that it does what he want's it to do and that's it, he's done. This means a bit of extra work for us providing patches to things that are found broken or needed. Finally, simpleinit-msb is missing a few critical features for a server. As a desktop init system it's usually sufficient, but it lacks a couple features that are quite useful. For one, respawn support. The ability to ensure that a process is always running is necessary on a server system. Also, UPS support to allow graceful failure of the machine. Without the ability recognize that the computer is asking you to turn off the UPS instead of just calling the kernel power off, you cannot control how your computer, or network of computers, responds to a power outage.
Added 7 Nov 2005: You cannot create an arbitrary runlevel. Gentoo's power management guide uses this to enable switching to a low power runlevel. I'd think it'd be a useful thing to be able to do. ref: http://www.gentoo.org/doc/en/power-management-guide.xml
Even MSB him self agrees 
: http://linuxfromscratch.org/pipermail/lfs-dev/2003-August/036302.html
There were reasons simpleinit-msb was chosen as the init system:
- No symlink farm
- Dependencies
- Easier for sorcery to manage scripts
- And probably others that I'm not aware of.
Now on to my proposed solution for this.
Init Metadata
I've thought about this for a while and determined that a library that sorcery can call to install an initscript would probably be best. We abstract out the init script stuff so that the information in the spell doesn't match any one init system specifically but provides enough information to generate, or fill a template, one for any init system.
Information Required
First, we need to define a naming scheme for the init scripts. Using the daemon name is perfectly acceptable. If for some reason you'd want to have two named's running on the same computer you'd have to manage your own initscripts anyway.
Needs
What the init script has to have running to start. If the needs are not running then the script cannot start and fails.
Wants
What the init script would like to have running. Not strictly necessary, but would be preferred. Example: sshd You'd prefer to have the network up, but you don't necessarily need it. Say you're testing a new PAM configuration and you want to test it via the loopback before turning on the network connection.
Alternate implementation: The way it's currently implemented. If the script exists and it's WANTed, then it has to succeed, otherwise ignore it.
Before
General dependency ordering. The script tries to start before the listed scripts. Could replace WANTS, depending on implementation of WANTS.
After
General dependency ordering. The script won't start after the listed scripts, regardless of failure or success. Could replace WANTS, depending on implementation of WANTS.
Program
If it's a simple program like slapd or squid then this should just contain the fully qualified path to the program to run. Also, if you've got yourself a wrapper script for a process that forks into the background, but you want to keep it under respawn, you could specify said script as the program.
Arguments
Any arguments that get passed to the program. I would assume that these arguments are only used in start and restart.
Respawn
I'm not sure if this needs to be stored in our metadata or not, but this flag would be whether or not the init system should monitor the process and keep it running.
Runlevels
This is a list of all the runlevels that the init script should be running in. Obviously, this goes into play for sysVinit. For such systems like simpleinit-msb it's not so important. It'll be up to the implementations of the init script managers that are written to determine exactly how this is used. My thoughts were:
RUNLEVEL="3 4 5" sysVinit: It'll be running in 3, 4 and 5 simpleinit: It'll be started in 3
Functions
There are the top level functions that each init script manager/creator needs to provide.
- start
- stop
- restart
- reload
- status
These can all or none be overridden by the init script metadata. Should probably be overridden if no PROGRAM variable is specified.
A library of functions would be even more useful. The functions would have to be flexible enough to accomidate different scritps. For example: the kill_proc function should be able to take a single pid or lots of pids.
So those are my basic thoughts on how the init script system should be managed.
Notes and random thoughts
For systems like runit (which I like a lot), it gets significantly trickier. There's not really a "stop command," since it works entirely off process monitoring. Also some things that always background regardless of the users preference tend to cause problems.
Global "telinit" style program - Invoke
The old script invoke for menu generation is dead, so I thiefed the name. The global initsystem management tool will be invoke. The program used to manipulate and manage these initscripts needs to do a few things things (All of which should probably be modular):
- Enable
- Disable
- Start
- Stop
- List-Enabled
- List-Disabled
- List
- Status
- Switch
- Runlevels
- Move
- Install
Description of the commands
Enable
Simply enables the script so that it will be run by the init system. I haven't determined yet how to ensure things like bootenable and bootdisable, because they don't always work the same with different init systems. runit doesn't really have a bootenable thing, when you "enable" it runsvc starts watching it.
Disable
prevent the script from being started by the init system
Start
Have the initsystem start the script
Stop
Have the initsystem stop the script
List-Enabled
display a runlevel organized list of the enabled scripts
List-Disabled
display a runlevel organized list of the disabled scripts
List
display a runlevel organized list of all the initscripts
Status
Display some status of the requested script
Switch
Have the system change to a different runlevel
Runlevels
Display all the available runlevels
Move
Move an initscript to a different runlevel
Install
Either install a file into a specified runlevel, or install the init scripts from the specified spell.
Also we can implement something to be LSB compliant with our initscripts http://refspecs.freestandards.org/LSB_2.1.0/LSB-generic/LSB-generic/iniscrptact.html /etc/init.d/script needs to exist and work somehow... So that program should handle the installation and management of the scripts so that it feels the same for each user.