From Fedora Project Wiki
No edit summary
Line 1: Line 1:
{{autolang}}
{{autolang}}


systemd 是Linux下一个与SysV和LSB init scripts兼容的系统和服务管理器。systemd 使用socket和D-Bus来开启服务,提供基于守护进程的按需启动策略,保留了Linux cgroups的进程追踪功能,支持快照和系统状态恢复,维护挂载和自挂载点,实现了各服务间基于从属关系的一个更为精细的逻辑控制,拥有前卫的并行性能。它也可以降级作为sysvinit的一个替代品。更多信息,请参考视频:http://linuxconfau.blip.tv/file/4696791/ 和 http://www.youtube.com/watch?v=TyMLi8QF6sw
systemd 是Linux 下一个与SysV 和LSB 初始化脚本兼容的系统和服务管理器。systemd 使用socket 和D-Bus 来开启服务,提供基于守护进程的按需启动策略,保留了Linux cgroups 的进程追踪功能,支持快照和系统状态恢复,维护挂载和自挂载点,实现了各服务间基于从属关系的一个更为精细的逻辑控制,拥有前卫的并行性能。它也可以降级作为sysvinit 的一个替代品。更多信息,请参考视频:http://linuxconfau.blip.tv/file/4696791/ 和 http://www.youtube.com/watch?v=TyMLi8QF6sw


{{admon/note|对于系统管理员|
{{admon/note|对于系统管理员|
Line 13: Line 13:
==介绍==
==介绍==


systemd 开启和监督整个系统是基于''unit'' 的概念。''unit'' 由一个与配置文件对应的名字和类型组成的(例如: avahi.service ''unit'' 有一个具有相同名字的配置文件,是守护进程Avahi 的一个封装单元)。''unit'' 有以下几种类型:
systemd 开启和监督整个系统是基于''unit'' 的概念。''unit'' 是由一个与配置文件对应的名字和类型组成的(例如: avahi.service ''unit'' 有一个具有相同名字的配置文件,是守护进程Avahi 的一个封装单元)。''unit'' 有以下几种类型:


# <code>service</code> :守护进程的启动、停在、重启和重载是此类''unit'' 最为明显的类型。
# <code>service</code> :守护进程的启动、停止、重启和重载是此类''unit'' 中最为明显的几个类型。
# <code>socket</code> :此类''unit'' 封装系统和互联网中的一个套接口。当下,systemd 支持流式、数据报和连续包的AF_INET、AF_INET6、AF_UNIX 接口。也支持传统的FIFOs 传输模式。每一个套接口''unit'' 都有一个相应的服务''unit'' 。相应的服务在第一个连接进入socket 或FIFO 时就会启动(例如:nscd.socket 在有新连接后便启动nscd.service )。
# <code>socket</code> :此类''unit'' 封装系统和互联网中的一个socket 。当下,systemd 支持流式、数据报和连续包的AF_INET、AF_INET6、AF_UNIX socket 。也支持传统的FIFOs 传输模式。每一个socket ''unit'' 都有一个相应的服务''unit'' 。相应的服务在第一个“连接”进入socket 或FIFO 时就会启动(例如:nscd.socket 在有新连接后便启动nscd.service )。
# <code>device</code> :此类''unit'' 封装一个存在于Linux 设备树中的设备。每一个使用udev 规则标记的设备都将会在systemd 中作为一个设备''unit'' 出现。udev 的属性设置可以作为配置设备''unit'' 依赖关系的配置源。
# <code>device</code> :此类''unit'' 封装一个存在于Linux 设备树中的设备。每一个使用udev 规则标记的设备都将会在systemd 中作为一个设备''unit'' 出现。udev 的属性设置可以作为配置设备''unit'' 依赖关系的配置源。
# <code>mount</code> :此类''unit'' 封装系统结构层次中的一个挂载点。
# <code>mount</code> :此类''unit'' 封装系统结构层次中的一个挂载点。
Line 29: Line 29:


==特性==
==特性==
'''systemd''' 提供以下特性:
* 使用socket 的前卫的并行性能:为了加速整个系统启动和并行启动更多的进程,systemd 在实际启动守护进程之前创建监听socket ,然后传递socket 给守护进程。在系统初始化时,首先为所有守护进程创建socket ,然后再启动所有的守护进程。如果一个服务因为需要另一个服务的支持而没有完全启动,而这个连接可能正在提供服务的队列中排队,那么这个客户端进程在这次请求中就处于阻塞状态。但是只有这一个客户端进程在这一次请求中阻塞。服务间的依赖关系也不再需要通过配置来实现真正的并行启动(因为一次开启了所有的socket ,如果一个服务需要其他的服务,它显然可以连接到相应的socket )。
* D-Bus 激活策略启动服务:通过使用总线激活策略,服务可以在接入时马上启动。同时,总线激活策略使得系统可以用微小的消耗实现D-Bus 服务的提供者与消费者的同步开启请求。(同时开启多个服务,如果一个比总线激活策略中其他服务快就在D-Bus 中排队其请求,直到其他管理确定自己的服务信息为止)
* 提供守护进程的按需启动策略
* 保留了使用Linux [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups] 进程的追踪功能:每一个执行了的进程获得它自己的一个cgroup ,配置sysytemd 使其可以存放在cgroup 中已经经过外部配置的服务非常简单。(如使用libcgroups utilities )
* supports snapshotting and restoring of the system state: Snapshots can be used to save/rollback the state of all services and units of the init system. Primarily it has two intended use cases: to allow the user to temporarily enter a specific state such as "Emergency Shell", terminating current services, and provide an easy way to return to the state before, pulling up all services again that got temporarily pulled down.
 
* maintains mount and automount points: Systemd monitors all mount points how they come and go, and can also be used to mount or unmount mount-points. /etc/fstab can be used here as an additional configuration source for these mount points. Using the <code>comment=</code> fstab option you can even mark <code>/etc/fstab</code> entries to become systemd controlled automount points..
* implements an elaborate transactional dependency-based service control logic: Systemd supports several kinds of dependencies between services (or units), using ''After''/''Before'', ''Requires'' and ''Wants'' options in the unit configuration files to fix the ordering how units are activated. ''Requires'' and ''Wants'', express a positive requirement dependency, either mandatory, or optional. There is ''Conflicts'' which expresses a negative requirement dependency, and others less used. As a transactional control, if a unit is requested to start up or shut down, systemd will add it and all its dependencies to a temporary transaction, verifing if the transaction is consistent (or the ordering via After/Before of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop.
and:
* For each process spawned, it controls: The environment, resource limits, working and root directory, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, supplementary group ids, readable/writable/inaccessible directories, shared/private/slave mount flags, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, cgroup control for various subsystems. Also, you can easily connect <code>stdin/stdout/stderr</code> of services to <code>syslog</code>, <code>/dev/kmsg</code>, arbitrary TTYs. If connected to a TTY for input systemd will make sure a process gets exclusive access, optionally waiting or enforcing it.
* The native configuration files use a syntax that closely follows the well-known <code>.desktop</code> files: It is a simple syntax for which parsers exist already in many software frameworks. Also, this allows to rely on existing tools for i18n for service descriptions, and similar, without for admins the need to learn a new syntax.
{{admon/note|systemadm |
There's a minimal UI, <code>systemadm</code> that allows to start/stop/introspect services.  It is part of the systemd-gtk package It's a work in progress and is not functional yet, but useful as a debugging tool. It's written in Vala.  Do not use it for now unless you are a developer}}
(... and more advanced)
* Compatibility with SysV init scripts: It takes advantages of LSB and Red Hat chkconfig headers if they are available, if not, it uses otherwise available information, such as the start priorities in /etc/rc.d. These init scripts are simply considered a different source of configuration, easing the upgrade path to proper systemd services.
* /etc/fstab configuration file: it just another source of configuration. Using the comment= fstab option it is possible to mark /etc/fstab entries to become systemd controlled automount points.
* Support a simple templating/instance mechanism: For example, instead of having six configuration files for six gettys, it has only one getty@.service file which gets instantiated to getty@tty2.service and suchlike. The interface part can even be inherited by dependency expressions, i.e. it is easy to encode that a service dhcpcd@eth0.service pulls in avahi-autoipd@eth0.service, while leaving the eth0 string wild-carded.
* Compatibility, to a certain extent, with <code>/dev/initctl</code>. This compatibility is in fact implemented with a FIFO-activated service, which simply translates these legacy requests to D-Bus requests. Effectively this means the old shutdown, poweroff and similar commands from Upstart and sysvinit continue to work with systemd.
* Compatibility with <code>utmp</code> and <code>wtmp</code> (To an extent that is far more than healthy, given how crufty <code>utmp</code> and <code>wtmp</code> today are).
For all details view [http://0pointer.de/blog/projects/systemd.html A short list of other features] on the developer blog.
==工具==
==工具==


* <code>systemctl</code> :用作内省和控制systemd 系统和服务管理器的状态
* <code>systemctl</code> :用作内省和控制systemd 系统和服务管理器的状态。
* <code>systemd-cgls</code>:以树形递归显示选中的Linux 控制组结构层次
* <code>systemd-cgls</code>:以树形递归显示选中的Linux 控制组结构层次。
* <code>systemadm</code>:一个systemd 系统和服务管理器的图形化前端。是systemd-gtk 工作的一部分。这还只是前期版本,尚需完善。除非你是一个开发者,否则不要使用它。
* <code>systemadm</code>:一个systemd 系统和服务管理器的图形化前端。是systemd-gtk 工作的一部分。这还只是前期版本,尚需完善。除非你是一个开发者,否则不要使用它。


Line 39: Line 81:
==内核启动命令行==
==内核启动命令行==


在系统启动时'''systemd''' 默认激活''default.target'' ,它的工作就是按照依赖关系激活服务和调用其他''unit'' 。
在系统启动时'''systemd''' 默认激活''default.target'' ,它的工作就是按照依赖关系来激活服务和调用其他''unit'' 。


为了重载需要激活的''unit'' ,'''systemd''' 通过<code>systemd.unit=</code> 命令行选项解析其自己的kernel 命令行参数。这可以用来临时启动系统到一个不同的启动''unit'' 。传统的yun-levels 被下面的取代:
为了重载需要激活的''unit'' ,'''systemd''' 通过<code>systemd.unit=</code> 命令行选项解析其自己的kernel 命令行参数。这可以用来临时启动系统到一个不同的启动''unit'' 。传统的yun-levels 被下面的取代:


<code>systemd.unit=rescue.target</code> 是一个设置基本系统和救援shell 的特殊的target ''unit'' (与运行级1相似);<code>systemd.unit=emergency.target</code> 与传递保留参数的<code>init=/bin/sh</code> 给系统使系统从该状态启动相似;<code>systemd.unit=multi-user.target</code> 设置一个非图形化的多用户系统;<code>systemd.unit=graphical.target</code> 设置一个图形化的登录界面。
<code>systemd.unit=rescue.target</code> 是一个设置基本系统和救援shell 的特殊target ''unit'' (与运行级1相似);<code>systemd.unit=emergency.target</code> 与传递保留参数的<code>init=/bin/sh</code> 给系统使系统从该状态启动相似;<code>systemd.unit=multi-user.target</code> 设置一个非图形化的多用户系统;<code>systemd.unit=graphical.target</code> 设置一个图形化的登录界面。


关于特殊的systemd 启动''unit'' 的详细内容,请参看<code>systemd.special</code> 手册页。
关于特殊的systemd 启动''unit'' 的详细内容,请参看<code>systemd.special</code> 手册页。


==Fedora 中systemd 的开发状态==
==Fedora 中systemd 的开发状态==
在Fedora 14的特性中,systemd 是作为一个技术预览。在Fedora 15中替代Upstart 作为默认管理器。
在Fedora 14的特性中,systemd 是作为一个技术预览。在Fedora 15中替代Upstart 作为默认管理器。


==System V init 与systemd 的对接==
==System V init 与systemd 的对接==


大量(但不是全部)核心服务(<code>/lib/systemd/system 中有的,可以通过http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability</code> 检查它们的状态)已经转换到了systemd 中。预计在Fedora 16时完成所有转换工作。详情请参考
大量(但不是全部)核心服务(在<code>/lib/systemd/system</code> 中有的,可以通过http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability 检查它们的状态)已经转换到了systemd 中。预计在Fedora 16 时完成所有转换工作。详情请参考
http://fedoraproject.org/wiki/Features/SysVtoSystemd 。systemd 完全兼容原始系统的初始化脚本。
http://fedoraproject.org/wiki/Features/SysVtoSystemd 。systemd 完全兼容原始系统的初始化脚本。


==systemd 的服务管理程序==
==systemd 的服务管理程序==


<code>systemctl</code> 是最主要的工具。它结合<code>service</code> 和<code>chkconfig</code> 于一体。你可以使用它永久性或只在当前阶段开启/禁用服务。
<code>systemctl</code> 是最主要的工具。它结合<code>service</code> 和<code>chkconfig</code> 于一体。你可以使用它永久性或只在当前阶段开启/禁用服务。
Line 64: Line 106:
<pre> systemctl </pre>   
<pre> systemctl </pre>   


更多详细信息请参考手册页。<code>systemd-cgls</code> 以树形列出正在运行的进程。它可以递归显示给定控制组内容。详情参阅<code>systemd-sgls</code> 手册页。
更多详细信息请参考手册页。<code>systemd-cgls</code> 以树形列出正在运行的进程。它可以递归显示给定控制组内容。详情请参阅<code>systemd-sgls</code> 手册页。


==如何启动/关闭、开启/禁用服务?==
==如何启动/关闭、开启/禁用服务?==
Line 98: Line 140:
0 表示已开机启用,1 表示没有开机启用。
0 表示已开机启用,1 表示没有开机启用。


更多详情请参考<code>systemctl</code> 手册。
更多详情请参看<code>systemctl</code> 手册。


==如何改变运行级别?==
==如何改变运行级别?==
Line 144: Line 186:
</pre>
</pre>


更多的可能有: <code>halt -p</code>、 <code>init 0</code>、 <code>shutdown -P now</code>
更多可行的命令是: <code>halt -p</code>、 <code>init 0</code>、 <code>shutdown -P now</code>


需要注意到在之前的Fedora 发布版中<code>halt</code> 与<code>poweroff</code> 的效果一样。但是systemd 对区别这两项,因而,没有参数的<code>halt</code> 做的就是像它说的那样(停止)——仅仅停止系统而不关机。
需要注意的是,在之前的Fedora 发布版中<code>halt</code> 与<code>poweroff</code> 的效果一样。但是systemd 区别对待这两项,因而,没有参数的<code>halt</code> 做的就是像它说的那样(停止)——仅仅停止系统而不关机。


==<code>service</code> 命令兼容systemd 吗?==
==<code>service</code> 命令兼容systemd 吗?==


是的。<code>service</code> 经过修改可以在处理systemd 服务时调用<code>systemctl</code> 实现。因而下面的命令做的事情相同
是的。<code>service</code> 经过修改可以在处理systemd 服务时调用<code>systemctl</code> 实现。因而下面的命令所做的事情相同


<pre> service NetworkManager stop </pre>
<pre> service NetworkManager stop </pre>
Line 170: Line 212:
<pre> systemctl disable NetworkManager.service </pre>
<pre> systemctl disable NetworkManager.service </pre>


<code>chkconfig --list</code> 不会列出systemd 服务,只列出Sys V 服务。<code>chkconfig</code> 的输出结果里添加了对此的说明信息。
<code>chkconfig --list</code> 不会列出systemd 服务,只列出Sys V 服务。<code>chkconfig</code> 的输出结果里附带了对此的说明信息。


==<code>system-config-services</code> 与systemd 兼容吗?==
==<code>system-config-services</code> 与systemd 兼容吗?==
Line 231: Line 273:


==如何定制或增加一个自定义''unit'' 文件?==
==如何定制或增加一个自定义''unit'' 文件?==
''unit''文件在<code>/etc/systemd/system</code>下的优先级要高于<code>/lib/systemd/system</code>下的。按照个人的需求从后者移动到前者并进行自定义修改。
 
''unit'' 文件在<code>/etc/systemd/system</code> 下的优先级要高于<code>/lib/systemd/system</code> 下的。按照个人的需求从后者移动到前者并进行自定义修改。


如果一行以<code>.include</code> 开始,后接文件名,那么该文件在此时被解析为特殊文件。请确保包含的文件在指令前有适当的章节头信息。
如果一行以<code>.include</code> 开始,后接文件名,那么该文件在此时被解析为特殊文件。请确保包含的文件在指令前有适当的章节头信息。
Line 237: Line 280:
如果可能的话,你应当使用<code>.include</code> 声明''unit'' 文件而不是在<code>/lib/systemd/system</code> 下复制整个''unit'' 文件到<code>/etc/systemd/system</code> 目录下。这样你才可以在将来升级软件包时正确地升级未改变的指令。
如果可能的话,你应当使用<code>.include</code> 声明''unit'' 文件而不是在<code>/lib/systemd/system</code> 下复制整个''unit'' 文件到<code>/etc/systemd/system</code> 目录下。这样你才可以在将来升级软件包时正确地升级未改变的指令。


在使用<code>.include</code> 和指令时需要小心,因为它可以有多次定义(像<code>EnvironmentFile=</code> 一样)。由于我们只能添加新指令而不能删除已经定义的指令。此时,我们就必须从<code>/lib/systemd/system</code> 复制整个文件到<code>/etc/systemd/system</code> 中去。
在使用<code>.include</code> 和指令时需要小心,因为它可以有多次定义(像<code>EnvironmentFile=</code> 一样)。由于我们只能添加新指令而不能删除已定义的指令,此时,我们就必须从<code>/lib/systemd/system</code> 复制整个文件到<code>/etc/systemd/system</code> 中去。


假设我们有一个lighttpd 服务,我们现在想降低它的niceness 值。我们需要做的只是添加<code>Nice=-5</code> 到lighttpd.service 文件中。我们可以通过复制整个文件<code>/lib/systemd/system/lighttpd.service</code> 到<code>/etc/systemd/system/lighttpd.service</code> 或者在<code>/etc/systemd/system/lighttpd.service</code> 中创建如下文件做到
假设我们有一个lighttpd 服务,我们现在想降低它的niceness 值。我们需要做的就只是添加<code>Nice=-5</code> 到lighttpd.service 文件中。我们可以通过复制整个文件<code>/lib/systemd/system/lighttpd.service</code> 到<code>/etc/systemd/system/lighttpd.service</code> 或者在<code>/etc/systemd/system/lighttpd.service</code> 中创建如下文件做到


<pre>
<pre>
Line 249: Line 292:
不要忘记在编辑一个''unit'' 文件后使用<code>systemdctl daemon-reload</code> 重载systemd 守护进程。
不要忘记在编辑一个''unit'' 文件后使用<code>systemdctl daemon-reload</code> 重载systemd 守护进程。


 
{{admon/note|当修改一个拥有指向它的链接的''unit'' 时,例如:<code>display-manager.service -> prefdm.service</code> ,需要复制链接而不是实际的''unit'' ,例中即复制<code>display-manager.service</code> 到<code>/etc/systemd/system</code> 目录下,或者是用<code>.include</code> 新建一个相应名字的''unit'' 。
{{admon/note|当修改一个拥有指向它的链接的''unit'' 时,例如:<code>display-manager.service -> prefdm.service</code> ,需要复制链接而不是实际的''unit'' ,例中即复制<code>display-manager.service</code> 到<code>/etc/systemd/system</code> 目录下,或者是用<code>.include</code> 新建一个相应名字的''unit'' 。}}
}}


==如何调试系统事件?==
==如何调试系统事件?==


参考 [[How_to_debug_Systemd_problems]]
参看 [[How_to_debug_Systemd_problems]]


==预读功能==
==预读功能==
Line 272: Line 315:
http://cgit.freedesktop.org/systemd/tree/README
http://cgit.freedesktop.org/systemd/tree/README


==man 手册==
==<code>man</code> 手册==
systemd 有多方面的文档,其中也包括一些man手册页。其网页版地址是:
 
systemd 有丰富的文档,其中也包括一些<code>man</code> 手册页。其网页版地址是:
http://0pointer.de/public/systemd-man/
http://0pointer.de/public/systemd-man/



Revision as of 06:19, 17 March 2012

systemd 是Linux 下一个与SysV 和LSB 初始化脚本兼容的系统和服务管理器。systemd 使用socket 和D-Bus 来开启服务,提供基于守护进程的按需启动策略,保留了Linux cgroups 的进程追踪功能,支持快照和系统状态恢复,维护挂载和自挂载点,实现了各服务间基于从属关系的一个更为精细的逻辑控制,拥有前卫的并行性能。它也可以降级作为sysvinit 的一个替代品。更多信息,请参考视频:http://linuxconfau.blip.tv/file/4696791/http://www.youtube.com/watch?v=TyMLi8QF6sw

Note.png
对于系统管理员
系统管理员如果想了解如何使用本地命令systemctl 来替换SysVinit 的工作流程,可以访问此页。需要注意的是,在systemd 的世界里servicechkconfig 命令将继续像之前一样工作。


为什么是systemd?

http://0pointer.de/blog/projects/why.html

介绍

systemd 开启和监督整个系统是基于unit 的概念。unit 是由一个与配置文件对应的名字和类型组成的(例如: avahi.service unit 有一个具有相同名字的配置文件,是守护进程Avahi 的一个封装单元)。unit 有以下几种类型:

  1. service :守护进程的启动、停止、重启和重载是此类unit 中最为明显的几个类型。
  2. socket :此类unit 封装系统和互联网中的一个socket 。当下,systemd 支持流式、数据报和连续包的AF_INET、AF_INET6、AF_UNIX socket 。也支持传统的FIFOs 传输模式。每一个socket unit 都有一个相应的服务unit 。相应的服务在第一个“连接”进入socket 或FIFO 时就会启动(例如:nscd.socket 在有新连接后便启动nscd.service )。
  3. device :此类unit 封装一个存在于Linux 设备树中的设备。每一个使用udev 规则标记的设备都将会在systemd 中作为一个设备unit 出现。udev 的属性设置可以作为配置设备unit 依赖关系的配置源。
  4. mount :此类unit 封装系统结构层次中的一个挂载点。
  5. automount :此类unit 封装系统结构层次中的一个自挂载点。每一个自挂载unit 对应一个已挂载的挂载unit (需要在自挂载目录可以存取的情况下尽早挂载)。
  6. target :此类unit 为其他unit 进行逻辑分组。它们本身实际上并不做什么,只是引用其他unit 而已。这样便可以对unit 做一个统一的控制。(例如:multi-user.target 相当于在传统使用SysV 的系统中运行级别5;bluetooth.target 只有在蓝牙适配器可用的情况下才调用与蓝牙相关的服务,如:bluetooth 守护进程、obex 守护进程等)
  7. snapshot :与target unit 相似,快照本身不做什么,唯一的目的就是引用其他unit

文档

systemd 拥有丰富的文档。参考 http://0pointer.de/blog/projects/systemd-docs.html

特性

systemd 提供以下特性:

  • 使用socket 的前卫的并行性能:为了加速整个系统启动和并行启动更多的进程,systemd 在实际启动守护进程之前创建监听socket ,然后传递socket 给守护进程。在系统初始化时,首先为所有守护进程创建socket ,然后再启动所有的守护进程。如果一个服务因为需要另一个服务的支持而没有完全启动,而这个连接可能正在提供服务的队列中排队,那么这个客户端进程在这次请求中就处于阻塞状态。但是只有这一个客户端进程在这一次请求中阻塞。服务间的依赖关系也不再需要通过配置来实现真正的并行启动(因为一次开启了所有的socket ,如果一个服务需要其他的服务,它显然可以连接到相应的socket )。
  • D-Bus 激活策略启动服务:通过使用总线激活策略,服务可以在接入时马上启动。同时,总线激活策略使得系统可以用微小的消耗实现D-Bus 服务的提供者与消费者的同步开启请求。(同时开启多个服务,如果一个比总线激活策略中其他服务快就在D-Bus 中排队其请求,直到其他管理确定自己的服务信息为止)
  • 提供守护进程的按需启动策略
  • 保留了使用Linux cgroups 进程的追踪功能:每一个执行了的进程获得它自己的一个cgroup ,配置sysytemd 使其可以存放在cgroup 中已经经过外部配置的服务非常简单。(如使用libcgroups utilities )
  • supports snapshotting and restoring of the system state: Snapshots can be used to save/rollback the state of all services and units of the init system. Primarily it has two intended use cases: to allow the user to temporarily enter a specific state such as "Emergency Shell", terminating current services, and provide an easy way to return to the state before, pulling up all services again that got temporarily pulled down.
  • maintains mount and automount points: Systemd monitors all mount points how they come and go, and can also be used to mount or unmount mount-points. /etc/fstab can be used here as an additional configuration source for these mount points. Using the comment= fstab option you can even mark /etc/fstab entries to become systemd controlled automount points..
  • implements an elaborate transactional dependency-based service control logic: Systemd supports several kinds of dependencies between services (or units), using After/Before, Requires and Wants options in the unit configuration files to fix the ordering how units are activated. Requires and Wants, express a positive requirement dependency, either mandatory, or optional. There is Conflicts which expresses a negative requirement dependency, and others less used. As a transactional control, if a unit is requested to start up or shut down, systemd will add it and all its dependencies to a temporary transaction, verifing if the transaction is consistent (or the ordering via After/Before of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop.

and:

  • For each process spawned, it controls: The environment, resource limits, working and root directory, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, supplementary group ids, readable/writable/inaccessible directories, shared/private/slave mount flags, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, cgroup control for various subsystems. Also, you can easily connect stdin/stdout/stderr of services to syslog, /dev/kmsg, arbitrary TTYs. If connected to a TTY for input systemd will make sure a process gets exclusive access, optionally waiting or enforcing it.
  • The native configuration files use a syntax that closely follows the well-known .desktop files: It is a simple syntax for which parsers exist already in many software frameworks. Also, this allows to rely on existing tools for i18n for service descriptions, and similar, without for admins the need to learn a new syntax.
Note.png
systemadm
There's a minimal UI, systemadm that allows to start/stop/introspect services. It is part of the systemd-gtk package It's a work in progress and is not functional yet, but useful as a debugging tool. It's written in Vala. Do not use it for now unless you are a developer

(... and more advanced)

  • Compatibility with SysV init scripts: It takes advantages of LSB and Red Hat chkconfig headers if they are available, if not, it uses otherwise available information, such as the start priorities in /etc/rc.d. These init scripts are simply considered a different source of configuration, easing the upgrade path to proper systemd services.
  • /etc/fstab configuration file: it just another source of configuration. Using the comment= fstab option it is possible to mark /etc/fstab entries to become systemd controlled automount points.
  • Support a simple templating/instance mechanism: For example, instead of having six configuration files for six gettys, it has only one getty@.service file which gets instantiated to getty@tty2.service and suchlike. The interface part can even be inherited by dependency expressions, i.e. it is easy to encode that a service dhcpcd@eth0.service pulls in avahi-autoipd@eth0.service, while leaving the eth0 string wild-carded.
  • Compatibility, to a certain extent, with /dev/initctl. This compatibility is in fact implemented with a FIFO-activated service, which simply translates these legacy requests to D-Bus requests. Effectively this means the old shutdown, poweroff and similar commands from Upstart and sysvinit continue to work with systemd.
  • Compatibility with utmp and wtmp (To an extent that is far more than healthy, given how crufty utmp and wtmp today are).

For all details view A short list of other features on the developer blog.


工具

  • systemctl :用作内省和控制systemd 系统和服务管理器的状态。
  • systemd-cgls:以树形递归显示选中的Linux 控制组结构层次。
  • systemadm:一个systemd 系统和服务管理器的图形化前端。是systemd-gtk 工作的一部分。这还只是前期版本,尚需完善。除非你是一个开发者,否则不要使用它。

更多详细内容请参看手册页。

内核启动命令行

在系统启动时systemd 默认激活default.target ,它的工作就是按照依赖关系来激活服务和调用其他unit

为了重载需要激活的unitsystemd 通过systemd.unit= 命令行选项解析其自己的kernel 命令行参数。这可以用来临时启动系统到一个不同的启动unit 。传统的yun-levels 被下面的取代:

systemd.unit=rescue.target 是一个设置基本系统和救援shell 的特殊target unit (与运行级1相似);systemd.unit=emergency.target 与传递保留参数的init=/bin/sh 给系统使系统从该状态启动相似;systemd.unit=multi-user.target 设置一个非图形化的多用户系统;systemd.unit=graphical.target 设置一个图形化的登录界面。

关于特殊的systemd 启动unit 的详细内容,请参看systemd.special 手册页。

Fedora 中systemd 的开发状态

在Fedora 14的特性中,systemd 是作为一个技术预览。在Fedora 15中替代Upstart 作为默认管理器。

System V init 与systemd 的对接

大量(但不是全部)核心服务(在/lib/systemd/system 中有的,可以通过http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability 检查它们的状态)已经转换到了systemd 中。预计在Fedora 16 时完成所有转换工作。详情请参考 http://fedoraproject.org/wiki/Features/SysVtoSystemd 。systemd 完全兼容原始系统的初始化脚本。

systemd 的服务管理程序

systemctl 是最主要的工具。它结合servicechkconfig 于一体。你可以使用它永久性或只在当前阶段开启/禁用服务。

列出正在运行的服务或其他:

 systemctl 

更多详细信息请参考手册页。systemd-cgls 以树形列出正在运行的进程。它可以递归显示给定控制组内容。详情请参阅systemd-sgls 手册页。

如何启动/关闭、开启/禁用服务?

运行一个服务:

  systemctl start foo.service 

关闭一个服务:

  systemctl stop foo.service 

重启一个服务:

 systemctl restart foo.service 

显示一个服务(无论运行与否)的状态:

 systemctl status foo.service 

在开机时启用一个服务:

 systemctl enable foo.service 

在开机时禁用一个服务:

 systemctl disable foo.service 

检查一个是否已开机启用:

 systemctl is-enabled foo.service; echo $? 

0 表示已开机启用,1 表示没有开机启用。

更多详情请参看systemctl 手册。

如何改变运行级别?

systemd 使用比sysvinit 的运行级更为自由的target 概念作为替代。

第3运行级用myti-user.target 替代。第5运行级用graphical.target 替代。runlevel3.target 和runlevel5.target 分别是指向muti-user.target 和graphical.target 的符号链接。

你可以使用下面的命令切换到“运行级3”:

 systemctl isolate multi-user.target (or) systemctl isolate runlevel3.target 

你也可以使用下面的命令切换到“运行级5”:

 systemctl isolate graphical.target (or) systemctl isolate runlevel5.target 

如何改变默认运行级别?

systemd 使用链接来指向默认的运行级别。在创建新的链接前,你可以通过下面命令删除存在的链接:

 rm /etc/systemd/system/default.target 

默认切换到运行级3:

 ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target 

默认切换到运行级5:

 ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target 

systemd 不使用/etc/inittab 文件。

如何查看当下运行级别?

runlevel 命令在systemd 下仍然可以工作。你可以继续使用它,尽管systemd 使用'target' 概念(多个的'target' 可以同时激活)替换了之前系统的runlevel 。等价的systemd 命令是

 systemctl list-units --type=target 

如何关机?

你可以使用

poweroff

更多可行的命令是: halt -pinit 0shutdown -P now

需要注意的是,在之前的Fedora 发布版中haltpoweroff 的效果一样。但是systemd 区别对待这两项,因而,没有参数的halt 做的就是像它说的那样(停止)——仅仅停止系统而不关机。

service 命令兼容systemd 吗?

是的。service 经过修改可以在处理systemd 服务时调用systemctl 实现。因而下面的命令所做的事情相同

 service NetworkManager stop 

(or)

 systemctl stop NetworkManager.service 

chkconfig 命令兼容systemd 吗?

是的,如果是开启/关闭服务,兼容性保证两种方式都可以运行。不过chkconfig 经过修改使得在处理systemd 服务时调用systemctl 工具。同样,在处理传统sysv 初始化文件时systemd 自动调用chkconfig

因此,下面的命令做的事情是一样的

 chkconfig NetworkManager off 

(or)

 systemctl disable NetworkManager.service 

chkconfig --list 不会列出systemd 服务,只列出Sys V 服务。chkconfig 的输出结果里附带了对此的说明信息。

system-config-services 与systemd 兼容吗?

Feodra 15的system-config-services 版本也可以处理systemd 的服务文件。如果你遇到问题,直接报告一个bug 。

如何改变默认gettys 数目?

添加一个新的getty :

只需要在getty.target.wants/ 目录下新建一个链接到getty 的示例即可:

ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
systemctl daemon-reload
systemctl start getty@tty9.service

删除一个getty :

直接删掉getty.target.wants/ 目录下你不想要的哪个getty 链接即可:

rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service
systemctl daemon-reload
systemctl stop getty@tty5.service getty@tty6.service

systemd 不使用/etc/inittab 文件。

虚拟终端如何设置自动登录?

首先创建一个新的类似与getty@.service 的服务:

# cp /lib/systemd/system/getty@.service \
     /etc/systemd/system/autologin@.service
# ln -s /etc/systemd/system/autologin@.service \
        /etc/systemd/system/getty.target.wants/getty@tty8.service

然后编辑ExecStart、Restart 和Alias 的值,如:

...
ExecStart=-/sbin/mingetty --autologin USERNAME %I
Restart=no
...
Alias=getty.target.wants/getty@tty8.service

最后重新加载守护进程,运行服务:

systemctl daemon-reload
systemctl start getty@tty8.service

需要注意的是,如果你退出了tty8 的会话,你需要等到下次重新启动才能使用,除非你给Restart 的值是'always' ,这样你可以使用systemctl 手动开启(但是出于安全考虑,强烈建议你不要那么做)。

如何定制或增加一个自定义unit 文件?

unit 文件在/etc/systemd/system 下的优先级要高于/lib/systemd/system 下的。按照个人的需求从后者移动到前者并进行自定义修改。

如果一行以.include 开始,后接文件名,那么该文件在此时被解析为特殊文件。请确保包含的文件在指令前有适当的章节头信息。

如果可能的话,你应当使用.include 声明unit 文件而不是在/lib/systemd/system 下复制整个unit 文件到/etc/systemd/system 目录下。这样你才可以在将来升级软件包时正确地升级未改变的指令。

在使用.include 和指令时需要小心,因为它可以有多次定义(像EnvironmentFile= 一样)。由于我们只能添加新指令而不能删除已定义的指令,此时,我们就必须从/lib/systemd/system 复制整个文件到/etc/systemd/system 中去。

假设我们有一个lighttpd 服务,我们现在想降低它的niceness 值。我们需要做的就只是添加Nice=-5 到lighttpd.service 文件中。我们可以通过复制整个文件/lib/systemd/system/lighttpd.service/etc/systemd/system/lighttpd.service 或者在/etc/systemd/system/lighttpd.service 中创建如下文件做到

.include /lib/systemd/system/lighttpd.service 
[Service]
Nice=-5

不要忘记在编辑一个unit 文件后使用systemdctl daemon-reload 重载systemd 守护进程。

Note.png
当修改一个拥有指向它的链接的unit 时,例如:display-manager.service -> prefdm.service ,需要复制链接而不是实际的unit ,例中即复制display-manager.service/etc/systemd/system 目录下,或者是用.include 新建一个相应名字的unit

如何调试系统事件?

参看 How_to_debug_Systemd_problems

预读功能

systemd 有内置的预读功能(默认升级时未启用),它可以提高开机速度,但具体提升幅度视个人硬件而定。 要使用它,使用命令:

systemctl enable systemd-readahead-collect.service
systemctl enable systemd-readahead-replay.service

关于/usr 分区的警告

详情请参考: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-brokenhttp://cgit.freedesktop.org/systemd/tree/README

man 手册

systemd 有丰富的文档,其中也包括一些man 手册页。其网页版地址是: http://0pointer.de/public/systemd-man/

参考