TLDR ;是否可以创建运行 service 的cron作业 service_name 开始？怎么样？
我的内容
sudo crontab -e
是：
45 23 * * * service bormarise_celery_daemon start
这在终端上以root或服务器正常运行：
service bormarise_celery_daemon start
start: Job is already running: bormarise_celery_daemon
但是cron反而给出了以下错误：
bormarise_celery_daemon: unrecognized service
答案 0 :(得分：13)
您需要将/sbin添加到cron的PATH，以便service脚本可以找到initctl。为此，请将此类定义添加到crontab的顶部：
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
如果您尝试启动的作业已在运行，则cron以initctl退出，状态为1（失败）后，您可能仍会遇到问题。45 23 * * * service bormarise_celery_daemon status | grep -q running || service bormarise_celery_daemon start
你可以通过以下方式解决这个问题：
bormarise_celery_daemon尽管有点长，但如果service服务没有运行，它应该只尝试运行启动命令。
虽然initctl命令尝试管理Upstart作业，但它不是实际的Upstart控制功能 - 即start和相关的简写命令套件（即，stop，/sbin/，等。）。所有Upstart脚本都位于service。
service命令试图促进人们在Upstart和经典SysV样式脚本之间传播服务。这样，您可以使用一个接口（service脚本）来管理来自两个系统的服务。
如果你在Ubuntu 14.04上浏览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
脚本的实际来源（它只是一个Bash脚本），你会看到：
bormarise_celery_daemon开场条件：
/etc/init/）是否为Upstart作业。新贵作业将.conf扩展为service。initctl脚本将检查它是否可以运行service。initctl脚本将确保service是一个足够新的版本。如果所有这些都成立，那么initctl脚本将尝试使用适当的service bormarise_celery_daemon start
命令来运行Upstart作业。例如：
start bormarise_celery_daemon
转换为：
initctl start bormarise_celery_daemon
（基本上）等同于：
service 但是，如果其中任何一个条件不成立，/etc/init.d/脚本会假定您正在尝试运行SysV样式的脚本。这些只是unrecognized service中的Bash脚本。但是，如果不存在此类脚本，则它将以PATH错误消息退出。
cron的默认/bin/仅包含/usr/bin/和/sbin/。这意味着它不包含initctl cron可执行文件所在的位置。 这意味着initctl将无法投放cron。
当service运行您的crontab时，initctl脚本 能够找到您的Upstart作业，但是不能够运行initctl命令，因此它会跳过尝试通过Upstart运行您的服务（ ie ，/etc/init.d/）。相反，它会尝试在service中查找SysV样式的脚本。由于该脚本不存在，cron脚本会放弃并打印您的错误消息。
如果您使用PATH覆盖/sbin/的默认service，那么initctl脚本将能够找到service和将尝试启动您的Upstart工作。
有趣的是，在Ubuntu 12.04上，initctl脚本仅检查是否存在Upstart作业，省略/sbin/次检查。这意味着如果你在Ubuntu 12.04上尝试这个，它会尝试使用Upstart来启动你的服务。但是，如果/usr/bin/service: 123: exec: start: not found
不在路径上，则会失败并显示（稍微）更清晰的错误消息：
SharedPreferences