• systemd.timer 的优势
  在 archlinux 的官网 wiki 上面有提到，为啥要使用 systemd.timer 呢？

• 由于所有的 systemd 的服务产生的信息都会被纪录 （log），因此比 crond 在 debug 上面要更清楚方便的多；

• 各项 timer 的工作可以跟 systemd 的服务相结合；

• 各项 timer 的工作可以跟 control group （cgroup，用来取代 /etc/secure/limit.conf 的功能） 结合，来限制该工作的资源利用
  虽然还是有些弱点啦～例如 systemd 的 timer 并没有 email 通知的功能 （除非自己写一个），也没有类似 anacron 的一段时间内的随机取样功能 （random_delay）， 不过，总体来说，还是挺不错的！此外，相对于 crond 最小的单位到分， systemd 是可以到秒甚至是毫秒的单位哩！相当有趣！

• 任务需求
  基本上，想要使用 systemd 的 timer 功能，你必须要有几个要件：

• 要有个 sname.service 的服务存在 （sname 是你自己指定的名称）

• sname.timer 的设置值
  你可以到 /etc/systemd/system 下面去创建这个 *.timer 档，那这个文件的内容要项有哪些东西呢？基本设置主要有下面这些： （man systemd.timer & man systemd.time）

基本的项目仅有这些而已，在设置上其实并不困难啦！

• 使用于 OnCalendar 的时间
  如果你想要从 crontab 转成这个 timer 功能的话，那么对于时间设置的格式就得要了解了解～基本上的格式如下所示：

上面谈的是基本的语法，你也可以直接使用间隔时间来处理！常用的间隔时间单位有：

• us 或 usec：微秒 （10-6 秒）
• ms 或 msec：毫秒 （10-3 秒）
• s, sec, second, seconds
• m, min, minute, minutes
• h, hr, hour, hours
• w, week, weeks
• month, months
• y, year, years
  常见的使用范例有：

• 一个循环时间运行的案例
  现在假设这样：

• 开机后 2 小时开始执行一次这个 backup.service

• 自从第一次执行后，未来我每两天要执行一次 backup.service
  好了，那么应该如何处理这个脚本呢？可以这样做喔！

如上表所示，我上次执行 backup.service 的时间是在 2015-08-13 14:50 ，由于设置两个小时执行一次，因此下次应该是 2015-08-15 14:50 执行才对！ 由于 timer 是由 timers.target 这个 unit 所管理的，而这个 timers.target 的启动时间是在 2015-08-13 14:31 ， 要注意，最终 backup.timer 所纪录的下次执行时间，其实是与 timers.target 所纪录的时间差！因此是“ 2015-08-15 14:50 - 2015-08-13 14:31 ”才对！ 所以时间差就是 2d 19min 啰！

• 一个固定日期运行的案例
  上面的案例是固定周期运行一次，那如果我希望不管上面如何运行了，我都希望星期天凌晨 2 点运行这个备份程序一遍呢？请注意，因为已经存在 backup.timer 了！ 所以，这里我用 backup2.timer 来做区隔喔！

与循环时间运行差异比较大的地方，在于这个 OnCalendar 的方法对照的时间并不是 times.target 的启动时间，而是 Unix 标准时间！ 亦即是 1970-01-01 00:00:00 去比较的！因此，当你看到最后出现的 NextElapseUSecRealtime 时，哇！下一次执行还要 45 年 + 7 个月 + 1 周 + 6 天 + 10 小时过 30 分～刚看到的时候，鸟哥确实因此揉了揉眼睛～确定没有看错…这才了解原来比对的是“日历时间”而不是某个 unit 的启动时间啊！呵呵！