我正在尝试运行at
bash命令,但它不起作用。我可以向队列中添加作业,但到了时间后作业不运行。我做错了什么?
hpek@melda:~$ cat /usr/lib/cron/at.deny
hpek@melda:~$ atq
hpek@melda:~$ at now +2 minutes
echo TTTEEEST
job 12 at Sun May 6 02:09:00 2012
hpek@melda:~$ date
Sun May 6 02:10:24 CEST 2012
hpek@melda:~$ atq
12 Sun May 6 02:09:00 2012
hpek@melda:~$
UPD2021.08.06 atd已在MacOS 11.5.2(或更早版本)中删除
$ sudo find / -name atd -print 2>/dev/null
$
7条答案
按热度按时间jw5wzhpr1#
它运行得很好,只是用
at
运行的命令没有将它们的输出写到你调用它的终端。请尝试:
您将在两分钟后看到该文件。
mqxuamgl2#
看一下
/var/at/jobs
,看看你的at作业是否列在那里。(根据操作系统的不同,它可能是一个不同的目录)。默认情况下,
at
在大多数系统上是不启用的。为了使at
作业真正得到执行,必须执行atrun命令。此命令通过launchd或cron执行,具体取决于系统。
具体的机制因系统而异,因此您必须阅读有关
at
、atrun
等的所有联机帮助页,以验证您的系统上是否真的启用了at
,以及您是否具有运行at作业的权限。因此您需要同时选中这两个选项。您必须同时在 * allow * 文件中,并且不在 deny 文件中。最重要的是,您必须确保
at
甚至在您的系统上被启用(出于安全考虑,它通常被禁用)。niknxzdl3#
检查您的邮件:
zf9nrax14#
我找到了这个here
首先,使用如下命令确保at守护进程正在运行:
如果没有看到atd正在运行,请使用以下命令启动它:
r8uurelv5#
为了分析(d)处的执行问题,以下做法可能会有所帮助:
1.检查/etc/at.allow和/etc/at.deny是否存在和内容(请参阅
man at.allow
)1.检查atd假脱机目录(/var/spool/cron/atjobs,daemon:daemon,Ubuntu上为770)的所有者和访问权限
1.检查atd守护程序是否正在运行(Ubuntu上的
systemctrl -a | grep atd
)tail -f /var/log/syslog
(在执行时)journalctl -b | grep atd
(发现here,包含进一步的提示)“Permission denied”错误也可能是由于/etc/security/limits. conf中定义的登录次数有限(对于
at
运行用户)造成的。jgwigjjp6#
当使用
at
命令时,我也遇到了同样的echo问题。但是如果你尝试使用>
或>>
来重定向输出,那么它会很好地工作。也可以尝试一些其他的系统命令,如reboot
,ls > some_text_file
等,以确保at命令是工作的。或者尝试sudo systemctl enable --now atd
来启用at
守护进程weylhg0b7#
第一个结论:
atrun
或atd
守护程序未运行,从而导致此问题。解决案例的指导原则:
1.首先通过
man at
检查at
mannul。在我的例子中,我(macos 10.13.6)找到了以下信息:1.通过
man atrun
检查atrun
手册,发现:atrun实用程序运行由at(1)排队的命令。它由launchd(8)定期调用,如com.apple.atrun.plist属性列表中所指定的。默认情况下,属性列表包含设置为true的Disabled键,因此不会调用atrun。
1.以root身份执行以下命令以启用atrun:
launchctl load -w /System/Library/LaunchDaemons/com.apple.atrun.plist