以编程方式编辑 crontab 并强制守护进程刷新
我正在尝试使用优秀的 CronEdit gem 在 Ruby 中为 Crontab 编写一个 Web 前端。我浏览了 Dillon Cron 的 crontab 源代码，发现它更新了一个特定的文件，以便守护进程在下一次扫描期间刷新 cron 列表。
在 VixieCron 的 man crontab 中，它说：
此外，cron 每分钟检查一次，看看它的假脱机目录的 modtime 是否 （或 /etc/crontab 上的 modtime）已更改，如果已更改，则 cron 将 检查所有 crontab 上的 modtime 并重新加载已更改的内容。 因此，每当修改 crontab 文件时，就不需要重新启动 cron。注意 crontab(1) 命令会在任何时候更新 spool 目录的 modtime 更改 crontab。
是否有任何独立于平台（Ubuntu、Red Hat、ArchLinux、Mac OS X）的方法可以确保手动编辑 Cron 文件后，守护进程不会失败地刷新它？
I'm trying to write a web frontend for Crontab in Ruby using the excellent CronEdit gem. I went through Dillon Cron's crontab source code and found that it updates a particular file so that the daemon will refresh the cron list during the next sweep.
In man crontab for VixieCron, it says:
Additionally, cron checks each minute to see if its spool directory’s modtime
(or the modtime on /etc/crontab) has changed, and if it has, cron will then
examine the modtime on all crontabs and reload those which have changed.
Thus cron need not be restarted whenever a crontab file is modified. Note that
the crontab(1) command updates the modtime of the spool directory whenever it
changes a crontab.
Is there any platform (Ubuntu, Red Hat, ArchLinux, Mac OS X) independent way to ensure that after manually editing the Cron file, the daemon refreshes it without fail?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不，没有。如果您知道它是 VixieCron，则更新目录的时间戳。否则，您可能可以伪造它：在调用
crontab -e之前设置环境变量EDITOR（这应该会打开 crontab 的编辑器）。这个想法是将编辑器设置为某个进行更改的程序。 crontab -e 将等待编辑器终止并重新读取文件并告诉 cron 某些内容已更改。
但是，如果您有旧版本的 cron，则仍然必须重新启动它。但我怀疑你能否在运行 Linux 或 Mac OS X 的任何设备上找到如此古老的版本。
No, there isn't. If you know it's VixieCron, then update the timestamp of the directory. Otherwise, you might be able to fake it: Set the env variable
EDITORbefore you invokecrontab -e(which should bring up an editor for the crontab).The idea is to set the editor to some program which makes the change.
crontab -ewill wait for the editor to terminate and reread the file and tell cron that something has changed.If you have an old version of cron, though, you must still restart it. But I doubt that you can find such ancient versions on anything that runs Linux or Mac OS X.
Sane 现代 Linux 发行版有
/etc/cron.d/目录，您可以将 crontab 条目作为单独的文件放在其中。如果我没记错的话，新的 cronfile 在写入后 2 分钟内就会被读取Sane modern linux distros have
/etc/cron.d/directory where you can put your crontab entry as a separate file. If I recall correctly the new cronfile gets read within 2 minutes of being written非常感谢 gnibbler 和 Aaron。我刚刚浏览了 Ruby 的“whenever”和“cronedit”gem 的源代码。它们都执行“crontab -”，用更新的 cron 条目替换现有的 cron 文件。这意味着与我最初的问题相反，这些库使用标准 crontab 工具，该工具反过来会执行刷新守护进程所需的任何具体操作。
我认为刷新守护进程的最好的独立于平台且与 cron（dillon、vixie、mcron 等）无关的方法是始终使用关联的 crontab 实用程序。即使以编程方式进行编辑，用户程序也必须将新的 cron 文件传递给 crontab 实用程序，该实用程序将执行该特定平台/cron 所需的任何操作。
@Mark，谢谢您的评论。但是，我试图提供一个简单的 Web 前端，用户可以通过 www 进行自定义，就像直接编辑 crontab 文件一样。
非常感谢您的回复！
Thank you very much gnibbler and Aaron. I just went through the source code for both 'whenever' and 'cronedit' gems for Ruby. Both of them does a 'crontab -' which replaces the existing cron file with the updated cron entries. That means contrary to my original question, these libraries make use of the standard crontab tool which in turn would do whatever specifics necessary to refresh the daemon.
I think the best platform-independent, and cron (dillon, vixie, mcron etc.) agnostic way to refresh the daemon is to always use the associated crontab utility. Even when editing programmatically, the user-program must pass the new cron file to the crontab utility which would do whatever is required by that specific platform/cron.
@Mark, thank you for the comments. However, I'm trying to provide a simple web frontend that the user can customize through the www just like editing the crontab file directly.
Thank you so much for your responses!
如果这很重要，为什么不使用不同的杠杆呢？换句话说，有两个选项：
crontab 1：/do/some/very/specific/thing 以及我需要更改的特定参数等。
crontab 2：/do/what/needs/to/be/done
在 #2 中，作业负责在运行时确定需要做什么并执行它。通过这种设计，需要了解 crontab 如何在某些详细级别上工作的概念是无关紧要的。
If this is that important, why not use a different lever? In other words, there are two options:
crontab 1: /do/some/very/specific/thing with specific parameters that i need to change etc.
crontab 2: /do/what/needs/to/be/done
In #2, the job is responsible for determining at run time what needs to be done and doing it. With this design, the notion of needing to understand how crontab works on some detailed level is irrelevant.