This is the internal documentation for invoke-rc.d, as written by Henrique M Holschuh <firstname.lastname@example.org> This document can be found on the web as well at http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt There is also the Debian BTS entry for the invoke-rc.d policy change at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=76868 INVOKE-RC.D (/usr/sbin/invoke-rc.d) interface: ============================================== The interface for all implementations of invoke-rc.d is mandated by the base implementation in the sysvinit package, just like it is done for update-rc.d. There is a provision for a "local initscript policy layer" (read: a call to /usr/sbin/policy-rc.d if this executable is present in the local system), which allows the local system administrator to control the behaviour of invoke-rc.d for every initscript id and action. It is assumed that this script is OPTIONAL and will by written and provided by packages other than the initscript system (sysvinit and file-rc packages). The basic interface for all implementations of policy-rc.d is mandated by the requirements of the base implementation of invoke-rc.d. This interface will be described either in the manpage of invoke-rc.d, and in a text file stored in /usr/share/doc/sysvinit/ by package sysvinit (which will host the base implementation of invoke-rc.d). Proposed script interfaces: invoke-rc.d [options] <basename> <action> [extra initscript parameters...] basename - Initscript ID, as per update-rc.d(8) action - Initscript action. Known actions are: start, [force-]stop, restart, [force-]reload, status (status is there because of the LSB. Debian does not use it). extra initscript parameters: These parameters are passed to the initscript as is, after the action parameter. <action> is always the first paramenter to the initscript, and may be modified by fallback actions or policy-rc.d requests. Note, however, that the extra parameters are not dropped or modified even if the action (first parameter) is modified. Options: --quiet Quiet mode, no error messages are generated by invoke-rc.d; policy-rc.d is also called with --quiet if this option is in effect. --force Try to run init script regardless of policy and non-fatal errors. Use of this option in automated scripts is severely discouraged as it bypasses integrity checks. If the initscript cannot be executed, error status 102 is returned. Do note that the policy layer call (policy-rc.d) is NOT skipped, although its results are ignored. --try-anyway Try to run the initscript even if a non-fatal subsystem error is detected (e.g: bad rc.d symlinks). A 102 status exit code will result if init script fails to execute anyway). Unlike --force, policy is still enforced with --try-anyway. --disclose-deny Return status code 101 instead of status code 0 if initscript action is denied by local policy rules or runlevel constrains. An warning is generated if the action is denied. --query Returns one of status codes 100-106, does not execute the init.d script. Implies --disclose-deny and --nofallback. Status codes 104-106 are only generated by this option. Note many messages are still sent to stderr in --query mode, including those regarding policy overrides and subsystem errors. Use --quiet if silent --query operation is desired. --no-fallback The policy layer (policy-rc.d) may return fallback actions to be run instead of the requested action. If this option is active, a fallback action request will be ignored and a "action not allowed" reply used in its place. This is probably a BAD idea unless you know exactly what you're doing. --help Outputs help message to stdout Unknown actions may generate warnings, but are passed to the underlying initscript anyway. The reason for the warning is simple: It is very unlikely that an unknown action (by invoke-rc.d) will be known to the policy layer (policy-rc.d), and therefore it may cause an initscript to execute an action which the local system administrator would have not allowed had he known about it. If policy-rc.d is not present, no warnings for unknown actions are generated. Should an initscript be executed, invoke-rc.d ALWAYS returns the status code returned by the initscript. Initscripts should not return status codes in the 100+ range (this is also a LSB requirement). Exit status codes (LSB compatible): 0 : success either the init script was run and returned exit status 0 (note that a fallback action may have been run instead of the one given in the command line), or it was not run because of runlevel/local policy constrains and --disclose-deny is not in effect. 1 - 99 : reserved for init.d script 100 : init script ID (basename) unknown init script not registered sucessfully through update-rc.d or init script does not exist. This error is fatal for most initscript systems. 101 : action not allowed requested action will not be performed because of runlevel or local policy constrains, and --disclose-deny is in effect. Note that a fallback action is NOT considered "action not allowed", unless --nofalback is in effect. 102 : subsystem error initscript (or policy) subsystem malfuncion. (e.g. broken /sbin/runlevel). Also, forced initscript execution due to --try-anyway or --force failed. 103 : syntax error 104 : action allowed --query is in effect; init script would be run if not for --query. 105 : behaviour uncertain cannot determine if action should be carried out or not, and --query in effect. 106 : fallback action requested the policy layer denied the requested action, and supplied an allowed fallback action.