mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-25 00:50:15 +08:00
Merge pull request #3529 from Ricky-Gong/master
【翻译完成】20151117 Linux 101--Get the most out of Systemd.md
This commit is contained in:
ictlyh
commit
0410e9c0ab
@ -1,173 +0,0 @@
|
||||
Ricky-Gong is translating this article.
|
||||
|
||||
Linux 101: Get the most out of Systemd
|
||||
================================================================================
|
||||
Why do this?
|
||||
|
||||
- Understand the big changes in modern distros.
|
||||
- See how Systemd replaces SysVinit.
|
||||
- Get to grips with units and the new journal.
|
||||
|
||||
Hate mail, personal insults, death threats – Lennart Poettering, the author of Systemd, is used to receiving these. The Red Hat employee recently ranted on Google+ about the nature of the FOSS community ([http://tinyurl.com/poorlennart][1]), lamenting that it’s “quite a sick place to be in”. In particular, he points to Linus Torvalds’s highly acerbic mailing list posts, and accuses the kernel head honcho of setting the tone of online discussion, making personal attacks and derogatory comments the norm.
|
||||
|
||||
But why has Poettering received so much hate? Why does a man who simply develops open source software have to tolerate this amount of anger? Well, the answer lies in the importance of his software. Systemd is the first thing launched by the Linux kernel on most distributions now, and it serves many roles. It starts system services, handles logins, executes tasks at specified intervals, and much more. It’s growing all the time, and becoming something of a “base system” for Linux – providing all the plumbing tools needed to boot and maintain a distro.
|
||||
|
||||
Now, Systemd is controversial for various reasons: it eschews some established Unix conventions, such as plain text log files. It’s seen as a “monolithic” project trying to take over everything else. And it’s a major change to the underpinnings of our OS. Yet almost every major distribution has adopted it (or is about to), so it’s here to stay. And there are benefits: faster booting, easier management of services that depend on one another, and powerful and secure logging facilities too.
|
||||
|
||||
So in this tutorial we’ll explore Systemd’s features, and show you how to get the most out of them. Even if you’re not a fan of the software right now, hopefully at least you’ll feel more comfortable with it by the end.
|
||||
|
||||
|
||||
|
||||
**This tongue-in-cheek animation at [http://tinyurl.com/m2e7mv8][2] portrays Systemd as a rabid animal eating everything in its path. Most critics haven’t been so fluffy.**
|
||||
|
||||
### Booting and services ###
|
||||
|
||||
Almost every major distro has either adopted Systemd, or will do so in the next release (Debian and Ubuntu). In this tutorial we’re using a pre-release of Fedora 21 – a distro that has been a great testing ground for Systemd – but the commands and notes should be the same regardless of your distro. That’s one of the plus points of Systemd: it obviates many of the tiny, niggling differences between distros.
|
||||
|
||||
In a terminal, enter **ps ax | grep systemd** and look at the first line. The **1** means that it’s process ID 1, ie the first thing launched by the Linux kernel. So, once the kernel has done its work detecting hardware and organising memory, it launches the **/usr/lib/systemd/systemd** executable, which then launches other programs in turn. (In pre-Systemd days, the kernel would launch **/sbin/init**, which would then launch various other essential boot scripts, in a system known as SysVinit.)
|
||||
|
||||
Central to Systemd is the concept of units. These are configuration files with information about services (programs running in the background), devices, mount points, timers and other aspects of the operating system. One of Systemd’s goals is to ease and simplify the interaction between these, so if you have a certain program that needs to start when a certain mount point is created when a certain device gets plugged in, it should be considerably easier to make all this work. (In pre-Systemd days, hacking all this together with scripts could get very ugly.) To list all units on your Linux installation, enter:
|
||||
|
||||
systemctl list-unit-files
|
||||
|
||||
Now, **systemctl** is the main tool for interacting with Systemd, and it has many options. Here, in the unit list, you’ll notice that there’s some formatting: enabled units are shown in green, and disabled are shown in red. Units marked as “static” can’t be started directly – they’re dependencies of other units. To narrow down the list to just services, use:
|
||||
|
||||
systemctl list-unit-files --type=service
|
||||
|
||||
Note that “enabled” doesn’t necessarily mean that a service is running; just that it can be turned on. To get information about a specific service, for instance GDM (the Gnome Display Manager), enter:
|
||||
|
||||
systemctl status gdm.service
|
||||
|
||||
This provides lots of useful information: a human-readable description of the service, the location of the unit configuration file, when it was started, its PID, and the CGroups to which it belongs (these limit resource consumption for groups of processes).
|
||||
|
||||
If you look at the unit config file in **/usr/lib/systemd/system/gdm.service**, you’ll see various options, including the binary to be started (ExecStart), what it conflicts with (ie which units can’t be active at the same time), and what needs to be started before this unit can be activated (the “After” line). Some units have additional dependency options, such as “Requires” (mandatory dependencies) and “Wants” (optional).
|
||||
|
||||
Another interesting option here is:
|
||||
|
||||
Alias=display-manager.service
|
||||
|
||||
When you activate **gdm.service**, you will also be able to view its status using **systemctl status display-manager.service**. This is useful when you know there’s a display manager running, and you want to do something with it, but you don’t care whether it’s GDM, KDM, XDM or any of the others.
|
||||
|
||||
|
||||
|
||||
**Use systemctl status, followed by a unit name, to see what’s going on with a service.**
|
||||
|
||||
### Target locked ###
|
||||
|
||||
If you enter **ls** in the **/usr/lib/systemd/system** directory, you’ll also see various files that end in **.target**. A target is a way of grouping units together so that they’re started at the same time. For instance, in most Unix-like OSes there’s a state of the system called “multi-user”, which means that the system has booted correctly, background services are running, and it’s ready for one or more users to log in and do their work – at least, in text mode. (Other states include single-user, for doing administration work, or reboot, for when the machine is shutting down.)
|
||||
|
||||
If you look inside **multi-user.target**, you may be expecting to see a list of units that should be active in this state. But you’ll notice that the file is pretty bare – instead, individual services make themselves dependencies of the target via the **WantedBy** option. So if you look inside **avahi-daemon.service**, **NetworkManager.service** and many other **.service** files, you’ll see this line in the Install section:
|
||||
|
||||
WantedBy=multi-user.target
|
||||
|
||||
So, switching to the multi-user target will enable those units that contain the above line. Other targets are available (such as **emergency.target** for an emergency shell, or **halt.target** for when the machine shuts down), and you can easily switch between them like so:
|
||||
|
||||
systemctl isolate emergency.target
|
||||
|
||||
In many ways, these are like SysVinit runlevels, with text-mode **multi-user.target** being runlevel 3, **graphical.target** being runlevel 5, **reboot.target** being runlevel 6, and so forth.
|
||||
|
||||
|
||||
|
||||
**The unit configuration files might look foreign compared to traditional scripts, but they’re not hard to grasp.**
|
||||
|
||||
### Up and down ###
|
||||
|
||||
Now, you might be pondering: we’ve got this far, and yet we haven’t even looked at stopping and starting services yet! But there’s a reason for this. Systemd can look like a complicated beast from the outside, so it’s good to have an overview of how it works before you start interacting with it. The actual commands for managing services are very simple:
|
||||
|
||||
systemctl stop cups.service
|
||||
systemctl start cups.service
|
||||
|
||||
(If a unit has been disabled, you can first enable it with **systemctl enable** followed by the unit name. This places a symbolic link for the unit in the .wants directory of the current target, in the **/etc/systemd/system** folder.)
|
||||
|
||||
Two more useful commands are **systemctl restart** and **systemctl reload**, followed by unit names. The second asks the unit to reload its configuration file. Systemd is – for the most part – very well documented, so look at the manual page (**man systemctl**) for details on every command.
|
||||
|
||||
> ### Timer units: replacing Cron ###
|
||||
>
|
||||
> Beyond system initialisation and service management, Systemd has its fingers in various other pies too. Notably, it can perform the job of **cron**, arguably with more flexibility (and an easier to read syntax). **Cron** is the program that performs jobs at regular intervals – such as cleaning up temporary files, refreshing caches and so forth.
|
||||
>
|
||||
> If you look inside the **/usr/lib/systemd/system** directory again, you’ll see that various **.timer** files are provided. Have a look at some of them with **less**, and you’ll note that they follow a similar structure to the **.service** and **.target** files. The difference, however, lies in the **[Timer]** section. Consider this example:
|
||||
>
|
||||
> [Timer]
|
||||
> OnBootSec=1h
|
||||
> OnUnitActiveSec=1w
|
||||
>
|
||||
> Here, the **OnBootSec** option tells Systemd to activate the unit 1 hour after the system has booted. Then the second option means: activate the unit once a week after that. There’s a huge amount of flexibility in the times that you can set – enter **man systemd.time** for a full list.
|
||||
>
|
||||
> By default, Systemd’s accuracy for timing is one minute. In other words, it will activate the unit within a minute of the time you specify, but not necessarily to the exact second. This is done for power management reasons, but if you need a timer to be executed without any delay, right down to the microsecond, you can add this line:
|
||||
>
|
||||
> AccuracySec=1us
|
||||
>
|
||||
> Also, the **WakeSystem** option (which can be set to true or false) defines whether or not the timer should wake up the machine if it’s in suspend mode.
|
||||
|
||||
|
||||
|
||||
**A Systemd GUI exists,although it hasn’t been actively worked on for a couple of years.**
|
||||
|
||||
### Log files: say hello to journald ###
|
||||
|
||||
The second major component of Systemd is the journal. This is a logging system, similar to syslog, but with some major differences. And if you’re a fan of the Unix way, prepare for your blood to boil: it’s a binary log, so you can’t just parse it using your regular command line text tools. This design decision regularly whips up heated debates on the net, but it has some benefits too. For instance, logs can be more structured, with better metadata, so it’s easier to filter out information based on executable name, PID, time and so forth.
|
||||
|
||||
To view the journal in its entirety, enter:
|
||||
|
||||
journalctl
|
||||
|
||||
As with many other Systemd commands, this pipes the output into the **less** program, so you can scroll down by hitting space, use / (forward slash) to search, and other familiar keybindings. You’ll also notice a sprinkling of colour here too, with warnings and failure messages in red.
|
||||
|
||||
That’s a lot of information; to narrow it down to the current boot, use:
|
||||
|
||||
journalctl -b
|
||||
|
||||
And here’s where the Systemd journal starts to shine. Do you want to see all messages from the previous boot? Try **journalctl -b -1**. Or the one before that? Replace **-1** with **-2**. How about something very specific, like all messages from 24 October 2014, 16:38 onwards?”
|
||||
|
||||
journalctl -b --since=”2014-10-24 16:38”
|
||||
|
||||
Even if you deplore binary logs, that’s still a useful feature, and for many admins it’s much easier than constructing a similar filter from regular expressions.
|
||||
|
||||
So we’ve narrowed down the log to specific times, but what about specific programs? For units, try this:
|
||||
|
||||
journalctl -u gdm.service
|
||||
|
||||
(Note: that’s a good way to see the log generated by the X server.) Or how about a specific PID?
|
||||
|
||||
journalctl _PID=890
|
||||
|
||||
You can even request to just see messages from a certain executable:
|
||||
|
||||
journalctl /usr/bin/pulseaudio
|
||||
|
||||
If you want to narrow down to messages of a certain priority, use the **-p** option. With 0 this will only show emergency messages (ie it’s time to start praying to **$DEITY**), whereas 7 will show absolutely everything, including debugging messages. See the manual page (**man journalctl**) for more details on the priority levels.
|
||||
|
||||
It’s worth noting that you can combine options as well, so to only show messages from the GDM service of priority level 3 (or lower) from the current boot, use:
|
||||
|
||||
journalctl -u gdm.service -p 3 -b
|
||||
|
||||
Finally, if you just want to have a terminal window open, constantly updating with the latest journal entries, as you’d have with the tail command in pre-Systemd installations, just enter **journalctl -f**.
|
||||
|
||||
|
||||
|
||||
**Binary logging isn’t popular, but the journal has some benefits, like very easy filtering of information.**
|
||||
|
||||
> ### Life without Systemd? ###
|
||||
>
|
||||
> If you simply, absolutely can’t get on with Systemd, you still have a few choices among the major distributions. Most notably, Slackware, the longest-running distro, hasn’t made the switch yet – but its lead developer hasn’t ruled it out for the future. A few small-name distros are also holding out with SysVinit as well.
|
||||
>
|
||||
> But how long will this last? Gnome is becoming increasingly dependent on Systemd, and the other major desktop environments could follow suit. This is a cause of consternation in the BSD communities, as Systemd is heavily tied to Linux kernel features, so the desktops are becoming less portable, in a way. A half-way-house solution might arrive in the form of Uselessd ([http://uselessd.darknedgy.net][3]), which is a stripped-down version of Systemd that purely focuses on launching and supervising processes, without consuming the whole base system.
|
||||
>
|
||||
> 
|
||||
>
|
||||
> If you don’t like Sysytemd, try Gentoo, which has it as a choice of init system, but doesn’t force it on its users.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxvoice.com/linux-101-get-the-most-out-of-systemd/
|
||||
|
||||
作者：[Mike Saunders][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.linuxvoice.com/author/mike/
|
||||
[1]:http://tinyurl.com/poorlennart
|
||||
[2]:http://tinyurl.com/m2e7mv8
|
||||
[3]:http://uselessd.darknedgy.net/
|
||||
@ -0,0 +1,171 @@
|
||||
Linux 101：最有效地使用 Systemd
|
||||
================================================================================
|
||||
干嘛要这么做？
|
||||
|
||||
- 理解现代 Linux 发行版中的显著变化；
|
||||
- 看看 Systemd 是如何取代 SysVinit 的；
|
||||
- 处理好*单元* (unit)和新的 journal 日志。
|
||||
|
||||
吐槽邮件，人身攻击，死亡威胁——Lennart Poettering，Systemd 的作者，对收到这些东西早就习以为常了。这位 Red Hat 公司的员工最近在 Google+ 上怒斥 FOSS 社区([http://tinyurl.com/poorlennart][1])的本质，悲痛且失望地表示：“那真是个令人恶心的地方”。他着重指出 Linus Torvalds 在邮件列表上言辞刻薄的帖子，并谴责这位内核的领导者为在线讨论定下基调，并使得人身攻击及贬抑之辞成为常态。
|
||||
|
||||
但为何 Poettering 会遭受如此多的憎恨？为何就这么个搞搞开源软件的人要忍受这等愤怒？答案就在于他的软件的重要性。如今大多数发行版中，Systemd 是 Linux 内核发起的第一个程序，并且它还扮演多种角色。它会启动系统服务，处理用户登陆，每隔特定的时间执行一些任务，还有很多很多。它在不断地成长，并逐渐成为 Linux 的某种“基础系统”——提供系统启动和发行版维护所需的所有工具。
|
||||
|
||||
如今，在以下几点上 Systemd 颇具争议：它逃避了一些确立好的 Unix 传统，例如纯文本的日志文件；它被看成是个“大一统”的项目，试图接管一切；它还是我们这个操作系统的支柱的重要革新。然而大多数主流发行版已经接受了（或即将接受）它，因此它就保留了下来。而且它确实是有好处的：更快地启动，更简单地管理那些有依赖的服务程序，提供强大且安全的日志系统等。
|
||||
|
||||
因此在这篇教程中，我们将探索 Systemd 的特性，并向您展示如何最有效地利用这些特性。即便您此刻并不是这款软件的粉丝，读完本文后您至少可以更加了解和适应它。
|
||||
|
||||
|
||||
|
||||
**这部没正经的动画片来自[http://tinyurl.com/m2e7mv8][2]，它把 Systemd 塑造成一只狂暴的动物，吞噬它路过的一切。大多数批评者的言辞可不像这只公仔一样柔软。**
|
||||
|
||||
### 启动及服务 ###
|
||||
|
||||
大多数主流发行版要么已经采用 Systemd，要么即将在下个发布中采用（如 Debian 和 Ubuntu）。在本教程中，我们使用 Fedora 21——该发行版已经是 Systemd 的优秀实验场地——的一个预览版进行演示，但不论您用哪个发行版，要用到的命令和注意事项都应该是一样的。这是 Systemd 的一个加分点：它消除了不同发行版之间许多细微且琐碎的区别。
|
||||
|
||||
在终端中输入 **ps ax | grep systemd**，看到第一行，其中的数字 **1** 表示它的进程号是1，也就是说它是 Linux 内核发起的第一个程序。因此，内核一旦检测完硬件并组织好了内存，就会运行 **/usr/lib/systemd/systemd** 可执行程序，这个程序会按顺序依次发起其他程序。（在还没有 Systemd 的日子里，内核会去运行 **/sbin/init**，随后这个程序会在名为 SysVinit 的系统中运行其余的各种启动脚本。）
|
||||
|
||||
Systemd 的核心是一个叫*单元* (unit)的概念，它是一些存有关于服务（在运行在后台的程序），设备，挂载点，和操作系统其他方面信息的配置文件。Systemd 的其中一个目标就是简化这些事物之间的相互作用，因此如果你有程序需要在某个挂载点被创建或某个设备被接入后开始运行，Systemd 可以让这一切正常运作起来变得相当容易。（在没有 Systemd 的日子里，要使用脚本来把这些事情调配好，那可是相当丑陋的。）要列出您 Linux 系统上的所有单元，输入以下命令：
|
||||
|
||||
systemctl list-unit-files
|
||||
|
||||
现在，**systemctl** 是与 Systemd 交互的主要工具，它有不少选项。在单元列表中，您会注意到这儿有一些格式：被使能的单元显示为绿色，被禁用的显示为红色。标记为“static”的单元不能直接启用，它们是其他单元所依赖的对象。若要限制输出列表只包含服务，使用以下命令：
|
||||
|
||||
systemctl list-unit-files --type=service
|
||||
|
||||
注意，一个单元显示为“enabled”，并不等于对应的服务正在运行，而只能说明它可以被开启。要获得某个特定服务的信息，以 GDM (the Gnome Display Manager) 为例，输入以下命令：
|
||||
|
||||
systemctl status gdm.service
|
||||
|
||||
这条命令提供了许多有用的信息：一段人类可读的服务描述，单元配置文件的位置，启动的时间，进程号，以及它所从属的 CGroups （用以限制各组进程的资源开销）。
|
||||
|
||||
如果您去查看位于 **/usr/lib/systemd/system/gdm.service** 的单元配置文件，您可以看到多种选项，包括要被运行的二进制文件（“ExecStart”那一行），相冲突的其他单元（即不能同时进入运行的单元），以及需要在本单元执行前进入运行的单元（“After”那一行）。一些单元有附加的依赖选项，例如“Requires”（必要的依赖）和“Wants”（可选的依赖）。
|
||||
|
||||
此处另一个有趣的选项是：
|
||||
|
||||
Alias=display-manager.service
|
||||
|
||||
当您启动 **gdm.service** 后，您将可以通过 **systemctl status display-manager.service** 来查看它的状态。当您知道有*显示管理程序* (display manager)在运行并想对它做点什么，但您不关心那究竟是 GDM，KDM，XDM 还是什么别的显示管理程序时，这个选项会非常有用。
|
||||
|
||||
|
||||
|
||||
**使用 systemctl status 命令后面跟一个单元名，来查看对应的服务有什么情况。**
|
||||
|
||||
### “目标”锁定 ###
|
||||
|
||||
如果您在 **/usr/lib/systemd/system** 目录中输入 **ls** 命令，您将看到各种以 **.target** 结尾的文件。一个*启动目标* (target)是一种将多个单元聚合在一起以致于将它们同时启动的方式。例如，对大多数类 Unix 操作系统而言有一种“多用户”状态，意思是系统已被成功启动，后台服务正在运行，并且已准备好让一个或多个用户登陆并工作——至少在文本模式下。（其他状态包括用于进行管理工作的单用户状态，以及用于机器关机的重启状态。）
|
||||
|
||||
如果您打开 **multi-user.target** 文件一探究竟，您可能期待看到的是一个要被启动的单元列表。但您会发现这个文件内部几乎空空如也——其实，一个服务会通过 **WantedBy** 选项让自己成为启动目标的依赖。因此如果您去打开 **avahi-daemon.service**, **NetworkManager.service** 及其他 **.service** 文件看看，您将在 Install 段看到这一行：
|
||||
|
||||
WantedBy=multi-user.target
|
||||
|
||||
因此，切换到多用户启动目标会使能那些包含上述语句的单元。还有其他一些启动目标可用（例如 **emergency.target** 用于一个紧急情况使用的 shell，以及 **halt.target** 用于机器关机），您可以用以下方式轻松地在它们之间切换：
|
||||
|
||||
systemctl isolate emergency.target
|
||||
|
||||
在许多方面，这些都很像 SysVinit 中的*运行级* (runlevel)，如文本模式的 **multi-user.target** 类似于第3运行级，**graphical.target** 类似于第5运行级，**reboot.target** 类似于第6运行级，诸如此类。
|
||||
|
||||
|
||||
|
||||
**与传统的脚本相比，单元配置文件也许看起来很陌生，但并不难以理解。**
|
||||
|
||||
### 开启与停止 ###
|
||||
|
||||
现在您也许陷入了沉思：我们已经看了这么多，但仍没看到如何停止和开启服务！这其实是有原因的。从外部看，Systemd 也许很复杂，像野兽一般难以驾驭。因此在您开始摆弄它之间，有必要从宏观的角度看看它是如何工作的。实际用来管理服务的命令非常简单：
|
||||
|
||||
systemctl stop cups.service
|
||||
systemctl start cups.service
|
||||
|
||||
（若某个单元被禁用了，您可以先通过 **systemctl enable** 加该单元名的方式将其使能。这种做法会为该单元创建一个符号链接，并将其放置在当前启动目标的 .wants 目录下，这些 .wants 目录在**/etc/systemd/system** 文件夹中。）
|
||||
|
||||
还有两个有用的命令是 **systemctl restart** 和 **systemctl reload**，后面接单元名。后者要求单元重新加载它的配置文件。Systemd 的绝大部分都有良好的文档，因此您可以查看手册 (**man systemctl**) 了解每条命令的细节。
|
||||
|
||||
> ### 定时器单元：取代 Cron ###
|
||||
>
|
||||
> 除了系统初始化和服务管理，Systemd 还染指其他方面。在很大程度上，它能够完成 **cron** 的工作，而且可以说是以更灵活的方式（并带有更易读的语法）。**cron** 是一个以规定时间间隔执行任务的程序——例如清楚临时文件，刷新缓存等。
|
||||
>
|
||||
> 如果您再次进入 **/usr/lib/systemd/system** 目录，您会看到那儿有多个 **.timer** 文件。用 **less** 来查看这些文件，您会发现它们与 **.service** 和 **.target** 文件有着相似的结构，而区别在于 **[Timer]** 段。举个例子：
|
||||
>
|
||||
> [Timer]
|
||||
> OnBootSec=1h
|
||||
> OnUnitActiveSec=1w
|
||||
>
|
||||
> **OnBootSec** 选项告诉 Systemd 在系统启动一小时后启动这个单元。第二个选项的意思是：自那以后每周启动这个单元一次。关于定时器有大量选项您可以设置——输入 **man systemd.time** 查看完整列表。
|
||||
>
|
||||
> Systemd 的时间精度默认为一分钟。也就是说，它会在设定时刻的一分钟内运行单元，但不一定精确到那一秒。这么做是基于电源管理方面的原因，但如果您需要一个没有任何延时且精确到毫秒的定时器，您可以添加以下一行：
|
||||
>
|
||||
> AccuracySec=1us
|
||||
>
|
||||
> 另外， **WakeSystem** 选项（可以被设置为 true 或 false）决定了定时器是否可以唤醒处于休眠状态的机器。
|
||||
|
||||
|
||||
|
||||
**存在一个 Systemd 的图形界面程序，即便它已有多年未被积极维护。**
|
||||
|
||||
### 日志文件：向 journald 问声好 ###
|
||||
|
||||
Systemd 的第二个主要部分是 journal 。这是个日志系统，类似于 syslog 但也有些显著区别。如果您是个 Unix 日志管理模式的 粉丝，准备好热血沸腾吧：这是个二进制日志，因此您不能使用常规的命令行文本处理工具来解析它。这个设计决定不出意料地在网上引起了激烈的争论，但它的确有些优点。例如，日志可以被更系统地组织，带有更多元数据，因此可以更容易地根据可执行文件名和进程号等过滤出信息。
|
||||
|
||||
要查看整个 journal，输入以下命令：
|
||||
|
||||
journalctl
|
||||
|
||||
像许多其他的 Systemd 命令一样，该命令将输出通过管道的方式引向 **less** 程序，因此您可以使用空格键向下滚动，“/”（斜杠）键查找，以及其他熟悉的快捷键。您也能在此看到少许颜色，像红色的警告及错误信息。
|
||||
|
||||
以上命令会输出很多信息。为了限制其只输出当前启动的消息，使用如下命令：
|
||||
|
||||
journalctl -b
|
||||
|
||||
这就是 Systemd 大放异彩的地方！您想查看自上次启动以来的全部消息吗？试试 **journalctl -b -1** 吧。再上一次的？用 **-2** 替换 **-1** 吧。那自某个具体时间，例如2014年10月24日16:38以来的呢？
|
||||
|
||||
journalctl -b --since=”2014-10-24 16:38”
|
||||
|
||||
即便您对二进制日志感到遗憾，那依然是个有用的特性，并且对许多系统管理员来说，构建类似的过滤器比起写正则表达式而言容易多了。
|
||||
|
||||
我们已经可以根据特定的时间来准确查找日志了，那可以根据特定程序吗？对单元而言，试试这个：
|
||||
|
||||
journalctl -u gdm.service
|
||||
|
||||
（注意：这是个查看 X server 产生的日志的好办法。）那根据特定的进程号？
|
||||
|
||||
journalctl _PID=890
|
||||
|
||||
您甚至可以请求只看某个可执行文件产生的消息：
|
||||
|
||||
journalctl /usr/bin/pulseaudio
|
||||
|
||||
若您想将输出的消息限制在某个优先级，可以使用 **-p** 选项。该选项参数为 0 的话只会显示紧急消息（也就是说，是时候向 **\$DEITY** 祈求保佑了），为 7 的话会显示所有消息，包括调试消息。请查看手册 (**man journalctl**) 获取更多关于优先级的信息。
|
||||
|
||||
值得指出的是，您也可以将多个选项结合在一起，若想查看在当前启动中由 GDM 服务输出的优先级数小于等于 3 的消息，请使用下述命令：
|
||||
|
||||
journalctl -u gdm.service -p 3 -b
|
||||
|
||||
最后，如果您仅仅想打开一个随 journal 持续更新的终端窗口，就像在没有 Systemd 时使用 tail 命令实现的那样，输入 **journalctl -f** 就好了。
|
||||
|
||||
|
||||
|
||||
**二进制日志并不流行，但 journal 的确有它的优点，如非常方便的信息查找及过滤。**
|
||||
|
||||
> ### 没有 Systemd 的生活？###
|
||||
>
|
||||
> 如果您就是完全不能接收 Systemd，您仍然有一些主流发现版中的选择。尤其是 Slackware，作为历史最为悠久的发行版，目前还没有做出改变，但它的主要开发者并没有将其从未来规划中移除。一些不出名的发行版也在坚持使用 SysVinit 。
|
||||
>
|
||||
> 但这又将持续多久呢？Gnome 正越来越依赖于 Systemd，其他的主流桌面环境也会步其后尘。这也是引起 BSD 社区一阵恐慌的原因：Systemd 与 Linux 内核紧密相连，导致在某种程度上，桌面环境正变得越来越不可移植。一种折中的解决方案也许会以 Uselessd ([http://uselessd.darknedgy.net][3]) 的形式到来：一种裁剪版的 Systemd，纯粹专注于启动和监控进程，而不消耗整个基础系统。
|
||||
>
|
||||
> 
|
||||
>
|
||||
> 若您不喜欢 Systemd，可以尝试一下 Gentoo 发行版，它将 Systemd 作为初始化工具的一种选择，但并不强制用户使用 Systemd。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://www.linuxvoice.com/linux-101-get-the-most-out-of-systemd/
|
||||
|
||||
作者：[Mike Saunders][a]
|
||||
译者：[Ricky-Gong](https://github.com/Ricky-Gong)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://www.linuxvoice.com/author/mike/
|
||||
[1]:http://tinyurl.com/poorlennart
|
||||
[2]:http://tinyurl.com/m2e7mv8
|
||||
[3]:http://uselessd.darknedgy.net/
|
||||
Loading…
Reference in New Issue
Block a user