Назад | Перейти на главную страницу

код bash в rc.local не выполняется после загрузки

Кто-нибудь знает, почему система не выполняет код сценария в rc.local при загрузке? У меня есть сценарий bash после настройки, который я хочу запустить после начальной установки VMware ESX (Red Hat), и по какой-то причине он не запускается. У меня есть настройка, чтобы регистрировать начало выполнения и даже его прогресс, чтобы я мог видеть, как далеко он продвинется, если в какой-то момент он выйдет из строя, но даже когда я смотрю этот журнал, я обнаруживаю, что он даже не запустил выполнение кода скрипта. Я уже проверил, есть ли у скрипта разрешения на выполнение (755), на что еще мне обратить внимание?

Вот несколько первых строк моего кода:

#!/bin/sh
echo >> /tmp/configLog ""
echo >> /tmp/configLog "Entering maintenance mode"

Итак, существует ли / tmp / configLog? Если да, то ваш скрипт запускается и просто где-то умирает.

Начнем с основ:

  1. Поместите простой однострочный файл в /etc/rc.local, вот так. 
    touch /tmp/itworked
    Это сработало? После перезагрузки существует ли / tmp / itworked? Если да, то выполняется rc.local.
  2. Еще одна распространенная проблема заключается в том, что если ваш скрипт является демоном, ему либо нужно обрабатывать разветвление в фоновом режиме, либо его нужно использовать в rc.local. Если ваш скрипт - / bin / myscript, тогда rc.local должен иметь:
    /bin/myscript &
    в этом. Долго ли бежит? Где-то в сценариях инициализации может быть тайм-аут, чтобы пользователи не могли остановить процесс загрузки - фоновый процесс поможет вам обойти это, если он существует.
  3. Если «прикосновение» работает, и вы работаете в фоновом режиме, это должно быть где-то в вашем скрипте. Что он делает, когда вы бежите 
    /bin/sh /etc/rc.local
    из командной строки?
  4. Как сказал Джейсон, проверьте dmesg, а также / var / log / messages на наличие каких-либо подсказок.
  5. Когда скрипт запускается из rc.local, он не будет иметь полного набора переменных среды, который имеет ваш пользователь root при входе в систему - например, $ PATH может быть другим. Не полагайтесь на $ PATH. Вы также можете протестировать свой сценарий, запланировав задание «на», которое будет приближено к моделированию среды.

Не уверен, является ли обработка сценариев инициализации в Linux последовательной или параллельной, но системы Solaris запускают сценарии последовательно. Если более ранний сценарий инициализации еще не завершен (иногда я вижу это из-за зависимости sendmail / DNS), более поздние запускаются не так быстро, как вы предполагали.

Используйте ps, чтобы увидеть, работает ли еще более ранний сценарий инициализации.

Вы уверены, что ваша система поддерживает rc.local? Если это не задокументировано, вам нужно будет выполнить все сценарии инициализации. Вы начинаете с / etc / inittab. (Вы можете обнаружить, что оттуда вы перейдете в /etc/rc.d/rc)

В некоторых системах /etc/rc.d/rc.local поддерживается через символическую ссылку /etc/rc.d/rcX.d/S99local. (где X - соответствующий уровень выполнения).

Если вы используете RedHat, нет реальной причины не создавать свой собственный сценарий инициализации, добавьте его в /etc/rc.d/init.d, chkconfig --add script и chkconfig в сценарий. Это сделает правильные символические ссылки в каталогах /etc/rc.d/rcX.d и упростит развертывание или отключение сценариев инициализации.

Использование устаревшего rc.local прекрасно для быстрого взлома, если ваша система поддерживает его, но это не совсем подходит для чего-то важного или постоянного.

Это не такая простая опечатка, не так ли? Если это:

#!/bin/hash

Действительно быть:

#!/bin/bash

?

(Как сказал CK в комментарии, теперь, когда я смотрю)

Возможно, в скрипте rc.local есть синтаксическая ошибка. Если вы попытаетесь вручную запустить его из командной строки после загрузки системы, он будет работать правильно?

Вы проверяли права доступа к каталогу, содержащему файл rc.local?

Разве ваш код не должен выглядеть так? Здесь 3 изменения:

#!/bin/bash
echo "" >> /tmp/configLog
echo "Entering maintenance mode" >> /tmp/configLog

rc.local был способом BSD для запуска сценариев запуска. Хотя многие версии Linux действительно поддерживают наличие файла с именем «rc.local», который запускается при запуске, насколько я помню, для работы для этого требовалось множество символических ссылок и другого связующего звена, поскольку Linux следовала методу Solaris в обработке сценариев запуска.

SELinux.

Попробуйте getenforce, чтобы увидеть, включен ли selinux. Он вернет 1 или принудительно, если он включен. Затем проверьте dmesg, чтобы увидеть, есть ли ошибка, связанная с selinux, которая, похоже, может быть связана с вашим скриптом.

Если в первой строке действительно написано #! / Bin / hash, вы получите сообщение об ошибке, подобное этой:

-bash: ./test.sh: /bin/hash: bad interpreter: No such file or directory

когда он бежит.

Вы также можете проверить, есть ли у сценария разрешения на выполнение.