1

如果我以 root 身份从 运行脚本/home/<user>/<dir>/script.sh,则 cron 运行良好。但是如果我从(再次以 root 身份)运行脚本/root/<dir>/script.sh,cron 似乎不起作用。

4

5 回答 5

3

过去在使用“cron”时与各种默认的 $PATH 发生冲突,我总是为每个可执行文件和每个目标文件拼写完整的绝对 $PATH。我总是假设“cron”没有设置 $PATH 并且没有当前工作目录。

换句话说,不要使用类似的命令

       "myprocess  abc*.txt"

但要完整地做

        "/usr/localbin/myprocess    /home/jvs/abc*.txt".

或者,创建一个 bash 脚本来完成这项工作,并使用完整的绝对路径调用该 bash 脚本,例如

       "/usr/local/bin/myprocess_abc_txts".

如果您需要在脚本中有一些灵活性,请使用在您使用“cron”调用的 bash 脚本中专门设置的环境变量。

于 2009-03-01T06:30:26.907 回答
2

我认为您需要添加更多信息。我猜这是一个权限问题。在您的 crontab 中添加文件、目录和行的权限,以便我们提供帮助。另外,如果你把它放在 /root 中,你是在 root 的 crontab 中运行它吗?

于 2009-02-28T21:46:48.773 回答
2

记住环境——尤其是当由cron而不是由 root 运行时。当 cron 运行某些东西时,您的环境可能没有太多设置,这与您通过at. 也不清楚您当前的目录是什么。因此,对于将由 运行的命令cron,请使用脚本(正如您已经在做的那样)并确保它设置了足够的环境以使其运行。并确保您的环境设置代码不是交互式的!

在我的机器上,我有一个机制使得 cron 条目读取(例如):

23 1 * * 1-5 /usr/bin/ksh /work1/jleffler/bin/Cron/weekday

目录中的weekday脚本Cron是一个标准脚本的链接,它首先设置环境,然后运行命令/work1/jleffler/bin/weekday(在这种情况下 - 它使用命令的名称来确定要运行的内容)。

目录中的实际脚本Cron是:

:       "$Id: runcron.sh,v 2.1 2001/02/27 00:53:22 jleffler Exp $"
#
#       Commands to be performed by Cron (no debugging options)

#       Set environment -- not done by cron (usually switches HOME)
. $HOME/.cronfile

base=`basename $0`
cmd=${REAL_HOME:-/real/home}/bin/$base

if [ ! -x $cmd ]
then cmd=${HOME}/bin/$base
fi

exec $cmd ${@:+"$@"}

我已经使用了一段时间了——这个版本是从 2001 年开始的——它对我来说是一种享受。我正在使用的基本(Sun Solaris 10)实现cron;其他平台上的新版本中可能会有新功能,cron从而使其中一些变得不必要。(这些$REAL_HOME东西是我的怪事;假装它说$HOME- 尽管这使得某些脚本对你来说是不必要的。).cronfile负责环境设置 - 它做了很多,但这是我的问题,而不是你的问题。

于 2009-02-28T22:20:11.767 回答
0

运行 sh 脚本的另一种方法是将 bash 脚本放在/usr/bin目录中,只需运行命令bash yourscript.sh而不添加/usr/bin/目录

于 2012-10-03T07:47:56.107 回答
0

这可能是因为您正在寻找脚本中的相对目录/文件,这些目录/文件在从 /home/ 运行而不是从 /root 运行时位于,因为 /root 不在 /home/root 中,也不会看起来像用户主文件夹在家/

你能检查一下它是否在寻找相关文件,或者发布脚本吗?

另一方面,您为什么不将其设置为从用户的主文件夹运行呢?

于 2009-02-28T21:49:24.663 回答