provide a more complete description of the actions of the init script. provide a brief description of the actions of the init script. For example, if a service should run in runlevels 3, 4, and 5 only, specify "Default-Start: 3 4 5" and "Default-Stop: 0 1 2 6". defines the run levels where the script should be started (stopped) by default. Normally you would include here the same facilities as those used with the Should-Start keyword.ĭefault-Start: run_level_1 ĭefault-Stop: run_level_1 defines the facilities that if present should be stopped after this service. Consider using virtual facility names as described below if adequate. This allows for weak dependencies which do not cause the service to fail if a facility is not available. Nevertheless, the script can still start if the listed facilities are missing. defines the facilities that if present should start before the service provided by the script. Normally you would include here the same facilities as for the Required-Start keyword. The facility provided by this script should stop before the listed facilities are stopped to avoid conflicts. defines facilities used by the service provided by the script. If no boot facility is specified it means that this script can be started just after the bootstrap without local filesystems mounted, nor system logger, etc. defines facilities that must be available to start the script. (Virtual facility names listed below are defined outside the init.d scripts.) Facility names should be unique within the distribution, to avoid 'duplicate provides' errors when a package is installed. Boot facilities provided by scripts must not start with '$'. sh if the file name has such an ending) but one can in the exceptional case also use the name of the service(s) that the script replaces. Normally you should use the script name as boot facility (without. defines boot facilities provided by this init script such that when the script is run with the start argument, the specified boot facilities will be deemed present and hence other init scripts which require those boot facilities must be started at a later stage. On the other hand, all lines inside the block shall be of the form # : arg1 Īnd begin with a hash character '#' in the first column followed by one single space, except for the lines following the Description keyword. Where all trailing spaces shall be ignored. The block shown above has a special rigid format delimited by the lines # Description: Enable service provided by daemon. # Short-Description: Start daemon at boot time There is a separate wiki page documenting that effort.īy documenting the run-time dependencies for init.d scripts, it becomes possible to verify the current boot order, order the boot using these dependencies, and run boot scripts in parallel to speed up the boot process.Īdd a block like this in the init.d script: # BEGIN INIT INFO Maintainers should review that section and review / adjust their init.d scripts accordingly.Īdding run-time dependencies was a release goal for Lenny, and dependency based boot sequencing is the default in Squeeze. Log messages using the Init.d functions: log_success_msg, log_failure_msg and log_warning_msg (This would introduce consistent output in scripts, as requested in Īnd should also follow Debian Policy, chapter 9.4 Console messages from init.d scripts)įull information on the actions (and return codes) that LSB scripts have to honor are available at LSB 3.1, Chapter 20.2. "Status" support has been requested into policy, see #291148 and LSBInitScripts/StatusSupport. 
All of those, except for status, are required by the Debian Policy, chapter 9.3.2 Writing the scripts. Provide, at least, the following actions: start, stop, restart, force-reload, and status.
#Repetier server init.d script how to
This is a short documentation about how to make an Init Script LSB (Linux Standard Base)-compliant based on the Chapter 20 of the LSB 3.1. This does not affect the Debian requirement to include LSB style dependency information in the init.d scripts used by non-systemd installations.Ī status page for dependency based boot sequencing is available. Note: Debian discontinued LSB support in 2015, see DebianLsb and for example lwn.net: Debian dropping the Linux Standard Base.
0 kommentar(er)
