可以在一个cron工作中使用upstart的"服务开始"吗?

Irv*_*van 6 linux cron upstart

TLDR ; 是否可以创建运行service service_name start的cron作业?怎么样?

我的内容

sudo crontab -e
Run Code Online (Sandbox Code Playgroud)

是:

45 23 * * * service bormarise_celery_daemon start
Run Code Online (Sandbox Code Playgroud)

这在终端上以root或服务器正常运行:

service bormarise_celery_daemon start
start: Job is already running: bormarise_celery_daemon
Run Code Online (Sandbox Code Playgroud)

但是cron反而给出了以下错误:

bormarise_celery_daemon: unrecognized service
Run Code Online (Sandbox Code Playgroud)

cyf*_*r01 13

TL;博士

您需要添加/sbin到cron,PATH以便service脚本可以找到initctl.为此,请将此类定义添加到crontab的顶部:

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
Run Code Online (Sandbox Code Playgroud)

如果您尝试启动的作业已在运行,则退出状态为1(失败),您可能仍会遇到cron向您发送电子邮件的问题initctl.你可以通过以下方式解决这个问题:

45 23 * * * service bormarise_celery_daemon status | grep -q running || service bormarise_celery_daemon start
Run Code Online (Sandbox Code Playgroud)

尽管有点长,但如果bormarise_celery_daemon服务没有运行,它应该只尝试运行start命令.

service vs initctl

虽然service命令做出尝试管理工作新贵,它不是实际的新贵控制功能-这将是initctl和短手命令的相关套件(,start,stop,).所有Upstart脚本都驻留在/sbin/.

service命令试图促进人们在Upstart和经典SysV样式脚本之间传播服务.这样,您可以使用一个界面(service脚本)来管理来自两个系统的服务.

深入研究服务脚本

如果你service在Ubuntu 14.04上浏览脚本的实际源代码(它只是一个Bash脚本),你会看到:

if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null \
   && initctl version | grep -q upstart
then
   # Upstart configuration exists for this job and we're running on upstart
   case "${ACTION}" in
      start|stop|status|reload)
         # Action is a valid upstart action
         exec ${ACTION} ${SERVICE} ${OPTIONS}
      ;;
      restart)
         # Map restart to the usual sysvinit behavior.
         stop ${SERVICE} ${OPTIONS} || :
         exec start ${SERVICE} ${OPTIONS}
      ;;
      force-reload)
         # Upstart just uses reload for force-reload
         exec reload ${SERVICE} ${OPTIONS}
      ;;
   esac
fi
Run Code Online (Sandbox Code Playgroud)

开放条件:

  1. 检查您指定的服务(在您的情况下bormarise_celery_daemon:)是否为Upstart作业.新贵工作进入/etc/init/.conf扩展.
  2. 如果是,service脚本将检查它是否可以运行initctl.
  3. 如果可以,service脚本将确保这initctl是一个足够新的版本.

如果所有这些都是真的,那么service脚本将尝试使用适当的initctl命令来运行Upstart作业.例如:

service bormarise_celery_daemon start
Run Code Online (Sandbox Code Playgroud)

翻译成:

start bormarise_celery_daemon
Run Code Online (Sandbox Code Playgroud)

这基本上相当于:

initctl start bormarise_celery_daemon
Run Code Online (Sandbox Code Playgroud)

但是,如果这些条件中的任何一个不成立,则service脚本假定您正在尝试运行SysV样式的脚本.这些只是位于的Bash脚本/etc/init.d/.但是,如果不存在此类脚本,它将退出并显示unrecognized service错误消息.

把碎片放在一起

PATHcron 的默认值仅包含/bin//usr/bin/.这意味着它不包括可执行文件/sbin/所在的initctl位置.这意味着cron无法运行initctl.

cron运行你的crontab中,service脚本能找到你新贵工作,但它是能够运行的initctl命令,所以它跳过尝试通过新贵(运行服务,即,initctl).相反,它然后尝试在中查找SysV样式的脚本/etc/init.d/.由于该脚本不存在,service脚本会放弃并打印您的错误消息.

如果用一个包含的覆盖cron默认值,则脚本将能够找到并尝试启动Upstart作业.PATH/sbin/serviceinitctl


有趣的是,在Ubuntu 12.04上,service脚本只检查是否存在Upstart作业,省略两项initctl检查.这意味着如果你在Ubuntu 12.04上尝试这个,它会尝试使用Upstart来启动你的服务.但是,如果/sbin/不在路径上,它将失败并显示(稍微)更容易理解的错误消息:

/usr/bin/service: 123: exec: start: not found
Run Code Online (Sandbox Code Playgroud)