У меня есть скрипт, который запускается, когда сервер (Ubuntu 14.04) загружается с помощью @reboot в crontab (Под пользователем root)
@reboot /bin/bash /root/init.sh >> /var/logs/vminit.log
Скрипт запускает несколько вещей, но когда он достигает этой линии
ifdown eth1
Скрипт завершается, а ifdown
не запускается. (Запуск ifconfig
по-прежнему показывает eth1 в выходных данных) Включение подробного режима на ifdown
тоже ничего не возвращает.
Если я сам запускаю скрипт, он запускается, как и ожидалось.
Я написал тестовый скрипт, чтобы исключить любые проблемы с init.sh
#!/bin/bash
echo 'one'
ifdown eth1
echo 'two'
Если я запустил его вручную, я получу этот вывод (что ожидается)
one
<DHCP Client info>
two
Если я помещу этот тестовый скрипт в crontab для запуска с @reboot
, я получу те же результаты, что и init.sh
, и получу результат:
one
Я протестировал, запустив cron в точное время (пример: 25 14 * * *
), чтобы увидеть, если что-то с `@reboot ', но не повезло.
Я также пытался задержать запуск скрипта после загрузки, если что-то блокировало запуск ifdown
@reboot /bin/sleep 60; /bin/bash /root/init.sh >> /var/log/vminit.log
Несколько замечаний: - Eth1 - активный интерфейс, до запуска ifdown скрипт делает вызов из eth1, чтобы получить файл успешно. - Сценарий запускается от имени пользователя root - Права доступа к сценарию (и журналу) в порядке. - Запуск init.sh
или тестовый сценарий выполняется вручную, как и ожидалось.
На самом деле я не знаю, почему ifdown
не работает с crontab.
Во всяком случае, я сталкивался с той же ситуацией давным-давно и у меня есть обходное решение, надеюсь, это поможет вам.
Заменить
ifdown eth1
на
/sbin/ifconfig eth1 down 1> /dev/null
Это сработало для меня.
Даже если Вы используете wpa_cli в качестве задания крона, необходимо обеспечить полный путь как так:
/sbin/wpa_cli -i eth1 reconfigure
This работало для меня, когда я использую ifup или ifdown в crons:
apt-get install ifupdown
ifdown
местоположение: which ifdown
#!/bin/bash
echo 'one'
/sbin/ifdown eth1
echo 'two'