LSBInitScripts
以下是译文。
怎样LSB化 Init Script
一个可用的状态页，讲解了引导序列的依赖关系。
这是一篇简短文档，介绍了怎样使 Init Scripe 符合LSB(Linux Standard Base，Linux标准规范)—遵从Chapter 20 of the LSB 3.1的规范。
LSB系的 init scripts 需要
- 至少提供以下操作：start, stop, restart, force-reload, 和 status。所有这些，除了status，都需要按Debian Policy, chapter 9.3.2要求的编写脚本。”Status”的支持已经要求转化为政策，见＃291148和LSBInitScripts / StatusSupport。
- 返回正确的退出状态码。
- 标明运行时依赖关系。
- [可选的]使用的init.d的函数：log_success_msg，log_failure_msg和log_warning_msg来记录日志消息（这会使输出脚本一致，就像http://lists.debian.org/debian-devel/2005/06/msg00729.html中要求的，
同时也应该遵循 Debian Policy, chapter 9.4 Console messages from init.d scripts）
LSB脚本必须实现的操作(包括返回码)的全部信息的在LSB 3.1, Chapter 20.2. Init Script Actions可见。维护人员应审查该节和审查/相应调整对应的init.d脚本。
运行时依赖
添加运行时的依赖性对于Lenny是一个发布目标(release goal?)，基于引导顺序的依赖性是默认的在Squeeze中。有一个单独的wiki页面记录这一成就。
通过为init.d脚本添加运行时依赖关系，使得验证当前的引导顺序，使用这些依赖关系启动，并行运行启动脚本，以加快引导过程这件事情变得可能。
在init.d脚本中添加的块可能像这样的：
### BEGIN INIT INFO
# Provides: scriptname
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO上面显示该块有一个特殊的刚性格式，由这两行线划定
### BEGIN INIT INFO
### END INIT INFO
其中所有尾随空格将被忽略。另一方面，在块内的所有行应是这样的形式：
＃ {keyword}: arg1 [arg2...]
以第一列中的散列字符’#’为开始,再接着是一个单独的空格，除了接下来的描述关键字的行以外。定义了以下关键字：
Provides: boot_facility_1 [boot_facility_2…]
以下是谷歌翻译结果，还未人工修正。
定义此初始化脚本，这样提供的引导设施时运行该脚本用start参数时， 指定的引导设施将被视为需要这些引导设施存在，因此其他初始化脚本 必须在以后阶段启动。通常情况下，你应该使用脚本的名称作为启动设备（不.SH如果文件名中有这样的结局），但是可以在特殊情况下也可以使用的名称 服务（S），该脚本代替。由脚本提供的引导设施，不能以“$”。（下面列出的虚拟设备名称中的init.d脚本之外定义。）设备名称应该是唯一的分布范围内，以避免在安装包时，“重复提供”错误。
所需的启动：boot_facility_1 [boot_facility_2 …]
定义的设施必须可用来启动脚本。如考虑使用虚拟设备名称下面，如果足够。如果没有指定启动工厂则意味着该脚本可以引导后，刚开始没有本地文件系统安装，也没有系统日志程序等等。
所需-停止：boot_facility_1 [boot_facility_2 …]
定义了用于通过由脚本提供的服务设施。该脚本提供的设施应停止列出的设施都被停止，以避免冲突之前。通常你会在这里有相同的设施作为必选启动关键字。
应该启动：boot_facility_1 [boot_facility_2 …]
定义如果存在的话应该由脚本提供的服务前，启动设备。尽管如此，该脚本仍然可以启动，如果所列设施缺失。这使得弱相关性不导致服务失败，如果一个功能不可用。考虑如下所述，如果充分利用虚拟设备的名称。
应该-停止：boot_facility_1 [boot_facility_2 …]
定义如果存在应此服务后停止服务。通常你会在这里有相同的设施，那些具有如若启动关键字使用。
默认启动：run_level_1 [run_level_2 …]
默认-停止：run_level_1 [run_level_2 …]
定义运行级别，其中的脚本应启动（停止）默认情况下。例如，如果一个服务应该在运行级别3，4运行和5只，指定“默认启动：3 4 5”和“默认停止：0 1 2 6”。
短说明：SHORT_DESCRIPTION
提供初始化脚本的动作的简要说明。不限于文字单行。
说明：multiline_description
提供初始化脚本的操作的更完整的说明。可以跨多行。在多行的描述，每个续行必须以’＃’后面制表符或’＃’后面至少有两个空格字符。多行描述由不匹配此条件的第一行终止。
的X启动前：boot_facility_1 [boot_facility_2 …]
的X停止-后：boot_facility_1 [boot_facility_2 …]
提供反向相关性，这看起来好像列出的设施必须要启动，并在包装上使用这些标题应该停。
的X互动：真
表明，该启动脚本可以与用户进行交互，请求一些输入（例如，一个口令）。这确保单独运行脚本时引导系统启动的parallell脚本和直接访问该终端。
对于依赖性跟踪的提供，须─和前肩关键字是重要的，其余的是未使用的。默认运行级别所使用的程序命令初始化脚本（如insserv）来跟踪时，一个服务被添加在第一时间更新它的rc＃.d的目录下，并应反映服务的意图。
有一些“虚拟”的设施名称，在上市 [LSB 3.1]。这些都是：
localfs所有的本地文件系统挂载。是写在/var所有脚本/需要依靠这个，除非他们已经依赖于
remote_fs。
网络低级别的网络（以太网卡，可能意味着PCMCIA运行）
命名
守护程序可以提供主机名解析（如果存在的话）正在运行。例如，守护程序查询DNS，NIS +，或LDAP。
端口映射守护进程提供？SunRPC/ONCRPC在RFC1833（如果存在）定义的端口映射服务正在运行的所有远程
remote_fs
所有的文件系统挂载。在一些LSB运行时环境，文件系统，如/ usr可能是远程的。如果脚本需要一个装在/ usr /，它需要依赖于
remotefs。根据
remote_fs脚本并不需要依赖于
localfs。在关闭过程中，需要sendsigs之前运行的脚本杀死所有进程应取决于
remote_fs。
系统日志系统记录仪正常运行
时间
系统时间已定，例如通过使用一个基于网络的时间程序作为NTP或RDATE，或经由硬件实时时钟这样。注意，只是根据NTP不会导致一个精确的时间的NTP刚开始之后。它通常需要几分钟，直到NTP实际调整时间。还要注意的是标准insserv.conf只是列出hwclock的为
时间。
所有
通过支持设施insserv毕竟脚本不依赖于
所有，在引导序列结束，开始一个脚本。这对启动顺序只有工作，没有停止订购。根据这取决于
都将提供不正确的顺序一个脚本，为依赖于$所有脚本依赖于它的脚本之后将开始。
其他（非系统）的设施可以由其他应用程序来定义。这些设施应采用相同的命名来命名启动 脚本中定义的约定。见提议Debian的特定的虚拟设备列表以获取更多的信息。
本节大多最初基于从消息由皮特Reinholdtsen上的Debian-devel软件包。
BTS报告与LSB的头被usertagged。
常见问题
是否有可能启动一个给定的初始化脚本尽可能晚？
是的，如果你真的想这样做，insserv认识使得脚本将在年底执行的$所有虚拟设备的名称。
是否可以添加额外的关键字？
如果没有当前的关键字，你可以用你的需求，LSB允许使用前缀X-本地扩展。例如，X-Debian的foobardecl或X-Ubuntu的fastdecl。
是否可以指定给定的脚本应的另一个脚本之前启动？
不存在这样的标准定义的报头，但在实施了提议的延伸insserv（自1.09.0-8版本）封装。使用X-启动前和X-停止-后提出的标题？的SuSE。
我不应该等到Debian政策的变化？
Debian的政策变化是缓慢的，即使引进的东西（的例子，见＃291148），其中大部分维护者同意是好的，因为我们必须首先要等待许多软件包，以将其纳入政策之前做的事情以同样的方式。因为我们想成为LSB标准，init.d脚本均可以调节，现在是LSB兼容的。
什么是“适当的”退出状态码？
纵观＃208010，这似乎颇具争议。非零退出代码，甚至可能导致破裂，而LSB在这里Debian政策冲突。
CategoryBootProcess
扫一扫
8688
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
