使用 systemd 定时器代替 cron 作业 | Linux 中国 我正在致力于将我的 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，µsmsec，msseconds，second，sec，sminutes，minute，min，mhours，hour，hr，hdays，day，dweeks，week，wmonths，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 的手册页，有一些不重要的修改。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 表达式中使用的典型时间格式例子。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 定时器容易的多。

傻妞设置定时自动重启 不知道是不是我的版本问题，之前看站内文章，设置了守护进程，但是仍然傻妞启动两三天后就不在线，检查后发现进入假死状态，进程还在，但是名利没有反应，所以写了个shell脚本定时重启来解决这个问题。脚本放在了文末。下载后放在傻妞的程序文件夹sillyGirl里。编辑脚本 vim restart.sh修改你自定义的日志输出目录。其余的可以不用修改，脚本内都注释清楚了。如果你有其他要定时重启的程序，也可以用这个脚本简单修改来实现，在前面基础上多加一步修改启动命令部分即可。下一步是设置定时。打开定时任务文件 vim /etc/crontab最后面加上一行新的 59 11 * root /etc/sillGirl/restart.sh然后保存退出 :wq我是设置的每天中午11：59分自动重启，这个可以按照你的需要自定义，如果不明白cron表达式怎么写可以用下面这个生成器在线生成：https://cron.qqe2.com/这样就不用再担心傻妞假死还得人工重启程序了。``

修改容器端口教程 1.把容器停止docker stop ****为你的容器名称qqbot qqbot1 ncjdc nolanjdc）2.停掉docker systemctl stop docker3，用finalshell或者宝塔一类的进入目录 /var/lib/docker/containers/几个目录自己点开找hostconfig.json 这个文件。修改这个位置的端口别动地方不要动"HostPort":"5700"}]5，重启 dockersystemctl start docker6.重启你修改的容器docker start （为你的容器名称qqbot qqbot1 ncjdc nolanjdc）7.修改完成，记得在服务器放行你修改的端口，没用的端口可以删了

手把手配置 宝塔+青龙面板+qqbot + Nvjdc（诺兰）jd代挂+欢太 一步一步完成，不会的就直接复制代码粘贴就行，前提是，新服务器或者你的服务器重置过了！ 目录1、装宝塔代码如下：（*复制粘贴回车即可*）yum install -y wget && wget -O install.sh http://download.bt.cn/install/install_6.0.sh && sh install.sh中间截图忘了截图了，有一步这里需要输入 y 然后回车（找了个别人的图）输入 y 之后，等待它自己安装完成即可，成功之后如图：复制上面的外网面板地址——下面的password，自己保存下，然后浏览器输入外网面板地址，登陆用户名和密码就是下面的username、password如果访问进不去，就去服务器控制台，安全组，放行下8888端口至此，端口放行结束，进入宝塔面板2、登录宝塔面板，安装docker登陆宝塔之后，会给你推荐安装的，直接×掉就行绑定宝塔账号可以自己注册个宝塔账号进行绑定然后左侧软件商店——搜索 docker ——安装等待安装完成 安装完成之后，首页显示这里开一下，docker到此安装完成3、安装青龙，以及拉库这里傻瓜式安装，下面代码直接复制到控制台，粘贴回车即可，5700这里是青龙管理面板端口，就是前面让你开放的端口，想改的话自己改，但是记得服务器安全组放行下端口号，也要在宝塔面板放行下端口！ wget -q https://raw.githubusercontents.com/Oreomeow/VIP/main/Scripts/sh/ql.sh -O ql.sh && bash ql.sh开始安装，不会装的，一路回车就行安装完成：宝塔放行端口：安装完成去登录青龙面板：登录网址为：ip：5700（这里默认5700为青龙面板端口）页面如果是让你设置的，直接在最后一步设置自己青龙的账号和密码即可页面如果直接是登录页面，默认账号密码都是admin，如果不对去宝塔面板——文件——根目录——root——ql——config，找到 auth.json 这个文件双击点开这个json文件，就可以看到username和password，自己直接修改自己想设置的用户名username和密码password保存就行回到青龙登录页面，输入你设置的账号密码即可拉jd代挂库青龙登录成功后左侧 定时任务——添加任务第一个名称随便写，我这里写faker3第二个命令复制下面的，粘贴就行> ql repo https://ghproxy.com/https://github.com/shufflewzc/faker3.git "jd_|jx_|gua_|jddj_|getJDCookie" "activity|backUp" "^jd[^_]|USER|function|utils|sendnotify|ZooFaker_Necklace.js|JDJRValidator_|sign_graphics_validate|ql"第三个复制下面的粘贴就行0 0 0 *然后运行脚本看日志完成之后刷新页面，在最后一页把这个任务给掉就行至此，jd代挂库拉好了依赖修复同上操作，添加脚本，执行，禁用。代码如下> ql raw https://raw.githubusercontent.com/spiritLHL/qinglong_auto_tools/master/scripts_check_dependence.py拉欢太商城脚本库同操作，下面是欢太商城脚本库，复制粘贴就行第一次拉取代码ql repo https://github.com/Mashiro2000/HeyTapTask.git "" "Backup|index|HT.|sendNotify" "HT.|sendNotify"定时0 9 *这个拉取完毕后就删除这个定时任务第二次拉取代码拉取完成后，修改拉库指令，确保HT_account.py不被覆盖，更改拉库命令，命令如下ql repo https://github.com/Mashiro2000/HeyTapTask.git "" "Backup|index|HT.*|sendNotify" "HT_config|sendNotify"定时0 9 *这个保留欢太的禁用不禁用都行3、安装与配置go-cqhttp这里我已经下载好版本，需要的直接走这里下载即可链接：https://pan.baidu.com/s/1b8fEooTyfk1AFjEAH-Pg8A 提取码：twru下载好解压是个文件夹然后进入宝塔页面，文件，进入 root 目录下直接拖住上面解压的文件夹到这个页面，进行上传然后进入到shell控制台，输入下面指令，一行一行依次复制粘贴！cd /root/go-cqhttp //切换目录到go-cqhttp 如果报错可直接使用cd go-cqhttp chmod 777 go-cqhttp //赋值权限，该行命令执行成功不会输出任何信息 ./go-cqhttp //运行 未成功则权限不够如图！别弄错！ 然后输入12，回车回到宝塔页面，进入go-cqhttp目录，有个config.yml双击编辑，找到95行，97行，以及118行、120行代码，如图（修改前）：修改这四个数据，如图（修改后）：修改后保存，回到shell控制台，输入下面命令./go-cqhttp注意，如果页面卡在这回车或者 Ctrl+C 即可，再输入上面命令回车，提示如下，等待出现二维码，用QQ小号扫码即可！（需要更换机器人QQ号，就去宝塔面板 go-cqhttp目录下删除session.token文件重复上面的步骤重新扫码登录即可，不需要更换则不操作）至此 go-cqhttp 就配置完成了，此时属于前台运行，你关闭后会自动关闭，所以需要将go-cqhttp后台运行。在控制台中 Ctrl+c然后输入 nohup ./go-cqhttp &nohup ./go-cqhttp &在目录下会生成一个nohup.out文件，就是go-cqhttp 输入的日志了。然后在控制台依次复制下面两行代码kill -9 $( ps -e|grep go-cqhttp |awk '{print $1}') //杀死进程退出 nohup ./go-cqhttp & //重启至此 go-cqhttp配置完成4、安装与配置Nvjdc（诺兰）首先控制台 Ctrl+C然后 cd /rootcd /root进入root目录下1、拉源码国内 git clone https://ghproxy.com/https://github.com/fzls/nvjdcdocker.git /root/nolanjdc 国外 git clone https://github.com/fzls/nvjdcdocker.git /root/nolanjdc这里选择国内2、拉镜像docker pull shifanga/nolanhzy:latest3、执行指令yum install wget unzip -y4、创建目录放配置cd /root/nolanjdc mkdir -p Config && cd Config5、配置 config.json 文件回到宝塔面板页面，进入 /root/nolanjdc/Config 目录下，如果有 config.json文件 就双击进去修改，如果没有，这里就新建一个文件，命名为 config.json 并 双击进去编辑config.json 文件模板，复制下面进去粘贴进行修改{ ///浏览器最多几个网页 "MaxTab": "4", //网站标题 "Title": "Sean代挂", //回收时间分钟 不填默认3分钟 "Closetime": "3", //网站公告 "Announcement": "为提高账户的安全性，请关闭免密支付。", ///开启打印等待日志卡短信验证登陆 可开启 拿到日志群里回复 默认不要填写 "Debug": "", ///自动滑块次数5次 5次后手动滑块 可设置为0默认手动滑块 "AutoCaptchaCount": "5", ///XDD PLUS Url http://IP地址:端口/api/login/smslogin "XDDurl": "", ///xddToken "XDDToken": "", ///青龙配置 注意对接XDD 对接芝士 设置为"Config":[] "Config": [ { //序号必填从1 开始 "QLkey": 1, //青龙地址 "QLurl": "", //青龙2,9 OpenApi Client ID "QL_CLIENTID": "", //青龙2,9 OpenApi Client Secret "QL_SECRET": "", //CK最大数量 "QL_CAPACITY": 40, "QRurl": "" } ] }注意：上面代码只是模板，如果你是一台服务器，一个青龙面板，需要把Config里面清空！改成下面这样！{ ///浏览器最多几个网页 "MaxTab": "4", //网站标题 "Title": "Sean代挂", //回收时间分钟 不填默认3分钟 "Closetime": "3", //网站公告 "Announcement": "为提高账户的安全性，请关闭免密支付。", ///开启打印等待日志卡短信验证登陆 可开启 拿到日志群里回复 默认不要填写 "Debug": "", ///自动滑块次数5次 5次后手动滑块 可设置为0默认手动滑块 "AutoCaptchaCount": "5", ///XDD PLUS Url http://IP地址:端口/api/login/smslogin ///青龙配置 注意对接XDD 对接芝士 设置为"Config":[] "Config": [] }这里我是自己搭配机器人挂，自己配置如下：保存后，回到控制台，继续操作6、回到nolanjdc目录创建chromium文件夹并进入（直接复制粘贴就行）cd /root/nolanjdc && mkdir -p .local-chromium/Linux-884014 && cd .local-chromium/Linux-8840147、下载 chromiumwget https://mirrors.huaweicloud.com/chromium-browser-snapshots/Linux_x64/884014/chrome-linux.zip && unzip chrome-linux.zip8、删除压缩包、返回nolanjdc目录rm -f chrome-linux.zip cd /root/nolanjdc9、启动镜像（这里我设置的诺兰端口为5800，如需更改其他端口，自行更改，记得在服务器安全组放行端口）sudo docker run --name nolanjdc -p 5800:80 -d -v "$(pwd)":/app \ -v /etc/localtime:/etc/localtime:ro \ -it --privileged=true shifanga/nolanhzy:latest10、查看日志docker logs -f nolanjdc出现下面即诺兰配置成功5.安装与配置QQBot1、安装前请先安装gityum install -y git2、docker-run 方式安装先下载要不然容易报错SDKcd /root/qqbot1 git clone https://ghproxy.com/https://github.com/asupc/qqbot-multi-platform.git app docker restart qqbot1docker run --name qqbot1 -v /root/qqbot1/app:/app -p 5010:5010 asupc/qqbot -restart:always3、qqbot配置用浏览器打开 http//ip:5010/login.html （ip改成你自己的），服务器需要放行5010 端口号。数据库会用MySQL的配置MySQL。不会用的直接默认不用改。设置用户名密码提交。配置完成提示重启容器 然后去控制台输入重启指令docker restart qqbot1重启后刷新刚刚页面输入用户名密码登录进入系统管理——基础设置里面以下是我的配置： 成功后，QQ小号会给管理员发送一条消息测试信息然后重启容器，记住，每次修改指令什么的保存后都要重启 qqbot 容器！重启指令docker restart qqbot1重启后会再收到一条消息！群文件有一个快捷指令文件，自行去qqbot后台——快捷回复添加设置即可具体效果图：至此代挂机器人搭建成功，懒得搭建的可以走我的机器人啊6、QQbot配置之前忘了写这个，大佬看不上，我是小白，自己总结下方便以后自己看。先去青龙面板，在系统设置—应用设置里，右上角添加一个应用，名字随便取，权限4个都勾选，确定保存就行，然后生成的有Client ID 和 Client Secret然后去bot后台—青龙面板—添加名称随便，面板地址就是你的青龙地址，Client ID 和 Client Secret 就是你青龙面板里生成的，复制粘贴上，最大容量就是你的这个容器最大多少，或者下面开全量也行，然后确认保存。ck增加后，在bot后台—账号管理—找到ck，点编辑，把容器选择刚刚添加的然后保存，同步cookie就行了7、欢太商城前面脚本库已经拉过了，需要欢太暂时需要自己下载抓包软件去抓你的账号的UA和CK这里手机抓包软件分享一个小黄鸟，也可以电脑模拟器+fidder抓包HttpCanary（小黄鸟）下载链接：https://pan.baidu.com/s/1S01fKIXuOGkGB1LOxT-TwA 提取码：78gt打开小黄鸟-打开欢太商城登录-点签到（网络环境安全风险一直点继续访问）进去点签到然后返回小黄鸟查看记录找这个地址，看请求https://store.oppo.com/cn/oapi/users/web/checkPeople/isNewPeople点进去复制请求里边的UA和Cookie复制在青龙面板——脚本管理——搜索HT_account.py这个脚本，进去把你抓到的数据包放进去完成后去定时任务里面找一个欢太的脚本执行下看日志，成功即可。8、感谢本篇后面根据 璃渊爱吃糖 大佬的文章来进行修改补充的，自己踩了不少坑，总结此篇

是不是发现微信没有京东红包入账了 省钱大赢家翻翻乐提现，大范围资格失效，需要重新绑定账号和微信。1、解绑帐号。手机客户端-我的-设置(右上角齿轮)-账户与安全-帐号关联-微信绑定-解除绑定。2、帐号重新绑定方式：微信 点开我的 - 支付 - 京东购物 登录绑定不推荐手机app退出账号后重新用微信登陆，因为app退出账号可能导致 cookie 和 wskey 失效。