On Wed, Feb 16, 2000 at 11:35:28AM -0500, Theodore Y. Ts'o wrote: > Initiscripts management proposal for the LSB > ============================================ > > XXX The idea is to put together a scheme which can provide much faster > (parallel) boot startups, but not require distributions should use it. > It should be compatible with with the old rc.d/init.d scheme. FWIW, I coded up something like this a while ago (well, I took some stuff that Richard Woodcock and Richard Braakman had started, and made it actually do stuff). It didn't actually go noticably faster on my machine (it's uni-processor, and doesn't have any particular problems with waiting for DNS lookups etc), so we basically just dropped it. The headers were required to include: # Name: <foo> # Needs: <bar> <baz> # Provides: <quux> or similar. Lots of fun, didn't actually do much good. [0] > Packages that need to execute a script at bootup and/or shutdown will > provide an init.d file. This file is either installed in some > standard directory (i.e. /etc/init.d --- which may be a symbolic link > to some other location), or we specify the use of an installation > shell script which copies the file to the correct. This is more ^^^ location > complicated; I would prefer a standard installation directory, which > may be a symlink if necessary. Agreed. /etc/init.d/ for everyone's much more convenient. > In the init.d file, information about the shell script is delimited by > the strings "### BEGIN INIT INFO" and "### END INIT INFO". Inside > this block declarations shall take the form of "# <keyword>: [arg1] > [arg2] ..." The following keywords, with their arguments are defined > in this specification: > > # Provides: <boot facility 1> [<boot facility 2> ...] > # Required-Start: <boot facility 1> [<boot facility 2> ...] > # Required-Stop: <boot facility 1> [<boot facility 2> ...] > # Default-Start: <run level 1> [<run level 2> ...] > # Default-Stop: <run level 1> [<run level 2> ...] > # Description: <multiline description> The description probably has i18n issues. (i18n of comments in a script is probably less convenient than i18n of the script itself, eg, and introducing new things which need to be translated using different techniques seems unnecessary) What's the point of `Default-start' and `Default-stop'? For one, run-levels on different distributions mean different things. For another, run-levels on different systems mean different things. I wonder if this wouldn't be better being just a system-wide default (all new packages go into run levels 2, 3, 4, 5), and/or depedant on the `Required-Start' tag (if it depends on X, only start it in runlevel 5) What's `Required-Stop' header for? Other services that should be stopped before this service? That might be cumbersome. For example, the portmapper ought to be stopped after the NFS server, but you probably don't want to have: /etc/init.d/nfs-server # Required-Start: portmap /etc/init.d/portmap # Required-Stop: nfs-server Is there any reason the `Required-Start' headers can't just be reversed for stopping? IIRC, that's what I did in run-scripts, and it seemed sensible at the time. > Additional keywords may be defined in future LSB specifications. > Distributions may define local extensions by using the prefix > "X-<distribution name>" --- for example, "X-RedHat-foobardecl", or > "X-Debian-xyzzydecl". What's with the "decl"s? > An init.d shell script may declare using the "Requires: " header that ^^^^^^^^^^ Presumably required-start: now? > it must not be run until certain boot facilities are provided. This > information is used by the installation tool or the boot-time > boot-script execution facility to assure that init scripts are run in > the correct order. This seems like it could be a nuisance to achieve with existing SysVinits; there's only so much room for dependencies between S30foo and S40bar. Perhaps adding a rider strongly discouraging their use wherever possible would be good? (/usr being mounted is an obvious requirement, having /etc/init.d/exim already running doesn't matter so much as long as /usr/{sbin,lib}/sendmail still queues mail, eg) Also, what should happen if a dependency *can't* be met? For run-scripts I just treated the `provides/needs' clauses as advisories, and ignored any circularities or missing scripts. Anything more complicated at boot time seemed unreasonable. > In a multiline description, each continuation line must begin with a > '#' followed by a tab character. The multiline description is > terminated by the first line that does not match the '#','Tab' > continuation specification. I'm inclined to think an optional `/etc/init.d/foo about' would make more sense here. Easier to get at, and (as I understand it) easy to i18n. > Installation of init.d files > ============================ > > An init.d file is installed by copying it into /etc/init.d (which may > be a symlink to another location). This can be done by the package > installer. During the package's postinstall script, the program > "/usr/lib/lsb/install_initd" to configure the distribution's boot > script system to call the package's init.d file at the appropriate > time. > > The install_initd program takes a single argument, the pathanme to the > /etc/init.d file. For example: > > /usr/lib/lsb/install_initd /etc/init.d/inet (FWIW, `install-initd' with a hyphen rather than an underscore would look much less kludgy to me, but anyway.) Isn't the /etc/init.d/ redundant? I'd be a lot more comfortable, too, if there was a proof of concept implementation of this that worked with the existing SysVinit startups Debian (and RH? and everyone else?) use and the `requires/provides' stuff discussed above. ie, one that somehow translates the dependencies into Sxx and Kyy numbers. > There should be a tool available to the user (ala RedHat's chkconfig) > which can be used by the system administrator to easily manipulate at > which init levels a particular init.d script is started or stopped. > This specification currently does not specify such an interface, > however. (XXX should it?) XXX, possibly. Possibly it should do so separately. I think distinguishing the goals of `make it so ISVs can distribute packages installable on Debian, RedHat and SuSE', and `make it so admins can copes with SuSE, RedHat and Debian with minimal retraining'. I think the former's much more important. (IMAO, this area (updating rcX.d/* links) is a place where Debian's severely lacking) > Facility names > ============== > > Facility names that begin with a dollar sign ('$') are system facility > names, defined by the LSB, and MUST be provided by distributions. LSB > applications should not provide system facilities. This document > defines the following system facility names: > > $local_fs all remote filesystems are mounted > $remote_fs all remote filesystems are mounted (note > in some cases /usr may be remote. Is there any reason these are separate? `$usr_mounted' or something would make more sense to me. What, if any, certainty does depending on `$local_fs' alone buy you? > $network low level networking (ethernet card; may > imply PCMCIA running) This interests me, and I plan on doing some more toying with it later. I've written a tool `ifupdown' [1] which provides two binaries `ifup', `ifdown', modelled somewhat after the way RedHat does it. (With the provisos that RH didn't supply manpages when I looked, and I don't use RH enough to really grok how they're meant to behave) This uses a single config file, /etc/network/interfaces, and calls ifconfig, or pump, or whatever as appropriate. It has some support for PCMCIA style devices, but pcmcia-cs currently doesn't have support for it. FWIW, my /etc/network/interfaces on my laptop looks like: iface lo inet loopback iface eth0 inet dhcp noauto # PCMCIA cards don't come up at bootup In future, I expect it to look more like: iface lo inet loopback scheme home iface eth0 inet dhcp noauto scheme humbug # local LUG iface eth0 inet static noauto address 192.168.105.26 netmask 255.255.255.0 gateway 192.168.105.1 var name-server 192.168.105.1 130.102.2.15 With the `name-server' variable being passed to an external script that modifies /etc/resolv.conf appropriately (as pump already does for dhcp). What's my point? My point is, this'll mean I'll need an ip-up.d directory to collect all the scripts that find the various `var's that my configuration file contains or the, eg, DHCP picks up from its server. This seems very similar to having an /etc/rcNET.d/ directory, but with a couple of extra things: they don't all start services, exactly; and they read from some sort of variables to get the exact configuration. There's an extra problem here. Consider a home network connected at times (but not 24/7) to the Internet via PPP. It might want, eg, to have a name server to resolve the local (reserved) IPs, but need to be restarted to cope with the fact that a new route's been made, and some upstream servers are now available. So the same script needs to be executed a couple of times, without actually changing runlevels (we've always been multiuser, network, just that the network's expanded a bit). So that's just a note. For machines with changing network situations, network services can be weird. They can need to be told stuff about their particular environment, and can need to be restarted. They're kinda special. Or, at least, that's how it seems to me today. I haven't worked this all through yet, and I haven't implemented it, and so on. So take it with a grain of salt. > $named named is operational Hmmm. I wonder if this shouldn't be almost implicit in $network. Before the $network is up, you should have everything you need in /etc/hosts. Immediately afterwards, you should have bind running. That said, what about $portmap, needed for NFS, and presumably other things. > $netdaemons all network daemons are running What's this for? > Script names > ============= > 1) Assigned namespace. This namespace consists of names which > only use the character set [a-z0-9]. This space is > desireable for scripts which system administrators may > often wish to run manually: e.g., "/etc/init.d/named > restart" This is /etc/init.d/bind restart in Debian. /etc/init.d/ names in Debian are taken after the program providing the service, not the service itself; so if you want to restart the SMTP daemon, you need to know which one you're actually running (/etc/init.d/sendmail, exim, smail, postfix, etc). It might be worth considering /etc/init.d/smtpd being a link to the approrpiate one of these, via, eg, the alternatives mechanism from Debian's POV. Similarly, it might be worth recommending that the mail server be available to be stopped and started by admins as that name. > In order to avoid conflicts these names must be reserved > through the LANA (Linux Assigned Names/Numbers > Authority). LANA doesn't actually exist at this time, right? > 2) Hierarchical namespace. This namespace consists of scripts > names which look like this: <hier1>-<hier2>-...-<name>, > where name is again taken from [a-z0-9], and where > there may be one or more <hier-n> components. <hier1> > may either be a [a-z0-9] name assigned by the LANA, or > it may be owners' DNS name in lower case, with at > least one '.'. I.e., "debian.org", > "staroffice.sun.com", etc. I can't imagine Debian using this, fwiw. Registering a LANA name for the package, and using that would be much more likely. (As such, corel.com-wordperfect, or similar might be a better example) It may be a good idea to reserve names in all caps, like README, for distributions to use as documentation, examples, and whatnot. > In general, if a package or some system function is likely to be used > on multiple systems, the package developers or the distribution SHOULD > get a registered name through LANA, and disrtibutions should strive to ^^ > use the same name whenever possible. For applications which may not > be "core" or may not be commonly installed, the hierarchical namespace > may be more appropriate. An advantage to the hierarchical namespace > is that there is no need to consult with the LANA before obtaining an > assigned name. > > This specification shall pre-define the following script names as: > > apmd atd crond dhclient dhcpcd gpm halt identd inet > httpd kudzu klogd lpd mcserv named nfs nfslock pcmcia > portmap random routed rstatd rusersd rwhod sendmail smb > snmpd sshd syslog xfs xntpd ypbind Hmmm. May I suggest two lists? Generic services (httpd, smtpd, named, etc) and specific implementations (apache, exim, bind, etc). There's a list of the 250 or so init.d scripts currently in Debian at http://master.debian.org/~ajt/initd-scripts.txt if that's of any help. > XXX Some of these packages, such as sshd, aren't currently being > distributed by distributions, but may in the future. I can assure you, sshd definitely is distributed by some distributions :) > Functions > ========= > > Each LSB complaint init.d script must source the file ^^ > /usr/lib/lsb/init-functions. This file must cause the following shell ^^^^ will? > script commands to be defined. This can be done either by adding a > directory to the PATH variable which defines these commands, or by > defining bash aliases. Or using shell functions, too. > While the distribution-provided aliases may > choose to use bash extensions (at the distribution's option), the LSB > init.d files themselves should only depend in /bin/sh features as > defined by POSIX.2. Or specify /bin/bash as their interpretor? (And have the entire package Depend: on bash, presumably) There's probably no big deal eitherway here. Note that their are lots of little bashisms people fall into when /bin/sh is bash. Using `==' in [ ... ] clauses, instead of `=' for example. It may be a better idea just to encourage people to use /bin/bash and be done with it, as far as the user experience goes. > start_daemon [-f] [-n nicelevel] pathname [args] > killproc basename [signal] > pidofproc basename Hmmm. Giving start_daemon a `fork to background' option might be useful. Debian's start-stop-daemon utility lets you specify a pid-file for killing a process, or an executable (in which case it compares against /proc/<foo>/exe), and some other things. It'd probably be a good idea to compare against that, and incorporate the good features. > log_success_msg "message" > log_failure_msg "message" > log_warning_msg "message" What do these buy us over `echo' or `gettext -s' ? Debian's init scripts tend to be of the form: echo -n "Starting foo: foo" start-stop-daemon --start foo echo "." which is pretty and helpful if your startup dies. Someway of achieving something vaguely equivalent might be nice. Cheers, aj [0] http://azure.humbug.org.au/~aj/run-scripts-1.0.tgz Warning. Modem link. Only 10k, though. [1] Which is on CVS at sourceforge. Project name ifupdown. It's also in netbase in Debian, and installed for non-PCMCIA setups by the potato (frozen) bootfloppies. -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds
Attachment:
pgpxTx7Z2BjGt.pgp
Description: PGP signature