分类技术下的文章

将你的安卓手机屏幕投射到 Linux

Sudeshna Sur 发布于 2021-04-21
另请参阅: 桌面应用,安卓, 手机
2 条评论

使用 Scrcpy 可以把你的手机屏幕变成一个“应用”，与在树莓派或任何其他基于 Linux 的设备上的应用一起运行。

title=

要远离我们日常使用的电子产品是很难的。在熙熙攘攘的现代生活中，我想确保我不会错过手机屏幕上弹出的来自朋友和家人的重要信息。我也很忙，不希望迷失在令人分心的事情中，但是拿起手机并且回复信息往往会使我分心。

更糟糕的是，有很多的设备。幸运地是，大多数的设备（从功能强大的笔记本电脑到甚至不起眼的树莓派）都可以运行 Linux。因为它们运行的是 Linux，所以我为一种设置找到的解决方案几乎都适用于其他设备。

普遍适用

我想要一种无论我使用什么屏幕，都能统一我生活中不同来源的数据的方法。

我决定通过把手机屏幕复制到电脑上来解决这个问题。本质上，我把手机变成了一个“应用”，可以和我所有的其他程序运行在一起。这有助于我将注意力集中在桌面上，防止我走神，并使我更容易回复紧急通知。

听起来有吸引力吗？你也可以这样做。

设置 Scrcpy

Scrcpy 俗称屏幕复制（Screen Copy），是一个开源的屏幕镜像工具，它可以在 Linux、Windows 或者 macOS 上显示和控制安卓设备。安卓设备和计算机之间的通信主要是通过 USB 连接和安卓调试桥 Android Debug Bridge （ADB）。它使用 TCP/IP，且不需要 root 权限访问。

Scrcpy 的设置和配置非常简单。如果你正在运行 Fedora，你可以从 COPR 仓库安装它：

$ sudo dnf copr enable zeno/scrcpy
$ sudo dnf install scrcpy -y

在 Debian 或者 Ubuntu 上：

$ sudo apt install scrcpy

你也可以自己编译 Scrcpy。即使是在树莓派上，按照 Scrcpy 的 GitHub 主页上的说明来构建也不需要很长时间。

设置手机

Scrcpy 安装好后，你必须启用 USB 调试并授权每个设备（你的树莓派、笔记本电脑或者工作站）为受信任的控制器。

打开安卓上的“设置”应用程序。如果“开发者选项”没有被激活，按照安卓的说明来解锁它。

接下来，启用“USB 调试”。

title=

然后通过 USB 将手机连接到你的树莓派或者笔记本电脑（或者你正在使用的任何设备），如果可以选择的话，将模式设置为 PTP。如果你的手机不能使用 PTP，将你的手机设置为用于传输文件的模式（而不是，作为一个叠接 tethering 或者 MIDI 设备）。

你的手机可能会提示你授权你的电脑，这是通过它的 RSA 指纹进行识别的。你只需要在你第一次连接的时候操作即可，在之后你的手机会识别并信任你的计算机。

使用 lsusb 命令确认设置：

$ lsusb
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 011 Device 004: ID 046d:c21d Logitech, Inc. F310 Gamepad
Bus 005 Device 005: ID 0951:1666 Kingston Technology DataTraveler G4
Bus 005 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 004 Device 001: ID 18d1:4ee6 Google Inc. Nexus/Pixel Device (PTP + debug)
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

然后执行 scrcpy 以默认设置运行。

title=

性能和响应能力取决于你使用什么设备来控制你的手机。在树莓派派上，一些动画可能会变慢，甚至有时候会响应滞后。Scrcpy 提供了一个简单的解决办法：降低 Scrcpy 显示图像的位速率和分辨率使得你的计算机能够容易显示动画。使用以下命令来实现：

$ scrcpy --bit-rate 1M --max-size 800

尝试不同的值来找到一个适合你的值。为了使键入更方便，在选定一个命令之后，可以考虑创建自己的 Bash 别名。

剪断连线

Scrcpy 开始运行后，你甚至可以通过 WiFi 连接你的手机和计算机。Scrcpy 安装过程也会安装 adb，它是一个与安卓设备通信的命令。Scrcpy 也可以使用这个命令与你的设备通信，adb 可以通过 TCP/IP 连接。

title=

要尝试的话，请确保你的手机通过 WiFi 连在与你的计算机所使用的相同的无线网络上。依然不要断开你的手机与 USB 的连接！

接下来，通过手机中的“设置”，选择“关于手机”来获取你手机的 IP 地址。查看“状态”选项来获得你的地址。它通常是 192.168 或者 10 开头。

或者，你也可以使用 adb 来获得你手机的IP地址：

$ adb shell ip route | awk '{print $9}'

To connect to your device over WiFi, you must enable TCP/IP connections. This, you must do through the adb command:
$ adb tcpip 5555
Now you can disconnect your mobile from USB.
Whenever you want to connect over WiFi, first connect to the mobile with the command adb connect. For instance, assuming my mobile's IP address is 10.1.1.22, the command is:
$ adb connect 10.1.1.22:5555

连接好之后，你就可以像往常一样运行 Scrcpy 了。

远程控制

Scrcpy 很容易使用。你可以在终端或者一个图形界面应用中尝试它。

你是否在使用其它的屏幕镜像工具？如果有的话，请在评论中告诉我们吧。

via: https://opensource.com/article/21/3/android-raspberry-pi

作者：Sudeshna Sur 选题：lujun9972 译者：ShuyRoy 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

7个管理家目录的 Git 技巧

Seth Kenlon 发布于 2021-04-20
另请参阅: 技术,配置, Git, 家目录
评论

这是我怎样设置 Git 来管理我的家目录的方法。

title=

我有好几台电脑。一台笔记本电脑用于工作，一台工作站放在家里，一台树莓派（或四台），一台 Pocket CHIP，一台运行各种不同的 Linux 的 Chromebook，等等。我曾经在每台计算机上或多或少地按照相同的步骤设置我的用户环境，也经常告诉自己让每台计算机都略有不同。例如，我在工作中比在家里更经常使用 Bash 别名，并且我在家里使用的辅助脚本可能对工作没有用。

这些年来，我对各种设备的期望开始相融，我会忘记我在家用计算机上建立的功能没有移植到我的工作计算机上，诸如此类。我需要一种标准化我的自定义工具包的方法。使我感到意外的答案是 Git。

Git 是版本跟踪软件。它以既可以用在非常大的开源项目也可以用在极小的开源项目而闻名，甚至最大的专有软件公司也在用它。但是它是为源代码设计的，而不是用在一个装满音乐和视频文件、游戏、照片等的家目录。我听说过有人使用 Git 管理其家目录，但我认为这是程序员们进行的一项附带实验，而不是像我这样的现实生活中的用户。

用 Git 管理我的家目录是一个不断发展的过程。随着时间的推移我一直在学习和适应。如果你决定使用 Git 管理家目录，则可能需要记住以下几点。

1、文本和二进制位置

title=

当由 Git 管理时，除了配置文件之外，你的家目录对于所有内容而言都是“无人之地”。这意味着当你打开主目录时，除了可预见的目录的列表之外，你什么都看不到。不应有任何杂乱无章的照片或 LibreOffice 文档，也不应有 “我就在这里放一分钟” 的临时文件。

原因很简单：使用 Git 管理家目录时，家目录中所有未提交的内容都会变成噪音。每次执行 git status 时，你都必须翻过去之前 Git 未跟踪的任何文件，因此将这些文件保存在子目录（添加到 .gitignore 文件中）至关重要。

许多 Linux 发行版提供了一组默认目录：

Documents
Downloads
Music
Photos
Templates
Videos

如果需要，你可以创建更多。例如，我把创作的音乐（Music）和购买来聆听的音乐（Albums）区分开来。同样，我的电影（Cinema）目录包含了其他人的电影，而视频（Videos）目录包含我需要编辑的视频文件。换句话说，我的默认目录结构比大多数 Linux 发行版提供的默认设置更详细，但是我认为这样做有好处。如果没有适合你的目录结构，你更会将其存放在家目录中，因为没有更好的存放位置，因此请提前考虑并规划好适合你的工作目录。你以后总是可以添加更多，但是最好先开始擅长的。

2、、设置最优的 `.gitignore`

清理家目录后，你可以像往常一样将其作为 Git 存储库实例化：

$ cd
$ git init .

你的 Git 仓库中还没有任何内容，你的家目录中的所有内容均未被跟踪。你的第一项工作是筛选未跟踪文件的列表，并确定要保持未跟踪状态的文件。要查看未跟踪的文件：

$ git status
  .AndroidStudio3.2/
  .FBReader/
  .ICEauthority
  .Xauthority
  .Xdefaults
  .android/
  .arduino15/
  .ash_history
[...]

根据你使用家目录的时间长短，此列表可能很长。简单的是你在上一步中确定的目录。通过将它们添加到名为 .gitignore 的隐藏文件中，你告诉 Git 停止将它们列为未跟踪文件，并且永远不对其进行跟踪：

$ \ls -lg | grep ^d | awk '{print $8}' >> ~/.gitignore

完成后，浏览 git status 所示的其余未跟踪文件，并确定是否有其他文件需要排除。这个过程帮助我发现了几个陈旧的配置文件和目录，这些文件和目录最终被我全部丢弃了，而且还发现了一些特定于一台计算机的文件和目录。我在这里非常严格，因为许多配置文件在自动生成时会表现得更好。例如，我从不提交我的 KDE 配置文件，因为许多文件包含了诸如最新文档之类的信息以及其他机器上不存在的其他元素。

我会跟踪我的个性化配置文件、脚本和实用程序、配置文件和 Bash 配置，以及速查表和我经常引用的其他文本片段。如果有软件主要负责维护的文件，则将其忽略。当对一个文件不确定时，我将其忽略。你以后总是可以取消忽略它（通过从 .gitignore 文件中删除它）。

3、了解你的数据

我使用的是 KDE，因此我使用开源扫描程序 Filelight 来了解我的数据概况。Filelight 为你提供了一个图表，可让你查看每个目录的大小。你可以浏览每个目录以查看占用了空间的内容，然后回溯调查其他地方。这是一个令人着迷的系统视图，它使你可以以全新的方式看待你的文件。

title=

使用 Filelight 或类似的实用程序查找不需要提交的意外数据缓存。例如，KDE 文件索引器（Baloo）生成了大量特定于其主机的数据，我绝对不希望将其传输到另一台计算机。

4、不要忽略你的 `.gitignore` 文件

在某些项目中，我告诉 Git 忽略我的 .gitignore 文件，因为有时我要忽略的内容特定于我的工作目录，并且我不认为同一项目中的其他开发人员需要我告诉他们 .gitignore 文件应该是什么样子。因为我的家目录仅供我使用，所以我不会忽略我的家目录的 .gitignore 文件。我将其与其他重要文件一起提交，因此它已在我的所有系统中被继承。当然，从家目录的角度来看，我所有的系统都是相同的：它们具有一组相同的默认文件夹和许多相同的隐藏配置文件。

5、不要担心二进制文件

我对我的系统进行了数周的严格测试，确信将二进制文件提交到 Git 绝对不是明智之举。我试过 GPG 加密的密码文件、试过 LibreOffice 文档、JPEG、PNG 等等。我甚至有一个脚本，可以在将 LibreOffice 文件添加到 Git 之前先解压缩，提取其中的 XML，以便仅提交 XML，然后重新构建 LibreOffice 文件，以便可以在 LibreOffice 中继续工作。我的理论是，提交 XML 会比使用 ZIP 文件（LibreOffice 文档实际上就是一个 ZIP 文件）会让 Git 存储库更小一些。

令我惊讶的是，我发现偶尔提交一些二进制文件并没有大幅增加我的 Git 存储库的大小。我使用 Git 已经很长时间了，我知道如果我要提交几千兆的二进制数据，我的存储库将会受到影响，但是偶尔提交几个二进制文件也不是不惜一切代价要避免的紧急情况。

有了这种信心，我将字体 OTF 和 TTF 文件添加到我的标准主存储库，以及 GDM 的 .face 文件以及其他偶尔小型二进制 Blob 文件。不要想太多，不要浪费时间去避免它。只需提交即可。

6、使用私有存储库

即使托管方提供了私人帐户，也不要将你的主目录提交到公共 Git 存储库。如果你像我一样，拥有 SSH 密钥、GPG 密钥链和 GPG 加密的文件，这些文件不应该出现在任何人的服务器上，而应该出现在我自己的服务器上。

我在树莓派上运行本地 Git 服务器（这比你想象的要容易），因此我可以在家里时随时更新任何一台计算机。我是一名远程工作者，所以通常情况下就足够了，但是我也可以在旅行时通过虚拟私人网络访问我的计算机。

7、要记得推送

Git 的特点是，只有当你告诉它要推送改动时，它才会把改动推送到你的服务器上。如果你是 Git 的老用户，则此过程可能对你很自然。对于可能习惯于 Nextcloud 或 Syncthing 自动同步的新用户，这可能需要一些时间来适应。

Git 家目录

使用 Git 管理我的常用文件，不仅使我在不同设备上的生活更加便利。我知道我拥有所有配置和实用程序脚本的完整历史记录，这会鼓励我尝试新的想法，因为如果结果变得 很糟糕，则很容易回滚我的更改。Git 曾将我从在 .bashrc 文件中一个欠考虑的 umask 设置中解救出来、从深夜对包管理脚本的拙劣添加中解救出来、从当时看似很酷的 rxvt 配色方案的修改中解救出来，也许还有其他一些错误。在家目录中尝试 Git 吧，因为这些提交会让家目录融合在一起。

via: https://opensource.com/article/21/4/git-home

作者：Seth Kenlon 选题：lujun9972 译者：stevenzdg988 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

Stratis 加密入门

Briansmith 发布于 2021-04-19
另请参阅: 技术,加密, Stratis
1 条评论

Stratis 在其官方网站上被描述为“易于使用的 Linux 本地存储管理”。请看这个短视频，快速演示基础知识。该视频是在 Red Hat Enterprise Linux 8 系统上录制的。视频中显示的概念也适用于 Fedora 中的 Stratis。

Stratis 2.1 版本引入了对加密的支持。继续阅读以了解如何在 Stratis 中开始加密。

先决条件

加密需要 Stratis 2.1 或更高版本。这篇文章中的例子使用的是 Fedora 33 的预发布版本。Stratis 2.1 将用在 Fedora 33 的最终版本中。

你还需要至少一个可用的块设备来创建一个加密池。下面的例子是在 KVM 虚拟机上完成的，虚拟磁盘驱动器为 5GB（/dev/vdb）。

在内核密钥环中创建一个密钥

Linux 内核密钥环 keyring 用于存储加密密钥。关于内核密钥环的更多信息，请参考 keyrings 手册页（man keyrings）。

使用 stratis key set 命令在内核钥匙圈中设置密钥。你必须指定从哪里读取密钥。要从标准输入中读取密钥，使用 -capture-key 选项。要从文件中读取密钥，使用 -keyfile-path <file> 选项。最后一个参数是一个密钥描述。它将稍后你创建加密的 Stratis 池时使用。

例如，要创建一个描述为 pool1key 的密钥，并从标准输入中读取密钥，可以输入：

# stratis key set --capture-key pool1key
Enter desired key data followed by the return key:

该命令提示我们输入密钥数据/密码，然后密钥就创建在内核密钥环中了。

要验证密钥是否已被创建，运行 stratis key list：

# stratis key list
Key Description
pool1key

这将验证是否创建了 pool1key。请注意，这些密钥不是持久的。如果主机重启，在访问加密的 Stratis 池之前，需要再次提供密钥（此过程将在后面介绍）。

如果你有多个加密池，它们可以有一个单独的密钥，也可以共享同一个密钥。

也可以使用以下 keyctl 命令查看密钥：

# keyctl get_persistent @s
318044983
# keyctl show
Session Keyring
 701701270 --alswrv      0     0  keyring: _ses
 649111286 --alswrv      0 65534   \_ keyring: _uid.0
 318044983 ---lswrv      0 65534   \_ keyring: _persistent.0
1051260141 --alswrv      0     0       \_ user: stratis-1-key-pool1key

创建加密的 Stratis 池

现在已经为 Stratis 创建了一个密钥，下一步是创建加密的 Stratis 池。加密池只能在创建池时进行。目前不可能对现有的池进行加密。

使用 stratis pool create 命令创建一个池。添加 -key-desc 和你在上一步提供的密钥描述（pool1key）。这将向 Stratis 发出信号，池应该使用提供的密钥进行加密。下面的例子是在 /dev/vdb 上创建 Stratis 池，并将其命名为 pool1。确保在你的系统中指定一个空的/可用的设备。

# stratis pool create --key-desc pool1key pool1 /dev/vdb

你可以使用 stratis pool list 命令验证该池是否已经创建：

# stratis pool list
Name                     Total Physical   Properties
pool1   4.98 GiB / 37.63 MiB / 4.95 GiB      ~Ca, Cr

在上面显示的示例输出中，~Ca 表示禁用了缓存（~ 否定了该属性）。Cr 表示启用了加密。请注意，缓存和加密是相互排斥的。这两个功能不能同时启用。

接下来，创建一个文件系统。下面的例子演示了创建一个名为 filesystem1 的文件系统，将其挂载在 /filesystem1 挂载点上，并在新文件系统中创建一个测试文件：

# stratis filesystem create pool1 filesystem1
# mkdir /filesystem1
# mount /stratis/pool1/filesystem1 /filesystem1
# cd /filesystem1
# echo "this is a test file" > testfile

重启后访问加密池

当重新启动时，你会发现 Stratis 不再显示你的加密池或它的块设备：

# stratis pool list
Name   Total Physical   Properties

# stratis blockdev list
Pool Name   Device Node   Physical Size   Tier

要访问加密池，首先要用之前使用的相同的密钥描述和密钥数据/口令重新创建密钥：

# stratis key set --capture-key pool1key
Enter desired key data followed by the return key:

接下来，运行 stratis pool unlock 命令，并验证现在可以看到池和它的块设备：

# stratis pool unlock
# stratis pool list
Name                      Total Physical   Properties
pool1   4.98 GiB / 583.65 MiB / 4.41 GiB      ~Ca, Cr
# stratis blockdev list
Pool Name   Device Node   Physical Size   Tier
pool1       /dev/dm-2          4.98 GiB   Data

接下来，挂载文件系统并验证是否可以访问之前创建的测试文件：

# mount /stratis/pool1/filesystem1 /filesystem1/
# cat /filesystem1/testfile
this is a test file

使用 systemd 单元文件在启动时自动解锁 Stratis 池

可以在启动时自动解锁 Stratis 池，无需手动干预。但是，必须有一个包含密钥的文件。在某些环境下，将密钥存储在文件中可能会有安全问题。

下图所示的 systemd 单元文件提供了一个简单的方法来在启动时解锁 Stratis 池并挂载文件系统。欢迎提供更好的/替代方法的反馈。你可以在文章末尾的评论区提供建议。

首先用下面的命令创建你的密钥文件。确保用之前输入的相同的密钥数据/密码来代替passphrase。

# echo -n passphrase > /root/pool1key

确保该文件只能由 root 读取：

# chmod 400 /root/pool1key
# chown root:root /root/pool1key

在 /etc/systemd/system/stratis-filesystem1.service 创建包含以下内容的 systemd 单元文件：

[Unit]
Description = stratis mount pool1 filesystem1 file system
After = stratisd.service

[Service]
ExecStartPre=sleep 2
ExecStartPre=stratis key set --keyfile-path /root/pool1key pool1key
ExecStartPre=stratis pool unlock
ExecStartPre=sleep 3
ExecStart=mount /stratis/pool1/filesystem1 /filesystem1
RemainAfterExit=yes

[Install]
WantedBy = multi-user.target

接下来，启用服务，使其在启动时运行：

# systemctl enable stratis-filesystem1.service

现在重新启动并验证 Stratis 池是否已自动解锁，其文件系统是否已挂载。

结语

在今天的环境中，加密是很多人和组织的必修课。本篇文章演示了如何在 Stratis 2.1 中启用加密功能。

via: https://fedoramagazine.org/getting-started-with-stratis-encryption/

作者：briansmith 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

为什么我喜欢用 bspwm 来做我的 Linux 窗口管理器

Stephen Adams 发布于 2021-04-18
另请参阅: 桌面应用,窗口管理器, bspwm
2 条评论

在 Fedora Linux 上安装、配置并开始使用 bspwm 窗口管理器。

title=

有些人喜欢重新布置家具。还有的人喜欢尝试新鞋或定期重新装修他们的卧室。我呢，则是尝试 Linux 桌面。

在对网上看到的一些不可思议的桌面环境流口水之后，我对一个窗口管理器特别好奇：bspwm。

title=

我喜欢 i3 窗口管理器已经有一段时间了，我很喜欢它的布局方式和上手的便捷性。但 bspwm 的某些特性吸引了我。有几个原因让我决定尝试一下：

它\_只是\_一个窗口管理器（WM）。
它由几个易于配置的脚本管理。
它默认支持窗口之间的间隙。

可能是最需要指出的第一个原因是它只是一个窗口管理器。和 i3 一样，默认情况下没有任何图形化的那些花哨东西。你当然可以随心所欲地定制它，但\_你\_需要付出努力来使它看起来像你想要的。这也是它吸引我的部分原因。

虽然它可以在许多发行版上使用，但在我这个例子中使用的是 Fedora Linux。

安装 bspwm

bspwm 在大多数常见的发行版中都有打包，所以你可以用系统的包管理器安装它。下面这个命令还会安装 sxkhd，这是一个 X 窗口系统的守护程序，它“通过执行命令对输入事件做出反应”；还有 dmenu，这是一个通用的 X 窗口菜单：

dnf install bspwm sxkhd dmenu

因为 bspwm 只是一个窗口管理器，所以没有任何内置的快捷键或键盘命令。这也是它与 i3 等软件的不同之处。所以，在你第一次启动窗口管理器之前，请先配置一下 sxkhd：

systemctl start sxkhd
systemctl enable sxkhd

这样就可以在登录时启用 sxkhd，但你还需要一些基本功能的配置：

curl https://raw.githubusercontent.com/baskerville/bspwm/master/examples/sxhkdrc --output ~/.config/sxkhd/sxkhdrc

在你深入了解之前，不妨先看看这个文件，因为有些脚本调用的命令可能在你的系统中并不存在。一个很好的例子是调用 urxvt 的 super + Return 快捷键。把它改成你喜欢的终端，尤其是当你没有安装 urxvt 的时候：

#
# wm independent hotkeys
#
   
# terminal emulator
super + Return
        urxvt
   
# program launcher
super + @space
        dmenu_run

如果你使用的是 GDM、LightDM 或其他显示管理器（DM），只要在登录前选择 bspwm 即可。

配置 bspwm

当你登录后，你会看到屏幕上什么都没有。这不是你感觉到的空虚感。而是无限可能性！你现在可以开始摆弄桌面环境的所有部分了。你现在可以开始摆弄这些年你认为理所当然的桌面环境的所有部分了。从头开始构建并不容易，但一旦你掌握了诀窍，就会非常有收获。

任何窗口管理器最困难的是掌握快捷键。你开始会很慢，但在很短的时间内，你就可以只使用键盘在系统中到处操作，在你的朋友和家人面前看起来像一个终极黑客。

你可以通过编辑 ~/.config/bspwm/bspwmrc，在启动时添加应用，设置桌面和显示器，并为你的窗口应该如何表现设置规则，随心所欲地定制系统。有一些默认设置的例子可以让你开始使用。键盘快捷键都是由 sxkhdrc 文件管理的。

还有更多的开源项目可以安装，让你的电脑看起来更漂亮，比如用于桌面背景的 Feh、状态栏的 Polybar、应用启动器的 Rofi，还有 Compton 可以给你提供阴影和透明度，可以让你的电脑看起来焕然一新。

玩得愉快！

via: https://opensource.com/article/21/4/bspwm-linux

作者：Stephen Adams 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

使用 systemd 定时器代替 cron 作业

David Both 发布于 2021-04-18
另请参阅: 系统运维,systemd, 定时器, cron
1 条评论

定时器提供了比 cron 作业更为细粒度的事件控制。

title=

我正在致力于将我的 cron 作业迁移到 systemd 定时器上。我已经使用定时器多年了，但通常来说，我的学识只足以支撑我当前的工作。但在我研究 systemd 系列的过程中，我发现 systemd 定时器有一些非常有意思的能力。

与 cron 作业类似，systemd 定时器可以在特定的时间间隔触发事件（shell 脚本和程序），例如每天一次或在一个月中的特定某一天（或许只有在周一生效），或在从上午 8 点到下午 6 点的工作时间内每隔 15 分钟一次。定时器也可以做到 cron 作业无法做到的一些事情。举个例子，定时器可以在特定事件发生后的一段时间后触发一段脚本或者程序去执行，例如开机、启动、上个任务完成，甚至于定时器调用的上个服务单元的完成的时刻。

操作系统维护的计时器

当在一个新系统上安装 Fedora 或者是任意一个基于 systemd 的发行版时，作为系统维护过程的一部分，它会在 Linux 宿主机的后台中创建多个定时器。这些定时器会触发事件来执行必要的日常维护任务，比如更新系统数据库、清理临时目录、轮换日志文件，以及更多其他事件。

作为示例，我会查看一些我的主要工作站上的定时器，通过执行 systemctl status *timer 命令来展示主机上的所有定时器。星号的作用与文件通配相同，所以这个命令会列出所有的 systemd 定时器单元。

[root@testvm1 ~]# systemctl status *timer
● mlocate-updatedb.timer - Updates mlocate database every day
     Loaded: loaded (/usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● mlocate-updatedb.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Updates mlocate database every day.

● logrotate.timer - Daily rotation of log files
     Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
   Triggers: ● logrotate.service
       Docs: man:logrotate(8)
             man:logrotate.conf(5)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily rotation of log files.

● sysstat-summary.timer - Generate summary of yesterday's process accounting
     Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left
   Triggers: ● sysstat-summary.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Generate summary of yesterday's process accounting.

● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left
   Triggers: ● fstrim.service
       Docs: man:fstrim

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Discard unused blocks once a week.

● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
     Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left
   Triggers: ● sysstat-collect.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Run system activity accounting tool every 10 minutes.

● dnf-makecache.timer - dnf makecache --timer
     Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left
   Triggers: ● dnf-makecache.service

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started dnf makecache –timer.

● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
     Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
     Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
    Trigger: Fri 2020-06-05 08:19:00 EDT; 23h left
   Triggers: ● systemd-tmpfiles-clean.service
       Docs: man:tmpfiles.d(5)
             man:systemd-tmpfiles(8)

Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily Cleanup of Temporary Directories.

每个定时器至少有六行相关信息：

定时器的第一行有定时器名字和定时器目的的简短介绍
第二行展示了定时器的状态，是否已加载，定时器单元文件的完整路径以及预设信息。
第三行指明了其活动状态，包括该定时器激活的日期和时间。
第四行包括了该定时器下次被触发的日期和时间和距离触发的大概时间。
第五行展示了被定时器触发的事件或服务名称。
部分（不是全部）systemd 单元文件有相关文档的指引。我虚拟机上输出中有三个定时器有文档指引。这是一个很好（但非必要）的信息。
最后一行是计时器最近触发的服务实例的日志条目。

你也许有一些不一样的定时器，取决于你的主机。

创建一个定时器

尽管我们可以解构一个或多个现有的计时器来了解其工作原理，但让我们创建我们自己的服务单元和一个定时器去触发它。为了保持简单，我们将使用一个相当简单的例子。当我们完成这个实验之后，就能更容易理解其他定时器的工作原理以及发现它们正在做什么。

首先，创建一个运行基础东西的简单的服务，例如 free 命令。举个例子，你可能想定时监控空余内存。在 /etc/systemd/system 目录下创建如下的 myMonitor.server 单元文件。它不需要是可执行文件：

# This service unit is for testing timer units
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs system statistics to the systemd journal
Wants=myMonitor.timer

[Service]
Type=oneshot
ExecStart=/usr/bin/free

[Install]
WantedBy=multi-user.target

这大概是你能创建的最简单的服务单元了。现在我们查看一下服务状态同时测试一下服务单元确保它和我们预期一样可用。

[root@testvm1 system]# systemctl status myMonitor.service
● myMonitor.service - Logs system statistics to the systemd journal
     Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
[root@testvm1 system]# systemctl start myMonitor.service
[root@testvm1 system]#

输出在哪里呢？默认情况下，systemd 服务单元执行程序的标准输出（STDOUT）会被发送到系统日志中，它保留了记录供现在或者之后（直到某个时间点）查看。（在本系列的后续文章中，我将介绍系统日志的记录和保留策略）。专门查看你的服务单元的日志，而且只针对今天。-S 选项，即 --since 的缩写，允许你指定 journalctl 工具搜索条目的时间段。这并不代表你不关心过往结果 —— 在这个案例中，不会有过往记录 —— 如果你的机器以及运行了很长时间且堆积了大量的日志，它可以缩短搜索时间。

[root@testvm1 system]# journalctl -S today -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. --
Jun 11 09:12:09 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 09:12:09 testvm1.both.org free[377966]:               total        used        free      shared  buff/cache   available
Jun 11 09:12:09 testvm1.both.org free[377966]: Mem:       12635740      522868    11032860        8016     1080012    11821508
Jun 11 09:12:09 testvm1.both.org free[377966]: Swap:       8388604           0     8388604
Jun 11 09:12:09 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
[root@testvm1 system]#

由服务触发的任务可以是单个程序、一组程序或者是一个脚本语言写的脚本。通过在 myMonitor.service 单元文件里的 [Service] 块末尾中添加如下行可以为服务添加另一个任务：

ExecStart=/usr/bin/lsblk

再次启动服务，查看日志检查结果，结果应该看上去像这样。你应该在日志中看到两条命令的结果输出：

Jun 11 15:42:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 15:42:18 testvm1.both.org free[379961]:               total        used        free      shared  buff/cache   available
Jun 11 15:42:18 testvm1.both.org free[379961]: Mem:       12635740      531788    11019540        8024     1084412    11812272
Jun 11 15:42:18 testvm1.both.org free[379961]: Swap:       8388604           0     8388604
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sda             8:0    0  120G  0 disk
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─sda1          8:1    0    4G  0 part /boot
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─sda2          8:2    0  116G  0 part
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 11 15:42:18 testvm1.both.org lsblk[379962]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sr0            11:0    1 1024M  0 rom
Jun 11 15:42:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 11 15:42:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

现在你知道了你的服务可以按预期工作了，在 /etc/systemd/system 目录下创建 myMonitor.timer 定时器单元文件，添加如下代码：

# This timer unit is for testing
# By David Both
# Licensed under GPL V2
#

[Unit]
Description=Logs some system statistics to the systemd journal
Requires=myMonitor.service

[Timer]
Unit=myMonitor.service
OnCalendar=*-*-* *:*:00

[Install]
WantedBy=timers.target

在 myMonitor.timer 文件中的 OnCalendar 时间格式，*-*-* *:*:00，应该会每分钟触发一次定时器去执行 myMonitor.service 单元。我会在文章的后面进一步探索 OnCalendar 设置。

到目前为止，在服务被计时器触发运行时观察与之有关的日志记录。你也可以跟踪计时器，跟踪服务可以让你接近实时的看到结果。执行 journalctl 时带上 -f 选项：

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --

执行但是不启用该定时器，看看它运行一段时间后发生了什么：

[root@testvm1 ~]# systemctl start myMonitor.service
[root@testvm1 ~]#

一条结果立即就显示出来了，下一条大概在一分钟后出来。观察几分钟日志，看看你有没有跟我发现同样的事情：

[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Jun 13 08:39:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:39:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:39:19 testvm1.both.org free[630566]:               total        used        free      shared  buff/cache   available
Jun 13 08:39:19 testvm1.both.org free[630566]: Mem:       12635740      556604    10965516        8036     1113620    11785628
Jun 13 08:39:19 testvm1.both.org free[630566]: Swap:       8388604           0     8388604
Jun 13 08:39:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sda             8:0    0  120G  0 disk
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─sda2          8:2    0  116G  0 part
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:39:19 testvm1.both.org lsblk[630567]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:40:46 testvm1.both.org free[630572]:               total        used        free      shared  buff/cache   available
Jun 13 08:40:46 testvm1.both.org free[630572]: Mem:       12635740      555228    10966836        8036     1113676    11786996
Jun 13 08:40:46 testvm1.both.org free[630572]: Swap:       8388604           0     8388604
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sda             8:0    0  120G  0 disk
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─sda2          8:2    0  116G  0 part
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:40:46 testvm1.both.org lsblk[630574]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sr0            11:0    1 1024M  0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:40:46 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:41:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:41:46 testvm1.both.org free[630580]:               total        used        free      shared  buff/cache   available
Jun 13 08:41:46 testvm1.both.org free[630580]: Mem:       12635740      553488    10968564        8036     1113688    11788744
Jun 13 08:41:46 testvm1.both.org free[630580]: Swap:       8388604           0     8388604
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sda             8:0    0  120G  0 disk
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─sda1          8:1    0    4G  0 part /boot
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─sda2          8:2    0  116G  0 part
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-root 253:0    0    5G  0 lvm  /
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-swap 253:1    0    8G  0 lvm  [SWAP]
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-usr  253:2    0   30G  0 lvm  /usr
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-tmp  253:3    0   10G  0 lvm  /tmp
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   ├─VG01-var  253:4    0   20G  0 lvm  /var
Jun 13 08:41:47 testvm1.both.org lsblk[630581]:   └─VG01-home 253:5    0   10G  0 lvm  /home
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sr0            11:0    1 1024M  0 rom
Jun 13 08:41:47 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:41:47 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.

别忘了检查下计时器和服务的状态。

你在日志里大概至少注意到两件事。第一，你不需要特地做什么来让 myMonitor.service 单元中 ExecStart 触发器产生的 STDOUT 存储到日志里。这都是用 systemd 来运行服务的一部分功能。然而，它确实意味着你需要小心对待服务单元里面执行的脚本和它们能产生多少 STDOUT。

第二，定时器并不是精确在每分钟的 :00 秒执行的，甚至每次执行的时间间隔都不是刚好一分钟。这是特意的设计，但是有必要的话可以改变这种行为（如果只是它挑战了你的系统管理员的敏感神经）。

这样设计的初衷是为了防止多个服务在完全相同的时刻被触发。举个例子，你可以用例如 Weekly，Daily 等时间格式。这些快捷写法都被定义为在某一天的 00:00:00 执行。当多个定时器都这样定义的话，有很大可能它们会同时执行。

systemd 定时器被故意设计成在规定时间附近随机波动的时间点触发，以避免同一时间触发。它们在一个时间窗口内半随机触发，时间窗口开始于预设的触发时间，结束于预设时间后一分钟。根据 systemd.timer 的手册页，这个触发时间相对于其他已经定义的定时器单元保持在稳定的位置。你可以在日志条目中看到，定时器在启动后立即触发，然后在每分钟后的 46 或 47 秒触发。

大部分情况下，这种概率抖动的定时器是没事的。当调度类似执行备份的任务，只需要它们在下班时间运行，这样是没问题的。系统管理员可以选择确定的开始时间来确保不和其他任务冲突，例如 01:05:00 这样典型的 cron 作业时间，但是有很大范围的时间值可以满足这一点。在开始时间上的一个分钟级别的随机往往是无关紧要的。

然而，对某些任务来说，精确的触发时间是个硬性要求。对于这类任务，你可以向单元文件的 Timer 块中添加如下声明来指定更高的触发时间跨度精确度（精确到微秒以内）：

AccuracySec=1us

时间跨度可用于指定所需的精度，以及定义重复事件或一次性事件的时间跨度。它能识别以下单位：

usec，us，µs
msec，ms
seconds，second，sec，s
minutes，minute，min，m
hours，hour，hr，h
days，day，d
weeks，week，w
months，month，M（定义为 30.44 天）
years，year，y（定义为 365.25 天）

所有 /usr/lib/systemd/system 中的定时器都指定了一个更宽松的时间精度，因为精准时间没那么重要。看看这些系统创建的定时器的时间格式：

[root@testvm1 system]# grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/logwatch.timer:AccuracySec=12h
/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h
/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h
/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h
[root@testvm1 system]#

看下 /usr/lib/systemd/system 目录下部分定时器单元文件的完整内容，看看它们是如何构建的。

在本实验中不必让这个定时器在启动时激活，但下面这个命令可以设置开机自启：

[root@testvm1 system]# systemctl enable myMonitor.timer

你创建的单元文件不需要是可执行的。你同样不需要启用服务，因为它是被定时器触发的。如果你需要的话，你仍然可以在命令行里手动触发该服务单元。尝试一下，然后观察日志。

关于定时器精度、事件时间规格和触发事件的详细信息，请参见 systemd.timer 和 systemd.time 的手册页。

定时器类型

systemd 定时器还有一些在 cron 中找不到的功能，cron 只在确定的、重复的、具体的日期和时间触发。systemd 定时器可以被配置成根据其他 systemd 单元状态发生改变时触发。举个例子，定时器可以配置成在系统开机、启动后，或是某个确定的服务单元激活之后的一段时间被触发。这些被称为单调计时器。“单调”指的是一个持续增长的计数器或序列。这些定时器不是持久的，因为它们在每次启动后都会重置。

表格 1 列出了一些单调定时器以及每个定时器的简短定义，同时有 OnCalendar 定时器，这些不是单调的，它们被用于指定未来有可能重复的某个确定时间。这个信息来自于 systemd.timer 的手册页，有一些不重要的修改。

定时器	单调性	定义
`OnActiveSec=`	X	定义了一个与定时器被激活的那一刻相关的定时器。
`OnBootSec=`	X	定义了一个与机器启动时间相关的计时器。
`OnStartupSec=`	X	定义了一个与服务管理器首次启动相关的计时器。对于系统定时器来说，这个定时器与 `OnBootSec=` 类似，因为系统服务管理器在机器启动后很短的时间后就会启动。当以在每个用户服务管理器中运行的单元进行配置时，它尤其有用，因为用户的服务管理器通常在首次登录后启动，而不是机器启动后。
`OnUnitActiveSec=`	X	定义了一个与将要激活的定时器上次激活时间相关的定时器。
`OnUnitInactiveSec=`	X	定义了一个与将要激活的定时器上次停用时间相关的定时器。
`OnCalendar=`		定义了一个有日期事件表达式语法的实时（即时钟）定时器。查看 `systemd.time(7)` 的手册页获取更多与日历事件表达式相关的语法信息。除此以外，它的语义和 `OnActiveSec=` 类似。

Table 1: systemd 定时器定义

单调计时器可使用同样的简写名作为它们的时间跨度，即我们之前提到的 AccuracySec 表达式，但是 systemd 将这些名字统一转换成了秒。举个例子，比如你想规定某个定时器在系统启动后五天触发一次事件；它可能看起来像 OnBootSec=5d。如果机器启动于 2020-06-15 09:45:27，这个定时器会在 2020-06-20 09:45:27 或在这之后的一分钟内触发。

日历事件格式

日历事件格式是定时器在所需的重复时间触发的关键。我们开始看下一些 OnCalendar 设置一起使用的格式。

与 crontab 中的格式相比，systemd 及其计时器使用的时间和日历格式风格不同。它比 crontab 更为灵活，而且可以使用类似 at 命令的方式允许模糊的日期和时间。它还应该足够熟悉使其易于理解。

systemd 定时器使用 OnCalendar= 的基础格式是 DOW YYYY-MM-DD HH:MM:SS。DOW（星期几）是选填的，其他字段可以用一个星号（*）来匹配此位置的任意值。所有的日历时间格式会被转换成标准格式。如果时间没有指定，它会被设置为 00:00:00。如果日期没有指定但是时间指定了，那么下次匹配的时间可能是今天或者明天，取决于当前的时间。月份和星期可以使用名称或数字。每个单元都可以使用逗号分隔的列表。单元范围可以在开始值和结束值之间用 .. 指定。

指定日期有一些有趣的选项，波浪号（~）可以指定月份的最后一天或者最后一天之前的某几天。/ 可以用来指定星期几作为修饰符。

这里有几个在 OnCalendar 表达式中使用的典型时间格式例子。

日期事件格式	描述
`DOW YYYY-MM-DD HH:MM:SS`
`--* 00:15:30`	每年每月每天的 0 点 15 分 30 秒
`Weekly`	每个周一的 00:00:00
`Mon --* 00:00:00`	同上
`Mon`	同上
`Wed 2020--`	2020 年每个周三的 00:00:00
`Mon..Fri 2021--`	2021 年的每个工作日（周一到周五）的 00:00:00
`2022-6,7,8-1,15 01:15:00`	2022 年 6、7、8 月的 1 到 15 号的 01:15:00
`Mon *-05~03`	每年五月份的下个周一同时也是月末的倒数第三天
`Mon..Fri *-08~04`	任何年份 8 月末的倒数第四天，同时也须是工作日
`*-05~03/2`	五月末的倒数第三天，然后 2 天后再来一次。每年重复一次。注意这个表达式使用了波浪号（`~`）。
`*-05-03/2`	五月的第三天，然后每两天重复一次直到 5 月底。注意这个表达式使用了破折号（`-`）。

Table 2: OnCalendar 事件时间格式例子

测试日历格式

systemd 提供了一个绝佳的工具用于检测和测试定时器中日历时间事件的格式。systemd-analyze calendar 工具解析一个时间事件格式，提供标准格式和其他有趣的信息，例如下次“经过”（即匹配）的日期和时间，以及距离下次触发之前大概时间。

首先，看看未来没有时间的日（注意 Next elapse 和 UTC 的时间会根据你当地时区改变）:

[student@studentvm1 ~]$ systemd-analyze calendar 2030-06-17
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

现在添加一个时间，在这个例子中，日期和时间是当作无关的部分分开解析的：

[root@testvm1 system]# systemd-analyze calendar 2030-06-17 15:21:16
  Original form: 2030-06-17                
Normalized form: 2030-06-17 00:00:00        
    Next elapse: Mon 2030-06-17 00:00:00 EDT
       (in UTC): Mon 2030-06-17 04:00:00 UTC
       From now: 10 years 0 months left    

  Original form: 15:21:16                  
Normalized form: *-*-* 15:21:16            
    Next elapse: Mon 2020-06-15 15:21:16 EDT
       (in UTC): Mon 2020-06-15 19:21:16 UTC
       From now: 3h 55min left              
[root@testvm1 system]#

为了把日期和时间当作一个单元来分析，可以把它们包在引号里。你在定时器单元里 OnCalendar= 时间格式中使用的时候记得把引号去掉，否则会报错：

[root@testvm1 system]# systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16        
    Next elapse: Mon 2030-06-17 15:21:16 EDT
       (in UTC): Mon 2030-06-17 19:21:16 UTC
       From now: 10 years 0 months left    
[root@testvm1 system]#

现在我们测试下 Table2 里的例子。我尤其喜欢最后一个：

[root@testvm1 system]# systemd-analyze calendar "2022-6,7,8-1,15 01:15:00"
  Original form: 2022-6,7,8-1,15 01:15:00
Normalized form: 2022-06,07,08-01,15 01:15:00
    Next elapse: Wed 2022-06-01 01:15:00 EDT
       (in UTC): Wed 2022-06-01 05:15:00 UTC
       From now: 1 years 11 months left
[root@testvm1 system]#

让我们看一个例子，这个例子里我们列出了时间表达式的五个经过时间。

[root@testvm1 ~]# systemd-analyze calendar --iterations=5 "Mon *-05~3"
  Original form: Mon *-05~3                
Normalized form: Mon *-05~03 00:00:00      
    Next elapse: Mon 2023-05-29 00:00:00 EDT
       (in UTC): Mon 2023-05-29 04:00:00 UTC
       From now: 2 years 11 months left    
       Iter. #2: Mon 2028-05-29 00:00:00 EDT
       (in UTC): Mon 2028-05-29 04:00:00 UTC
       From now: 7 years 11 months left    
       Iter. #3: Mon 2034-05-29 00:00:00 EDT
       (in UTC): Mon 2034-05-29 04:00:00 UTC
       From now: 13 years 11 months left    
       Iter. #4: Mon 2045-05-29 00:00:00 EDT
       (in UTC): Mon 2045-05-29 04:00:00 UTC
       From now: 24 years 11 months left    
       Iter. #5: Mon 2051-05-29 00:00:00 EDT
       (in UTC): Mon 2051-05-29 04:00:00 UTC
       From now: 30 years 11 months left    
[root@testvm1 ~]#

这些应该为你提供了足够的信息去开始测试你的 OnCalendar 时间格式。systemd-analyze 工具可用于其他有趣的分析，我会在这个系列的下一篇文章来探索这些。

总结

systemd 定时器可以用于执行和 cron 工具相同的任务，但是通过按照日历和单调时间格式去触发事件的方法提供了更多的灵活性。

虽然你为此次实验创建的服务单元通常是由定时器调用的，你也可以随时使用 systemctl start myMonitor.service 命令去触发它。可以在一个定时器中编写多个维护任务的脚本；它们可以是 Bash 脚本或者其他 Linux 程序。你可以通过触发定时器来运行所有的脚本来运行服务，也可以按照需要执行单独的脚本。

我会在下篇文章中更加深入的探索 systemd 时间格式的用处。

我还没有看到任何迹象表明 cron 和 at 将被废弃。我希望这种情况不会发生，因为至少 at 在执行一次性调度任务的时候要比 systemd 定时器容易的多。

参考资料

网上有大量的关于 systemd 的参考资料，但是大部分都有点简略、晦涩甚至有误导性。除了本文中提到的资料，下列的网页提供了跟多可靠且详细的 systemd 入门信息。

Fedora 项目有一篇切实好用的 systemd 入门，它囊括了几乎所有你需要知道的关于如何使用 systemd 配置、管理和维护 Fedora 计算机的信息。
Fedora 项目也有一个不错的备忘录，交叉引用了过去 SystemV 命令和 systemd 命令做对比。
关于 systemd 的技术细节和创建这个项目的原因，请查看 Freedesktop.org 上的 systemd 描述。
Linux.com 的“更多 systemd 的乐趣”栏目提供了更多高级的 systemd 信息和技巧。

此外，还有一系列深度的技术文章，是由 systemd 的设计者和主要实现者 Lennart Poettering 为 Linux 系统管理员撰写的。这些文章写于 2010 年 4 月至 2011 年 9 月间，但它们现在和当时一样具有现实意义。关于 systemd 及其生态的许多其他好文章都是基于这些文章：

via: https://opensource.com/article/20/7/systemd-timers

作者：David Both 选题：lujun9972 译者：tt67wq 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出

我使用 Git cherry-pick 命令的 3 个理由

Manaswini Das 发布于 2021-04-18
另请参阅: 软件开发,Git, 遴选
评论

“遴选”可以解决 Git 仓库中的很多问题。以下是用 git cherry-pick 修复错误的三种方法。

title=

在版本控制系统中摸索前进是一件很棘手的事情。对于一个新手来说，这可能是非常难以应付的，但熟悉版本控制系统（如 Git）的术语和基础知识是开始为开源贡献的第一步。

熟悉 Git 也能帮助你在开源之路上走出困境。Git 功能强大，让你感觉自己在掌控之中 —— 没有哪一种方法会让你无法恢复到工作版本。

这里有一个例子可以帮助你理解“ 遴选 cherry-pick ”的重要性。假设你已经在一个分支上做了好几个提交，但你意识到这是个错误的分支！你现在该怎么办？你现在要做什么？要么在正确的分支上重复所有的变更，然后重新提交，要么把这个分支合并到正确的分支上。等一下，前者太过繁琐，而你可能不想做后者。那么，还有没有办法呢？有的，Git 已经为你准备好了。这就是“遴选”的作用。顾名思义，你可以用它从一个分支中手工遴选一个提交，然后转移到另一个分支。

使用遴选的原因有很多。以下是其中的三个原因。

避免重复性工作

如果你可以直接将相同的提交复制到另一个分支，就没有必要在不同的分支中重做相同的变更。请注意，遴选出来的提交会在另一个分支中创建带有新哈希的新提交，所以如果你看到不同的提交哈希，请不要感到困惑。

如果您想知道什么是提交的哈希，以及它是如何生成的，这里有一个说明可以帮助你。提交哈希是用 SHA-1 算法生成的字符串。SHA-1 算法接收一个输入，然后输出一个唯一的 40 个字符的哈希值。如果你使用的是 POSIX 系统，请尝试在您的终端上运行这个命令：

$ echo -n "commit" | openssl sha1

这将输出一个唯一的 40 个字符的哈希值 4015b57a143aec5156fd1444a017a32137a3fd0f。这个哈希代表了字符串 commit。

Git 在提交时生成的 SHA-1 哈希值不仅仅代表一个字符串。它代表的是：

sha1(
    meta data
        commit message
        committer
        commit date
        author
        authoring date
    Hash of the entire tree object
)

这就解释了为什么你对代码所做的任何细微改动都会得到一个独特的提交哈希值。哪怕是一个微小的改动都会被发现。这是因为 Git 具有完整性。

撤销/恢复丢失的更改

当你想恢复到工作版本时，遴选就很方便。当多个开发人员在同一个代码库上工作时，很可能会丢失更改，最新的版本会被转移到一个陈旧的或非工作版本上。这时，遴选提交到工作版本就可以成为救星。

它是如何工作的？

假设有两个分支：feature1 和 feature2，你想把 feature1 中的提交应用到 feature2。

在 feature1 分支上，运行 git log 命令，复制你想遴选的提交哈希值。你可以看到一系列类似于下面代码示例的提交。commit 后面的字母数字代码就是你需要复制的提交哈希。为了方便起见，您可以选择复制前六个字符（本例中为 966cf3）。

commit 966cf3d08b09a2da3f2f58c0818baa37184c9778 (HEAD -> master)
Author: manaswinidas <me@example.com>
Date:   Mon Mar 8 09:20:21 2021 +1300

   add instructions

然后切换到 feature2 分支，在刚刚从日志中得到的哈希值上运行 git cherry-pick：

$ git checkout feature2
$ git cherry-pick 966cf3.

如果该分支不存在，使用 git checkout -b feature2 来创建它。

这里有一个问题。你可能会遇到下面这种情况：

$ git cherry-pick 966cf3
On branch feature2
You are currently cherry-picking commit 966cf3d.

nothing to commit, working tree clean
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

   git commit --allow-empty

Otherwise, please use 'git reset'

不要惊慌。只要按照建议运行 git commit --allow-empty：

$ git commit --allow-empty
[feature2 afb6fcb] add instructions
Date: Mon Mar 8 09:20:21 2021 +1300

这将打开你的默认编辑器，允许你编辑提交信息。如果你没有什么要补充的，可以保存现有的信息。

就这样，你完成了你的第一次遴选。如上所述，如果你在分支 feature2 上运行 git log，你会看到一个不同的提交哈希。下面是一个例子：

commit afb6fcb87083c8f41089cad58deb97a5380cb2c2 (HEAD -&gt; feature2)
Author: manaswinidas &lt;[me@example.com][4]&gt;
Date:   Mon Mar 8 09:20:21 2021 +1300
   add instructions

不要对不同的提交哈希感到困惑。这只是区分 feature1 和 feature2 的提交。

遴选多个提交

但如果你想遴选多个提交的内容呢？你可以使用：

git cherry-pick <commit-hash1> <commit-hash2>... <commit-hashn>

请注意，你不必使用整个提交的哈希值，你可以使用前五到六个字符。

同样，这也是很繁琐的。如果你想遴选的提交是一系列的连续提交呢？这种方法太费劲了。别担心，有一个更简单的方法。

假设你有两个分支：

feature1 包括你想复制的提交（从更早的 commitA 到 commitB）。
feature2 是你想把提交从 feature1 转移到的分支。

然后：

输入 git checkout <feature1>。
获取 commitA 和 commitB 的哈希值。
输入 git checkout <branchB>。
输入 git cherry-pick <commitA>^..<commitB> （请注意，这包括 commitA 和 commitB）。
如果遇到合并冲突，像往常一样解决，然后输入 git cherry-pick --continue 恢复遴选过程。

重要的遴选选项

以下是 Git 文档中的一些有用的选项，你可以在 cherry-pick 命令中使用。

-e、--edit：用这个选项，git cherry-pick 可以让你在提交前编辑提交信息。
-s、--signoff：在提交信息的结尾添加 Signed-off by 行。更多信息请参见 git-commit(1) 中的 signoff 选项。
-S[<keyid>]、--pgg-sign[=<keyid>]：这些是 GPG 签名的提交。keyid 参数是可选的，默认为提交者身份；如果指定了，则必须嵌在选项中，不加空格。
--ff：如果当前 HEAD 与遴选的提交的父级提交相同，则会对该提交进行快进操作。

下面是除了 --continue 外的一些其他的后继操作子命令：

--quit：你可以忘记当前正在进行的操作。这可以用来清除遴选或撤销失败后的后继操作状态。
--abort：取消操作并返回到操作序列前状态。

下面是一些关于遴选的例子：

git cherry-pick master：应用 master 分支顶端的提交所引入的变更，并创建一个包含该变更的新提交。
git cherry-pick master~4 master~2'：应用master` 指向的第五个和第三个最新提交所带来的变化，并根据这些变化创建两个新的提交。

感到不知所措？你不需要记住所有的命令。你可以随时在你的终端输入 git cherry-pick --help 查看更多选项或帮助。

via: https://opensource.com/article/21/3/git-cherry-pick

作者：Manaswini Das 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国荣誉推出