我应该以根用户身份编辑/ etc / crontab还是运行crontab -e？

43

我正在设置必须以root用户身份运行的常规系统维护任务。我计划使用Ubuntu 14.04 LTS随附的cron样式作为默认样式。

我看到以前的管理员（他离开公司以来）直接编辑了/ etc / crontab。但是我知道另一种可能的方法是使用crontab -eroot。是否有任何引人入胜的论点来使用其中之一，还是仅凭偏好？

linux cron ubuntu-14.04

— marcv81
source

9

对我来说，这似乎是一个合理的最佳实践问题，我希望它不会被关闭。我已经可以看到答案中有相关的事实要点和评论。

— MadHatter

1

我曾经输入crontab -l（列出crontab），但是我输入了crontab-;。错误地删除了我的crontab。那天我学到了很多东西。

— 伐木工人

64

请注意，个人crontab（crontab -e）中的作业始终以其所有者的身份执行，这可能很有用，其中/etc/crontab包含一个附加的必填<user>字段，允许管理员将作业配置为以非root用户身份运行。

编辑系统crontab或为root设置个人crontab可能更具可移植性，并非特定于某些Linux发行版，并且对于人来说维护起来更方便，因为所有作业都在一个文件中，但是：

我个人比较赞成第三个选择：对于每个计划的任务，要么

/etc/cron.d/带有cron片段的文件
相关/etc/cron.[hourly |daily |weekly |monthly]目录中的可执行文件（脚本）。

这更容易编写脚本（您可以简单地创建/覆盖/删除此类文件，而不必在单个crontab文件的内容中乱糟糟），并且与配置管理工具配合得很好，这就是程序包管理器已经无论如何。

中的作业/脚本/etc/cron.[hourly |daily |weekly |monthly]始终以root身份执行，其中的cron片段/etc/cron.d/既可以设置自定义时间表，也可以使用与相同的必填<user>字段以其他用户身份运行/etc/crontab。

— 鲁比恩
source

18

编辑的一个缺点/etc/crontab是，每当您更新cron软件包时，都将需要合并。如果只是将新文件添加到其中一个/etc/cron.*目录中，则不会有此问题。

— kasperd

1

你应该补充一点，在大多数发行版/etc/cron.[hourly |daily |weekly |monthly]拥有可执行文件，同时/etc/cron.d持有的crontab。除此之外，+ 1。

— GnP

我绝对是cron。[timing]目录的支持者，我很少需要比commn选项更详细的内容。尽管请注意，某些发行版，尤其是Ubuntu，将默默地忽略这些文件夹中带有文件扩展名的脚本（考虑到大多数人会添加.sh，这是一个相当破坏互联网的错误，这在最近的发行版中已得到修复）。很难弄清为什么脚本在这种情况下不起作用-至少可以确保添加到crontab中。

— Gargravarr

15

尽我所记得，它crontab -e还有一个额外的优势，即它在安装crontab语法之前先对其进行了验证，如果出错，将出错并恢复以前的版本。这样，如果您弄错了语法，以前所有有效的操作都不会突然停止。我认为最佳实践是使用实用程序，例如运行visudo而不是/etc/sudoers直接编辑。

— Gargravarr
source

2

+1有关语法验证的要点，尽管它可以识别一些语法错误，但它也不是万无一失的（例如，它很乐意允许您/etc/crontab在第6列中输入带有用户名的行）。-尽管我想证明使用交互式工具不是“最佳实践”，但是您应该使用Puppet / Salt / Ansible等工具自动化，并且一开始就不应该再手动配置服务器。另一方面，如果您是守旧派，那么确实可以使用您的工具。

— HBruijn

如果您配置5台以上的服务器，那么Ansible和其他服务器都很好，但是仅用1台服务器就不值得麻烦。您可能会争辩说，只有1台服务器，Ansible脚本使您能够在两年后发生故障时以相同的方式重建它，但是到那时，由于发行版/存储库的更改，脚本可能不再起作用。

— marcv81 2013年

这就是我强烈不同意已接受答案的原因。无论进行什么更改，都应至少在此验证过程中运行一次。如果然后从新的crontab复制一行并将其提供给自动化工具以传播到其他服务器，那么这是两全其美的方法。

— Monty Harder

启动脚本都没有帮助，并且脚本中有错误，因此无论哪种方式都需要空运行测试。

— mckenzm

@mckenzm同意，但是您可以申请的只有很多白痴证明：)

— Gargravarr

2

这确实是一个样式问题，因为操作系统提供了多种方法是有原因的。如果您不想使任何其他人（或一段时间不与系统打交道的人）感到困惑，请保持一致，不要混搭，如果很难看到整个主机上实际安排了哪些任务，以令人讨厌的惊喜结束。

— and子手
source

2

为了确保添加需要特定用户权限的cron作业，我个人使用以下命令：

 # crontab -u <user> -e

您也可以添加sudo。

就像@rackandboneman所说的那样，不需要弄乱/etc/cron.d/文件。如果有关用户的cron作业，请使用crontab命令的功能。

— 埃斯纳克
source

3

-1进行上述操作的最大缺点是，用户现在也可以修改/删除/破坏cronjob，当您作为管理员花费宝贵的时间进行设置时，通常这是不希望的...用户是服务帐户，并且该帐户已被锁定/过期，该服务将继续运行，但是锁定帐户的个人cron标签通常会被禁用。

— HBruijn

如果此处指定的用户是公共用户，例如公共终端服务环境的成员，那么您是对的。但是，如果此事与服务/代理的用户有关……再三考虑，则实际上与样式有关。

— aesnak