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 回答