【51CTO精选译文】过不了多久，几乎没有一个Linux用户能够摆脱Init Wars的越来越甚的控制，除非他们手动选择退出。近来，systemd带来的技术、情绪和社会方面的问题比其他任何一款软件都要多。这主要逐渐体现在又叫“Init Wars”的激烈讨论中：数月来，Debian开发者当中出现了这番讨论。虽然Debian技术委员会最终决定将systemd纳入到Debian 8“Jessie”，但有人竭力想取代总决议（General Resolution）作出的这个决定，甚至有人声称不利于赞成systemd的开发人员的健康。
这恰恰表明了systemd严重妨碍了处理Linux系统的方式：在很大程度上，这种处理方式自Unix时代起就强加给我们。“一种工具适合某项任务”之类的理论已被新的理论所取代。除了取代sysvinit作为init系统外，systemd深挖系统管理。眼下，你习惯使用的许多命令都可以继续使用，这归功于程序包systemd-sysv提供的兼容层。一旦systemd 214上传到Debian，定于在稳定分支版中随Debian 8“Jessie”一同发布。在此基础上，用户需要充分使用systemd随带的用于管理服务、进程、切换运行级别和查询日志系统的新命令。一个变通办法就是在.bashrc中设置命令别名。
所以，不妨看一下systemd会如何改变你我管理计算机的习惯，以及相关的优缺点。在改用systemd之前，保存旧的sysvinit，以便万一systemd出现故障，仍能够启动，这是良好的安全做法。只要systemd-sysv还没有安装，旧的sysvinit就能发挥作用，只要运行这个命令，就很容易获得sysvinit：
- # cp -av /sbin/init /sbin/init.sysvinit
因而作好了准备，万一出现什么紧急情况，只要将
- init=/sbin/init.sysvinit
附加到内核引导时间参数的末尾。
systemctl的基本用法
systemctl是取代原有“/etc/init.d/foo start/stop”的命令，但它具有的功能要多得多，你可以查阅参考手册页。
一些基本用法如下：
•systemctl – 列出所有已加载的单元及其状态（单元是任务/服务的术语）
•systemctl list-units – 列出所有单元
•systemctl start [NAME...] –启动（激活）一个或多个单元
•systemctl stop [NAME...] – 停止（停用）一个或多个单元
•systemctl disable [NAME...] – 禁用一个或多个单元文件
•systemctl list-unit-files – 显示所有已安装的单元文件及其状态
•systemctl --failed – 显示启动过程中哪些单元出现故障
•systemctl --type=mount – 类型过滤器；类型可能是：服务、挂载点、设备、套接字和启动目标
•systemctl enable debug-shell.service – 启动TTY 9上的根外壳，用于调试
如果想更方便地处理单元，还有程序包systemd-ui，它可以由用户用systemadm命令来启动。
切换运行级别、重启和关闭也由systemctl来处理：
•systemctl isolate graphical.target – 切换到运行级别5，X服务器在运行级别5运行
•systemctl isolate multi-user.target – 切换到运行级别3和TTY，不带X图形界面
•systemctl reboot – 关闭和重启系统
•systemctl poweroff – 关闭系统
除了用于切换运行级别的命令外，所有这些命令都可以由普通用户来执行。
journalctl的基本用法
systemd不仅启动机器的速度比原来的init系统要快，启动日志功能的速度也要快得多，包括来自内核初始化阶段、初始内存磁盘、早期启动逻辑和主系统运行时的消息。所以，这种日子基本上一去不复返了：你需要使用摄像头，提供内核错误或出现其他故障的系统的输出，以便用于调试。
就systemd而言，日志聚集在系统日志（journal）中，系统日志位于/var/log/。为了能够充分利用系统日志，我们需要先设置系统日志，因为Debian之前没有为你设置好它：
- # addgroup --system systemd-journal
- # mkdir -p /var/log/journal
- # chown root:systemd-journal /var/log/journal
- # gpasswd -a $user systemd-journal
这会设置好系统日志，那样你可以作为普通用户来查询它。使用journalctl查询系统日志比syslog的工作方式更具有一些优势：
•journalctl --all – 显示系统的完整日志及其所有用户
•journalctl -f – 显示系统日志的实时视图（相当于“tail -f /var/log/messages”）
•journalctl -b – 显示上一次启动以来的日志
•journalctl -k -b -1 – 显示来自上一次启动前（-b -1）的所有内核日志
•journalctl -b -p err – 显示上一次启动的日志，仅限于优先级“ERROR”
•journalctl --since=yesterday – 由于Linux用户通常不经常重启，这比-b更加限制了大小
•journalctl -u cron.service --since='2014-07-06 07:00' --until='2014-07-06 08:23' – 显示了计划任务（cron）在指定时间段的日志
•journalctl -p 2 --since=today – 显示优先级2的日志，这包括emerg（***的紧急程度状态）、alert（紧急状态）和crit（重要信息）；酷似syslog优先级emerg（0）、alert（1）、crit（2）、err（3）、warning（4）、notice（5）、info（6）和debug（7）。
•journalctl > yourlog.log – 将二进制格式的系统日志作为文本拷贝到你的当前目录
系统日志和syslog可以一块使用。另一方面，一旦你对系统日志的工作方式感到满意，可以清除任何syslog程序包，比如rsyslog或syslog-ng。
想获得非常详细的输出，将“systemd.log_level=debug”添加到内核引导时间参数列表的末尾，然后运行这个命令：
- # journalctl -alb
日志级别也可以在/etc/systemd/system.conf中加以编辑
使用systemd分析引导过程
Systemd让你可以高效地分析和优化引导过程：
•systemd-analyze – 显示内核和用户空间上一次引导花了多长时间
•systemd-analyze blame – 显示每个服务启动用了多长时间方面的详细信息
•systemd-analyze critical-chain – 打印对时间要求严格的单元链的树结构
•systemd-analyze dot | dot -Tsvg > systemd.svg – 列出引导过程的矢量图（需要graphviz程序包）
•systemd-analyze plot > bootplot.svg – 生成引导过程的图形化时间图
就一个历史很短、正在大力开发中的项目而言，systemd的说明文档编写相当翔实。首先，有Lennart Poettering 编写的0pointer系列：http://0pointer.de/blog/projects/systemd.html。该系列技术性很强，相当冗长详细，含有大量信息。另一个不错的来源是与发行版无关的Freedesktop信息页面：http://www.freedesktop.org/wiki/Software/systemd/，上面列有数量最多的链接，涉及systemd资源、针对特定发行版的页面、软件缺陷追踪器（bugtracker）和说明文档。瞄一眼：
- # man systemd.index
大致列出了所有的systemd参考手册页。不同发行版的systemd命令结构基本上一样，区别主要出现在封装上。
英文：http://xmodulo.com/2014/07/use-systemd-system-administration-debian.html
