svc.startd - 服务管理工具主重启程序
/lib/svc/bin/svc.startd
svc：/system/svc/restarter：default
svc.startd 是服务管理工具 (Service Management Facility, SMF) 的主重启程序守护进程和所有服务的缺省重启程序。svc.startd 基于管理请求、系统故障或应用程序故障启动、停止和重启服务。
svc.startd 维护服务状态，并负责根据每个服务的依赖项来管理故障。
在系统启动期间会自动调用 svc.startd。如果发生任何故障，它都会重启。绝不应当直接调用 svc.startd。
有关所有重启程序通用的配置和行为的信息，请参见 smf_restarter(7)。
svcs(1) 会报告服务配置工具管理的所有服务的状态。svcadm(8) 允许操纵与服务的重启程序有关的服务实例。
带 "SMF_" 前缀的环境变量是保留的，且可以被覆盖。
svc.startd 将 smf_method(7) 中指定的 "SMF_" 环境变量提供给方法。缺省情况下，PATH 设为 "/usr/sbin：/usr/bin"。缺省情况下，提供给 svc.startd 的所有其他环境变量均继承自 init(8)。
重复的条目将缩减为单个条目。所使用的值是未定义的。将忽略未带 "<name>=" 前缀的环境条目。
svc.startd 不是通过命令行选项配置的。其配置是从服务配置系统信息库中读取的。可以使用 svccfg(8) 设置所有选项和属性。
options 属性组中的下列配置变量可供开发者和管理员使用：
一个 astring（如 scf_value_is_type 中所定义；请参见 scf_value_create(3SCF)），描述了在引导期间要输出到控制台的消息的缺省级别。支持的消息选项包括 quiet 和 verbose。使用 quiet 选项时，在引导期间向控制台输出的消息最少。verbose 选项针对所启动的每个服务输出一条消息来指示是成功还是失败。您可以使用 boot –m 选项来覆盖引导时的 boot_messages 设置。请参见 kernel(8)。
控制 svc.startd 的全局服务日志记录级别。一个 astring（如 scf_value_is_type 中所定义；请参见 scf_value_create(3SCF)），描述了要记录到 syslog（请参见 syslog(3C) 和 svc.startd的全局日志文件 /var/svc/log/svc.startd.log）中的消息的缺省级别。支持的消息选项包括 quiet、verbose 和 debug。quiet 选项将需要管理员干预的错误消息发送到控制台、syslog，以及 svc.startd 的全局日志文件。verbose 选项将需要管理员干预的错误消息发送到控制台、syslog，以及 svc.startd 的全局文件，并将不需要管理员干预的错误的相关信息发送到 svc.startd 的全局日志文件。还会针对所启动的每个服务向控制台发送一条消息。debug 选项将 svc.startd 调试消息发送到 svc.startd 的全局日志文件；将需要管理员干预的错误消息发送到控制台、syslog，以及 svc.startd 的全局日志文件；并针对所启动的每个服务向控制台发送一条消息。
一个 FMRI，用于确定用作缺省引导级别的里程碑。可接受的选项仅包括以下主要里程碑：
svc:/milestone/single-user:default svc:/milestone/multi-user:default svc:/milestone/multi-user-server:default
或特殊值 all 或 none。all 表示依赖于每个服务的一个理想化里程碑。none 是一个特殊的里程碑，除了主 svc:/system/svc/restarter:default 外，没有任何服务在运行。缺省情况下，svc.startd 使用 all 这个依赖于每个服务的综合性里程碑。如果指定了此属性，它将覆盖 inittab(5) 中的任何 initdefault 设置。
一个或多个 astring（如 scf_value_is_type 中所定义；请参见 scf_value_is_typ(3SCF)）；作为参数附加到缺省 svcio 调用（请参见 svcio(1)）。如果指定了多个值，则每个值将会串联并以单个空格 (' ') 字符分隔。有关更多信息（包括 svcio 的缺省调用），请参见下文中的“模板服务 (STENCILS SERVICES)”部分。
指示已请求了重新配置重新引导。包含必须切断重新配置重新引导的操作的服务可以通过检查此属性是否存在以及是否设为 1 来确认是否请求了重新配置引导。
此属性由 svc.startd 管理，且管理员不应对其进行修改。
配置错误（例如禁用 svc.startd）将记录在 syslog 中，但会被忽略。
svc.startd 管理的服务可能会显示为 smf(7) 中描述的任一状态。此重启程序未修改状态定义。
除了由受管的服务执行的日志记录外，svc.startd 还提供了一组通用的服务报告和日志记录机制。
报告属性 svc.startd 更新它管理的所有服务通用的一组属性。这些属性是可用来基于服务实例运行状况采取措施的通用接口。可以使用 svcs(1) 来方便地显示这些属性。
实例的当前和下一个（如果当前正在转换中）状态。
一个详细描述当前实例状态的更多信息的标题。svc.startd 管理的服务的可用辅助状态为：
fault_threshold_reached stop_method_failed administrative_request custom
custom
当 restarter/auxiliary_custom_state 设置为 custom 时，这是一个由方法提供的标题，它详细描述了当前实例状态的更多信息。
当 restarter/auxiliary_custom_state 设置为 custom 时，这是一个由方法提供的字符串，它详细描述了当前实例状态的更多信息。
当 restarter/auxiliary_custom_state 设置为 custom 时，这是一个由方法提供的文本域，可以在其中本地化 restarter/auxiliary_reason。
访问当前状态的时间。
执行服务实例所依据的主进程合同 ID（如果有）。
日志
缺省情况下，svc.startd 会将服务的重要重启程序操作以及方法标准输出和标准错误文件描述符记录到 /var/svc/log/service:instance.log 中。在系统全局位置（例如 /var/svc/log/svc.startd.log 和 syslog）中执行的日志记录的级别是由 options/logging 属性控制的。
开发或配置 svc.startd 管理的服务时，使用一组通用的属性来影响服务实例与重启程序之间的交互。
方法
smf_method(7) 中介绍了 svc.startd 提供的 fork/exec 模型的方法的一般形式。下列方法是 svc.startd 管理的服务支持的必需或可选方法。
在不中断服务的情况下从系统信息库或 config 文件重新装入任何适当的配置参数。这通常是通过对系统守护进程使用 SIGHUP 实现的。如果服务在不重新启动的情况下无法识别配置更改，则不提供 refresh 方法。
This method is optional and is invoked only on running (online or degraded) service instances.
Start the service.仅在应用程序可供使用者使用后返回成功。如果某个冲突的实例已在运行或服务无法启动，此方法将失败。
此方法是必需的。
Stop the service.在某些情况下，当某些或全部服务已停止时可调用 stop 方法。只有在方法返回时服务未完全停止的情况下才返回错误。
此方法是必需的。
Cleanup the service.This method is invoked when the service is transitioned from the maintenance state to the disabled state.Such a transition only occurs when the administrator applies svcadm disable to a service in the maintenance state.
This method is optional, defaults to :true if not defined.
如果服务不需要在某个必需的方法中执行任何操作，则它必须为该方法指定 :true 标记。
svc.startd 会接受为服务或任何特定方法指定的任何方法上下文。smf_method(7) 中描述的方法扩展标记可在 svc.startd 调用的所有方法中使用。
Properties
smf(7) 中提供了常规属性的概述。这些常规属性与 svc.startd 进行交互的具体方式如下所述：
如果将 enabled 设为 true，重启程序会尝试在服务的所有依赖项都满足后启动该服务。如果设为 false，服务将保持为禁用状态，不会运行。
如果此 FMRI 属性为空或设为 svc:/system/svc/restarter:default，则服务由 svc.startd 进行管理。其他情况下，由指定的重启程序负责（在它可用后）管理该服务。
如果 single_instance 设为 true，在任意时间，svc.startd 仅允许该服务的一个实例转换为 online（联机）或 degraded（降级）状态。
此外，svc.startd 管理的服务可以在 startd 和 logfile_attributes 属性组中定义下面列出的可选属性。
duration 属性定义服务的模型。可将其设为 transient、child（这两者也称为 "wait" 模型服务）或 contract（缺省值）。
ignore_error 属性（如果已设置）指定忽略的事件的逗号分隔列表。列表中的合法字符串值为 core 和 signal。缺省情况下，发生任何错误都会重新启动。
need_session 属性（如果设为 true）指示此实例应在其自己的会话中启动。缺省情况下不是这样。
utmpx_prefix 字符串属性规定实例在启动方法执行前需要一个有效的 utmpx 条目。缺省情况下，不创建 utmpx 条目。
权限字符串属性定义 svc.startd(8) 创建的日志文件的文件权限。权限值应采用三位数的八进制格式。对于 logfile 权限，缺省使用 '644'。
服务可以使用 smf_method_exit() 来请求正在进行的状态转换的特殊注意事项。如果此类请求是通过 exit() 发出的，未使用 smf_method_exit()，则会按下文的“服务故障”中所述处理它们。
当 start 或 refresh 方法请求 $SMF_EXIT_TEMP_DISABLE 时，svc.startd 将临时禁用服务并在不运行其 stop 方法的情况下将其置于禁用状态。适用时，start 或 refresh 方法可以在返回 $SMF_EXIT_TEMP_DISABLE 之前显式调用 stop 方法来正常关闭它可能已启动的任何进程。
当某个合同服务通过 start 或 refresh 方法请求 $SMF_EXIT_TEMP_TRANSIENT 时，svc.startd 将完成当前正在进行的状态转换，然后会将服务视为瞬态的来对其进行处理。
当 stop 方法请求 $SMF_EXIT_TEMP_DISABLE 或 $SMF_EXIT_TEMP_TRANSIENT 时，svc.startd 会将它视为已返回 $SMF_EXIT_ERR_OK 来对其进行处理。
当非合同服务通过 start 或 refresh 方法请求 $SMF_EXIT_TEMP_TRANSIENT 时，svc.startd 会将它视为已返回 $SMF_EXIT_ERR_OK 来对其进行处理。
SMF 服务为以下三种模型之一：
此服务执行一些操作并退出时无需启动任何长时间运行的进程。
此服务每当其子进程正常退出后都会重新启动。系统不会将正常退出的子进程视为错误。
此服务会启动长时间运行的守护进程或启动多个相关的进程，这些进程将作为服务合同的一部分绑定在一起。合同服务用于管理其启动的进程以及任何相关服务及其启动顺序。只需管理高级服务。
除了在 SERVICE METHOD SPECIAL REQUESTS 中描述的情况下，如果某个方法返回了非零退出代码或者未能在指定的超时过期之前完成，svc.startd 会认为该方法已失败。如果返回了 $SMF_EXIT_ERR_CONFIG 或 $SMF_EXIT_ERR_FATAL，svc.startd 会立即将服务置于维护状态。对于所有其他故障，svc.startd 将服务置于 offline（脱机）状态。如果某个服务处于脱机状态且满足了其依赖项，svc.startd 会重新尝试启动该服务（请参见 smf(7)）。
如果在定义的超时时间到期前，合同或瞬态服务没有从其 start 方法中返回，svc.startd 将向该方法发送 SIGKILL，并使该服务返回至 offline（脱机）状态。
如果 start 方法在一行中失败了三次，则该服务将优先于 FAULT_THRESHOLD。启动服务后，如果遇到的故障导致在 10 分钟内重新启动了五次，则 svc.startd 会将服务置于维护状态。
服务故障的状况是由服务模型（由 startd/duration 属性定义）和 startd/ignore_error 属性值的组合定义的。
如果发生下列任一状况，合同模型服务将失败：
服务中的所有进程都退出
服务中的任意进程生成核心转储
服务外的进程向某个服务进程发送了致命的信号（例如，管理员使用 pkill 命令来终止某个服务进程）
可以通过在 startd/ignore_error 中指定 core 和/或 signal 让服务忽略后两种状况。
将某个服务定义为瞬态的意味着 svc.startd 不会跟踪该服务的进程。因此，合同模型服务的上述潜在故障不会被认为是瞬态服务的故障。瞬态服务仅在出现某种方法故障状况时进入 maintenance（维护）状态。
每当与服务相关联的子进程退出时，"Wait" 模型的服务都将重新启动。退出的子进程不会被视为 "wait" 模型的服务的错误，且重复发生的故障不会导致转换为 maintenance（维护）状态。
svc.startd 继续为在启动运行级转换期间调用的服务提供支持。每个 /etc/rc?. d 目录是在构成等效的运行级里程碑的所有受管理服务转换为 online（联机）状态后处理的。标准 init 脚本放置在/etc/rc?。d 目录中的脚本按照其序列号顺序运行。
里程碑到运行级的映射为：
单用户 (S)
多用户 (2)
使用网络服务的多用户 (3)
此外，通过将每个脚本的一个实例插入到系统信息库中，svc.startd 使得这些传统服务在 SMF 中可见。可以使用标准 SMF 接口（例如 svcs(1)）来访问这些传统实例，并且它们始终显示为 LEGACY-RUN 状态，无法修改，且无法指定为其他服务的依赖项。为了给管理员提供便利，捕获了传统服务的初始启动时间。
svc.startd 用于存储日志文件的目录。
在引导过程的早期阶段，将 /var 挂载为可读写之前，svc.startd 用于存储日志文件的目录。
要启用详细日志记录，请键入以下命令：
# /usr/sbin/svccfg -s system/svc/restarter:default svc:/system/svc/restarter:default> addpg options application svc:/system/svc/restarter:default> setprop options/logging = \ astring: verbose svc:/system/svc/restarter:default> exit
此请求将在 svc.startd 下次重新启动时生效。
有关下列属性的说明，请参见 attributes(7)：
|
svcprop(1)、svcs(1)、setsid(2)、syslog(3C)、libscf(3LIB)、scf_value_create(3SCF)、smf_method_exit(3SCF)、contract(5)、init.d(5)、inittab(5)、process(5)、attributes(7)、smf(7)、smf_method(7)、init(8)、kernel(8)、svc.configd(8)、svcadm(8)、svccfg(8)
当 start 或 refresh 方法请求 $SMF_EXIT_DEGRADED 时，svc.startd 会将服务移至 degraded 状态。服务通过这种方式进入 degraded 状态后，后续的 refresh 方法可以通过以 $SMF_EXIT_OK 或零 (0) 退出来将其转换回 online 状态。
当 stop 方法请求 $SMF_EXIT_DEGRADED 时，svc.startd 也会将服务移至 degraded 状态。服务通过这种方式进入 degraded 状态后，可以通过在该服务上发出恢复操作来重试 stop 方法。有关更多信息，请参见 svcadm(8) 和 smf_restore_instance(3SCF) 手册页。如果服务已禁用，还可以通过再次禁用服务来重试 stop 方法。