我可以使用 Linux crontab 指定以秒为单位的特定时间吗？

Question

49 18 * * * mpv ~/Musik/Donau.mp3

Donau.mp3该命令将在下午 6:49 正好播放该文件。例如，我如何指定下午 6:49:50？

Answer 1

使用systemd计时器： https: //wiki.archlinux.org/title/Systemd/Timers

您也可以指定秒：

OnCalendar=Mon,Tue *-*-01..04 18:49:50

或者像这样，“黑客” crontab：

49 18 * * * sleep 50; mpv ~/Musik/Donau.mp3

由于工作原理，不要期望后一种解决方案是精确的cron。

Answer 2

\n

该命令将在下午 6:49 正好播放“Donau.mp3”文件。

\n

\n

不是下午6:49，而是下午 6:49。这是一个重要的区别，实际上部分解释了为什么大多数 cron 实现不能\xe2\x80\x99 做你想做的事。

\n

从较高层面来看，crond 实际上所做的是休眠大约 60 秒，然后检查哪些作业需要运行并关闭它们，然后再次休眠大约 60 秒减去本周期检查和启动作业所花费的时间。

\n

However, none of the mechanisms used for suspending a process for some amount of time on UNIX-like systems allow for an exact wakeup time. They only let you specify a lower bound on the wakeup time. For example, in C code, sleep(10); will sleep for at least 10 seconds, but may sleep for longer than that (actually, it will almost always sleep at least one scheduling quanta longer than that). Usually the discrepancy is less than 200ms, but it\xe2\x80\x99s entirely possible for it to be significantly longer if the system is heavily loaded or the process being woken up is exceptionally low priority.

\n

For the usual case for crond of sleeping for 60 seconds, jitter of even a few seconds is generally insignificant, because it can just adjust how long it sleeps on the next cycle to compensate. If, however, it was trying to run things every second instead, jitter of more than about half a second would be enough to cause reliability issues and possibly miss events.

\n

This then brings up the question of why systemd lets you specify timestamps down to the second for timer units. The reality is that it doesn\xe2\x80\x99t actually schedule to that precision either. Systemd offers per-second resolution because it operates in a fundamentally different way from crond, instead of checking every cycle for jobs that need to run, systemd sets timers to be woken up when a job needs to run. On an idealized system with minimal timing jitter, this enables it to actually trigger things with that level of precision. In practice though, it\xe2\x80\x99s not unusual on a busy system for timer units scheduled with that precision to be a second or two late.

\n

\n

How could i (for example) specify 6:49'50pm?

\n

\n

If you truly need that level of precision, the correct answer is to use a realtime OS for whatever you\xe2\x80\x99re doing, not a time-sharing OS.

\n

You can get close to this on a Linux system by running crond with a realtime scheduling priority, but doing so safely requires a significant amount of effort to ensure that the jobs don\xe2\x80\x99t inherit that priority (which would run a nontrivial risk of them causing problems for anything else running on the system), but that still won\xe2\x80\x99t let you pick exact times down to the second to run jobs at.

\n