Скрипт работает вручную, но не при вызове Cron [дубликат]
На этот вопрос уже есть ответ здесь:
У меня давно работает cron, которое я хочу запустить @reboot. Я вызываю сценарий bash, который запускает два других сценария bash, используя crontab -e как root (безголовый ssh-компьютер). Кажется , что вторая строка сценария bash запущена, но не первая.
start.sh вызывает first.sh и second.sh . second.sh кажется запущенным, но first.sh - нет.
Я не могу понять, как узнать, что не так. Я добавил добавление вывода & >> в crontab, сценарий bash, который вызывает cron, и оба сценария bash, вызываемые первым сценарием. Все выходит пустым.
Я пробовал это , это , проверял системные журналы , пытался шпионить с помощью strace . Все, на что я смотрю, пусто . Все файлы & >> * .log пусты, strace ничего не возвращает для процессов, которые запущены , и я не могу найти работающий first.sh в любом диспетчере процессов.
ps aux | grep sh не показывает, что first.sh запущен.
Как мне сначала узнать почему.sh не запускается? Это исполняемый файл и работает нормально, когда я вхожу в систему и вызываю его с помощью терминала, но, кажется, ничего не происходит, когда я вызываю его с помощью cron. Даже вызов его напрямую из crontab -e ничего не дает. Те же результаты.
РЕДАКТИРОВАТЬ: Это было отмечено как возможная копия этого вопроса. Хотя это полезная информация, она не решила проблему. Та же проблема сохраняется с абсолютными путями в cron.
РЕДАКТИРОВАТЬ: включение сценариев синтаксических ошибок в соответствии с запросом комментария: crontab -e , ~ / startall.sh (Когда это выполняется, ~ / youtube .sh, кажется, пропускается, а ~ / copy.sh запускается), ~ / youtube.sh , ~ / youtube / run.sh
Когда я вызываю любой из них вручную, они Работа. Когда я вызываю их из crontab, даже напрямую, они не работают. ~ / copy.sh работает из crontab, остальные - нет.
2 ответа
Я не могу сказать, почему, но к сожалению иногда некоторые вещи не работают с @reboot задания крона (пример для такой проблемы). Чтобы доказать, является ли это причиной Вашей проблемы, можно создать регулярное задание крона и проверить, оно выполняется, как оно ожидается.
При испытании описанной проблемы можно воссоздать сценарий в некотором роде (поскольку в этом выполняют обеспеченный пример). Или можно попытаться выполнить сценарий во время запуска некоторым другим способом, например, через /etc/rc.local или единица systemd.
Ужасная идея прибыла ко мне - можно попытаться передать выполнение сценария к at команда в задании крона перезагрузки, что-то, таком как:
@reboot echo "/path/to/script.sh >> /path/to/the.log 2>&1" | at now
Или добавьте задержку ~1 минуты:
@reboot echo "/path/to/script.sh >> /path/to/the.log 2>&1" | at now + 1 minutes
Будет здорово, если это сделает задание :) Кроме того:
В
crontab, долина по умолчанию envvar$PATH/usr/bin:/bin. Для всех команд/сценариев, которые расположены за пределами этих каталогов, необходимо применить полный путь; Вы можетеexportновое$PATH, перед заданием; или даже можно использовать$(which my_command)вместо простоmy_command.Вы не должны вводить
shперед названием Вашего сценария, если: это - исполняемый файл; Вы используете полный путь; и первая строка файла является хижиной#!/bin/sh.
Точно так же, как steeldriver сказал, я думаю, что проблема с командой sh. Я отредактировал бы Ваши сценарии для удаления команд sh. Таким образом, если CD чтений сценария ~/filename/&& sh ~/filename/run.sh и>> ~/filename.sh.log затем удаляет команду sh после &&. Я также думал бы, что это - хорошая идея использовать полные пути также, но я вполне уверен проблема, которую Вы имеете, с командами sh во всех Ваших сценариях. Я открыл терминал и действовал, как будто я хотел открыть программу под названием Leafpad. Я ввел sh leafpad и получил ошибку, где, как будто я должен был просто ввести команду leafpad без команды sh затем, это запустит leafpad. При наличии sh перед командой Вы пытаетесь выполниться, Вы на самом деле выполняете команду с опцией, которая не существует, или по крайней мере именно это я верю, происходит.