Я создал cronjob следующим образом, чтобы запустить скрипт.
Вот сценарий,
#!/bin/bash
service=influxdb
if (( $(ps -ef | grep -v grep | grep $service | wc -l) > 0 ))
then
echo "$service is running!!!"
else
service $service start
fi
Я создал такое задание cron,
alphauser@AlphaServer:~$ sudo crontab -e
И затем добавила эту строку
* * * * * bash /home/alphauser/influx-start.sh > /home/alphauser/output-influx-start.txt
Я сохранил вывод в файле, чтобы проверить его вывод.
Служба остановилась, и теперь настало время для cron показать ее магия. Но он не смог запустить службу. Я видел выходной файл, и это было написано в этом,
Starting influxdb...
influxdb process was unable to start [ FAILED ]
, после чего я удалил эту cronjob с помощью sudo crontab -r.
Я добавил эту строку в конец etc/crontab, т. е.
* * * * * root bash /home/alphauser/influx-start.sh > /home/alphauser/outputinflux.txt
, и это сработало. Служба была запущена, и это был результат,
influxdb is running!!!
Я хочу знать, почему сбой [9], но он работал с файлом etc/crontab.
Аутентификация sudo не может быть проблемой, потому что я добавил его в sudo crontab и случайно, если бы это было так, он сказал бы You must be root to run this script.
Как заметил @steeldriver: команда service не работает, потому что она не находится в пути crontab. Даже в качестве корневых заданий crontab выполняется в среде, которая довольно ограничена с точки зрения переменных окружения. Вам нужно включить полный путь для многих исполняемых файлов в команде, которая должна выполняться cron.
В этом случае
/usr/sbin/service $service start
работал бы. Откуда мы знаем, что такое точный путь к исполняемому файлу? Сделайте which service, и он ответит /usr/sbin/service.
Однако команда service выходит и заменяется эквивалентом systemd systemctl. Вы выполнили systemctl start $service в команде терминала. Даже без sudo, systemctl выяснит, что он не работает от имени root, и попросите пароль sudo.
В crontab вы должны использовать полный путь к systemctl
Итак, если вы используете
/bin/systemctl start $service
, он должен работать.
Как заметил @steeldriver: команда service не работает, потому что она не находится в пути crontab. Даже в качестве корневых заданий crontab выполняется в среде, которая довольно ограничена с точки зрения переменных окружения. Вам нужно включить полный путь для многих исполняемых файлов в команде, которая должна выполняться cron.
В этом случае
/usr/sbin/service $service start
работал бы. Откуда мы знаем, что такое точный путь к исполняемому файлу? Сделайте which service, и он ответит /usr/sbin/service.
Однако команда service выходит и заменяется эквивалентом systemd systemctl. Вы выполнили systemctl start $service в команде терминала. Даже без sudo, systemctl выяснит, что он не работает от имени root, и попросите пароль sudo.
В crontab вы должны использовать полный путь к systemctl
Итак, если вы используете
/bin/systemctl start $service
, он должен работать.
Как заметил @steeldriver: команда service не работает, потому что она не находится в пути crontab. Даже в качестве корневых заданий crontab выполняется в среде, которая довольно ограничена с точки зрения переменных окружения. Вам нужно включить полный путь для многих исполняемых файлов в команде, которая должна выполняться cron.
В этом случае
/usr/sbin/service $service start
работал бы. Откуда мы знаем, что такое точный путь к исполняемому файлу? Сделайте which service, и он ответит /usr/sbin/service.
Однако команда service выходит и заменяется эквивалентом systemd systemctl. Вы выполнили systemctl start $service в команде терминала. Даже без sudo, systemctl выяснит, что он не работает от имени root, и попросите пароль sudo.
В crontab вы должны использовать полный путь к systemctl
Итак, если вы используете
/bin/systemctl start $service
, он должен работать.