document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-03 23:40:14 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #10885 from LuuMing/translate-new

Browse Source 
translated
This commit is contained in:
Xingyu.Wang 2018-10-25 22:04:57 +08:00 committed by GitHub
commit 4f781f6788
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 167 additions and 166 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

166
sources/tech/20180723 Setting Up a Timer with systemd in Linux.md
View File

@ -1,166 +0,0 @@
LuuMing translating
Setting Up a Timer with systemd in Linux
======
![](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/clock-650753_1920.jpg?itok=RiRyCbAP)
Previously, we saw how to enable and disable systemd services [by hand][1], [at boot time and on power down][2], [when a certain device is activated][3], and [when something changes in the filesystem][4].
Timers add yet another way of starting services, based on... well, time. Although similar to cron jobs, systemd timers are slightly more flexible. Let's see how they work.
### "Run when"
Let's expand the [Minetest][5] [service you set up][1] in [the first two articles of this series][2] as our first example on how to use timer units. If you haven't read those articles yet, you may want to go and give them a look now.
So you will "improve" your Minetest set up by creating a timer that will run the game's server 1 minute after boot up has finished instead of right away. The reason for this could be that, as you want your service to do other stuff, like send emails to the players telling them the game is available, you will want to make sure other services (like the network) are fully up and running before doing anything fancy.
Jumping in at the deep end, your _minetest.timer_ unit will look like this:
```
# minetest.timer
[Unit]
Description=Runs the minetest.service 1 minute after boot up
[Timer]
OnBootSec=1 m
Unit=minetest.service
[Install]
WantedBy=basic.target
```
Not hard at all.
As usual, you have a `[Unit]` section with a description of what the unit does. Nothing new there. The `[Timer]` section is new, but it is pretty self-explanatory: it contains information on when the service will be triggered and the service to trigger. In this case, the `OnBootSec` is the directive you need to tell systemd to run the service after boot has finished.
Other directives you could use are:
* `OnActiveSec=`, which tells systemd how long to wait after the timer itself is activated before starting the service.
* `OnStartupSec=`, on the other hand, tells systemd how long to wait after systemd was started before starting the service.
* `OnUnitActiveSec=` tells systemd how long to wait after the service the timer is activating was last activated.
* `OnUnitInactiveSec=` tells systemd how long to wait after the service the timer is activating was last deactivated.
Continuing down the _minetest.timer_ unit, the `basic.target` is usually used as a synchronization point for late boot services. This means it makes _minetest.timer_ wait until local mount points and swap devices are mounted, sockets, timers, path units and other basic initialization processes are running before letting _minetest.timer_ start. As we explained in [the second article on systemd units][2], _targets_ are like the old run levels and can be used to put your machine into one state or another, or, like here, to tell your service to wait until a certain state has been reached.
The _minetest.service_ you developed in the first two articles [ended up][2] looking like this:
```
# minetest.service
[Unit]
Description= Minetest server
Documentation= https://wiki.minetest.net/Main_Page
[Service]
Type= simple
User=
ExecStart= /usr/games/minetest --server
ExecStartPost= /home//bin/mtsendmail.sh "Ready to rumble?" "Minetest Starting up"
TimeoutStopSec= 180
ExecStop= /home//bin/mtsendmail.sh "Off to bed. Nightie night!" "Minetest Stopping in 2 minutes"
ExecStop= /bin/sleep 120
ExecStop= /bin/kill -2 $MAINPID
[Install]
WantedBy= multi-user.target
```
There’s nothing you need to change here. But you do have to change _mtsendmail.sh_ (your email sending script) from this:
```
#!/bin/bash
# mtsendmail
sleep 20
echo $1 | mutt -F /home/<username>/.muttrc -s "$2" my_minetest@mailing_list.com
sleep 10
```
to this:
```
#!/bin/bash
# mtsendmail.sh
echo $1 | mutt -F /home/paul/.muttrc -s "$2" pbrown@mykolab.com
```
What you are doing is stripping out those hacky pauses in the Bash script. Systemd does the waiting now.
### Making it work
To make sure things work, disable _minetest.service_ :
```
sudo systemctl disable minetest
```
so it doesn't get started when the system starts; and, instead, enable _minetest.timer_ :
```
sudo systemctl enable minetest.timer
```
Now you can reboot you server machine and, when you run `sudo journalctl -u minetest.*` you will see how, first the _minetest.timer_ unit gets executed and then the _minetest.service_ starts up after a minute... more or less.
![minetest timer][7]
Figure 1: The minetest.service gets started one minute after the minetest.timer... more or less.
[Used with permission][8]
### A Matter of Time
A couple of clarifications about why the _minetest.timer_ entry in the systemd's Journal shows its start time as 09:08:33, while the _minetest.service_ starts at 09:09:18, that is less than a minute later: First, remember we said that the `OnBootSec=` directive calculates when to start a service from when boot is complete. By the time _minetest.timer_ comes along, boot has finished a few seconds ago.
The other thing is that systemd gives itself a margin of error (by default, 1 minute) to run stuff. This helps distribute the load when several resource-intensive processes are running at the same time: by giving itself a minute, systemd can wait for some processes to power down. This also means that _minetest.service_ will start somewhere between the 1 minute and 2 minute mark after boot is completed, but when exactly within that range is anybody's guess.
For the record, [you can change the margin of error with `AccuracySec=` directive][9].
Another thing you can do is check when all the timers on your system are scheduled to run or the last time the ran:
```
systemctl list-timers --all
```
![check timer][11]
Figure 2: Check when your timers are scheduled to fire or when they fired last.
[Used with permission][8]
The final thing to take into consideration is the format you should use to express the periods of time. Systemd is very flexible in that respect: `2 h`, `2 hours` or `2hr` will all work to express a 2 hour delay. For seconds, you can use `seconds`, `second`, `sec`, and `s`, the same way as for minutes you can use `minutes`, `minute`, `min`, and `m`. You can see a full list of time units systemd understands by checking `man systemd.time`.
### Next Time
You'll see how to use calendar dates and times to run services at regular intervals and how to combine timers and device units to run services at defined point in time after you plug in some hardware.
See you then!
Learn more about Linux through the free ["Introduction to Linux" ][12]course from The Linux Foundation and edX.
--------------------------------------------------------------------------------
via: https://www.linux.com/blog/learn/intro-to-linux/2018/7/setting-timer-systemd-linux
作者：[Paul Brown][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.linux.com/users/bro66
[1]:https://www.linux.com/blog/learn/intro-to-linux/2018/5/writing-systemd-services-fun-and-profit
[2]:https://www.linux.com/blog/learn/2018/5/systemd-services-beyond-starting-and-stopping
[3]:https://www.linux.com/blog/intro-to-linux/2018/6/systemd-services-reacting-change
[4]:https://www.linux.com/blog/learn/intro-to-linux/2018/6/systemd-services-monitoring-files-and-directories
[5]:https://www.minetest.net/
[6]:/files/images/minetest-timer-1png
[7]:https://www.linux.com/sites/lcom/files/styles/rendered_file/public/minetest-timer-1.png?itok=TG0xJvYM (minetest timer)
[8]:/licenses/category/used-permission
[9]:https://www.freedesktop.org/software/systemd/man/systemd.timer.html#AccuracySec=
[10]:/files/images/minetest-timer-2png
[11]:https://www.linux.com/sites/lcom/files/styles/rendered_file/public/minetest-timer-2.png?itok=pYxyVx8- (check timer)
[12]:https://training.linuxfoundation.org/linux-courses/system-administration-training/introduction-to-linux

167
translated/tech/20180723 Setting Up a Timer with systemd in Linux.md Normal file
View File

@ -0,0 +1,167 @@
在 Linux 上使用 systemd 设置定时器
======
![](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/clock-650753_1920.jpg?itok=RiRyCbAP)
之前，我们看到了如何[手动的][1]、[在开机与关机时][2]、[在启用某个设备时][3]、[在文件系统发生改变时][4]启用与禁用 systemd 服务。
定时器增加了另一种启动服务的方式，基于...时间。尽管与定时任务很相似，但 systemd 定时器稍微地灵活一些。让我们看看它是怎么工作的。
### “定时运行”
让我们展开[本系列前两篇文章][2]中[你所设置的 ][1] [Minetest][5] 服务器作为如何使用定时器单元的第一个例子。如果你还没有读过那几篇文章，可以现在去看看。
你将通过创建一个定时器来改进 Minetest 服务器，使得在定时器启动 1 分钟后运行游戏服务器而不是立即运行。这样做的原因可能是，在启动之前可能会用到其他的服务，例如发邮件给其他玩家告诉他们游戏已经准备就绪，你要确保其他的服务（例如网络）在开始前完全启动并运行。
跳到最底下，你的 `_minetest.timer_` 单元看起来就像这样：
```
# minetest.timer
[Unit]
Description=Runs the minetest.service 1 minute after boot up
[Timer]
OnBootSec=1 m
Unit=minetest.service
[Install]
WantedBy=basic.target
```
一点也不难吧。
通常，开头是 `[Unit]` 和一段描述单元作用的信息，这儿没什么新东西。`[Timer]` 这一节是新出现的，但它的作用不言自明：它包含了何时启动服务，启动哪个服务的信息。在这个例子当中，`OnBootSec` 是告诉 systemd 在系统启动后运行服务的指令。
其他的指令有：
* `OnActiveSec=`，告诉 systemd 在定时器启动后多长时间运行服务。
* `OnStartupSec=`，同样的，它告诉 systemd 在 systemd 进程启动后多长时间运行服务。
* `OnUnitActiveSec=`，告诉 systemd 在上次由定时器激活的服务启动后多长时间运行服务。
* `OnUnitInactiveSec=`，告诉 systemd 在上次由定时器激活的服务停用后多长时间运行服务。
继续 `_minetest.timer_` 单元，`basic.target` 通常用作<ruby>后期引导服务<rt>late boot services</rt></ruby>的<ruby>同步点<rt>synchronization point</rt></ruby>。这就意味着它可以让 `_minetest.timer_` 单元运行在安装完<ruby>本地挂载点<rt>local mount points</rt></ruby>或交换设备，套接字、定时器、路径单元和其他基本的初始化进程之后。就像在[第二篇文章中 systemd 单元][2]里解释的那样，`_targets_` 就像<ruby>旧的运行等级<rt>old run levels</rt></ruby>，可以将你的计算机置于某个状态，或像这样告诉你的服务在达到某个状态后开始运行。
在前两篇文章中你配置的`_minetest.service_`文件[最终][2]看起来就像这样：
```
# minetest.service
[Unit]
Description= Minetest server
Documentation= https://wiki.minetest.net/Main_Page
[Service]
Type= simple
User=
ExecStart= /usr/games/minetest --server
ExecStartPost= /home//bin/mtsendmail.sh "Ready to rumble?" "Minetest Starting up"
TimeoutStopSec= 180
ExecStop= /home//bin/mtsendmail.sh "Off to bed. Nightie night!" "Minetest Stopping in 2 minutes"
ExecStop= /bin/sleep 120
ExecStop= /bin/kill -2 $MAINPID
[Install]
WantedBy= multi-user.target
```
这儿没什么需要修改的。但是你需要将 `_mtsendmail.sh_`（发送你的 email 的脚本）从：
```
#!/bin/bash
# mtsendmail
sleep 20
echo $1 | mutt -F /home/<username>/.muttrc -s "$2" my_minetest@mailing_list.com
sleep 10
```
改成：
```
#!/bin/bash
# mtsendmail.sh
echo $1 | mutt -F /home/paul/.muttrc -s "$2" pbrown@mykolab.com
```
你做的事是去除掉 Bash 脚本中那些蹩脚的停顿。Systemd 现在正在等待。
### 让它运行起来
确保一切运作正常，禁用 `_minetest.service_`：
```
sudo systemctl disable minetest
```
这使得系统启动时它不会一同启动；然后，相反地，启用 `_minetest.timer_`：
```
sudo systemctl enable minetest.timer
```
现在你就可以重启服务器了，当运行`sudo journalctl -u minetest.*`后，你就会看到 `_minetest.timer_` 单元执行后大约一分钟，`_minetest.service_` 单元开始运行。
![minetest timer][7]
图 1：minetest.timer 运行大约 1 分钟后 minetest.service 开始运行
[经许可使用][8]
### 时间的问题
`_minetest.timer_` 在 systemd 的日志里显示的启动时间为 09:08:33 而 `_minetest.service` 启动时间是 09:09:18，它们之间少于 1 分钟，关于这件事有几点需要说明一下：首先，请记住我们说过 `OnBootSec=` 指令是从引导完成后开始计算服务启动的时间。当 `_minetest.timer_` 的时间到来时，引导已经在几秒之前完成了。
另一件事情是 systemd 给自己设置了一个<ruby>误差幅度<rt>margin of error</rt></ruby>（默认是 1 分钟）来运行东西。这有助于在多个<ruby>资源密集型进程<rt>resource-intensive processes</rt></ruby>同时运行时分配负载：通过分配 1 分钟的时间，systemd 可以等待某些进程关闭。这也意味着 `_minetest.service_`会在引导完成后的 1~2 分钟之间启动。但精确的时间谁也不知道。
作为记录，你可以用 `AccuracySec=` 指令[修改误差幅度][9]。
你也可以检查系统上所有的定时器何时运行或是上次运行的时间：
```
systemctl list-timers --all
```
![check timer][11]
图 2：检查定时器何时运行或上次运行的时间
[经许可使用][8]
最后一件值得思考的事就是你应该用怎样的格式去表示一段时间。Systemd 在这方面非常灵活：`2 h`，`2 hours` 或 `2hr` 都可以用来表示 2 个小时。对于“秒”，你可以用 `seconds`，`second`，`sec` 和 `s`。“分”也是同样的方式：`minutes`，`minute`，`min` 和 `m`。你可以检查 `man systemd.time` 来查看 systemd 能够理解的所有时间单元。
### 下一次
下次你会看到如何使用日历中的日期和时间来定期运行服务，以及如何通过组合定时器与设备单元在插入某些硬件时运行服务。
回头见！
在 Linux 基金会和 edx 上通过免费课程 [“Introduction to Linux”][12] 学习更多关于 Linux 的知识。
--------------------------------------------------------------------------------
via: https://www.linux.com/blog/learn/intro-to-linux/2018/7/setting-timer-systemd-linux
作者：[Paul Brown][a]
选题：[lujun9972](https://github.com/lujun9972)
译者：[LuuMing](https://github.com/LuuMing)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.linux.com/users/bro66
[1]:https://www.linux.com/blog/learn/intro-to-linux/2018/5/writing-systemd-services-fun-and-profit
[2]:https://www.linux.com/blog/learn/2018/5/systemd-services-beyond-starting-and-stopping
[3]:https://www.linux.com/blog/intro-to-linux/2018/6/systemd-services-reacting-change
[4]:https://www.linux.com/blog/learn/intro-to-linux/2018/6/systemd-services-monitoring-files-and-directories
[5]:https://www.minetest.net/
[6]:/files/images/minetest-timer-1png
[7]:https://www.linux.com/sites/lcom/files/styles/rendered_file/public/minetest-timer-1.png?itok=TG0xJvYM (minetest timer)
[8]:/licenses/category/used-permission
[9]:https://www.freedesktop.org/software/systemd/man/systemd.timer.html#AccuracySec=
[10]:/files/images/minetest-timer-2png
[11]:https://www.linux.com/sites/lcom/files/styles/rendered_file/public/minetest-timer-2.png?itok=pYxyVx8- (check timer)
[12]:https://training.linuxfoundation.org/linux-courses/system-administration-training/introduction-to-linux