Ubuntu rc local не работает
Обновлено: 06.07.2024
У меня есть одна команда в моем сценарии /etc/rc.local , который должен запустить демон обновления для Tiny Tiny RSS во время запуска, но сценарий не запускается во время запуска. Почему?
Весь файл /etc/rc.local:
/etc/rc.local является исполняемым:
/etc/init.d/rc.local существует и является исполняемым:
/etc/init.d/rc.local должен быть запущен при запуске для этого уровня выполнения:
Если я вручную вызываю /etc/rc.local из командной строки, то update_daemon загружается .
. который я должен помнить, чтобы делать каждый раз, когда мой сервер перезапускается, пока эта проблема не будет исправлена.
Аналогично вопросы уже , но до сих пор мне не удалось применить эту информацию в рамках моей конкретной проблемы.
Почему команда в rc.local не выполняется во время запуска?
Возможно, некоторые предварительные требования не выполняются при попытке запуска ваших команд при выполнении rc.local , поэтому выполнение вашей команды выходит из строя.
Я столкнулся с одним и тем же, когда вручную устанавливал регулятор cpu и не смог сделать это в rc.local . Вот мой способ обхода, который использует update-rc.d , чтобы ваши команды запускались при запуске:
Кроме того, вы можете проверить сценарии /etc/network/if-up.d и посмотреть, можете ли вы запускать свои команды при запуске сети.
попробуйте sudo sysv-rc-conf и проверьте, если rc.local включен
У нас была эта проблема на некоторых размещенных серверах, загружающих правила FW.
В этих боксах они перезагружаются ОЧЕНЬ быстро, и мы обнаружили, что просто помещаем «sleep 1» в rc.local, прежде чем инструкции по загрузке, похоже, исправят проблему. Я думаю, это дало немного времени для интерфейсов, чтобы решить, прежде чем загружать правила FW.
Убедитесь, что скрипт rc.local является исполняемым:
Затем включите его:
Перезагрузите систему или запустите сценарий вручную, выполнив:
Статус службы можно отобразить, выполнив:
У меня была аналогичная проблема в rc.local, не выполнявшаяся при запуске
sshades предоставили мне следующий ответ:
Ubuntu теперь использует systemd, а rc.local теперь считается сервисом, который по умолчанию отключен. Вы можете включить rc.local «on», введя следующую команду и перезагрузив ее:
хотя я не тестировал его решение, я думаю, что это звучит логично и будет работать. Однако:
Я также нашел решение, добавляющее скрипт к ./.config/autostart-scripts/, выполнит трюк
Я однажды отредактировал rc.local с помощью Блокнота в Windows, и у этой проблемы возникла такая проблема.
В этом случае использование текстового редактора поддерживает EOL Conversion, например Notepad ++, для преобразования стиля EOL в Unix, может решить его.
У меня есть одна команда в моем скрипте /etc/rc.local , которая должна запускать демон обновления для Tiny Tiny RSS во время запуска, но сценарий не выполняется во время запуска. Почему?
Весь файл /etc/rc.local:
/etc/rc.local является исполняемым:
/etc/init.d/rc.local существует и является исполняемым:
/etc/init.d/rc.local должен выполняться при запуске для этого уровня запуска:
Если я вручную вызываю /etc/rc.local из командной строки, загружается update_daemon. ..
. что я должен помнить каждый раз, когда мой сервер перезагружается, пока эта проблема не будет устранена.
Подобные вопросы уже уже существуют, но до сих пор я не смог применить информацию в рамках моей конкретной проблемы.
Почему команда в rc.local не выполняется во время запуска?
Необходимо убедиться, что /etc/rc.local выполняется во время запуска сервера с помощью команды:
sudo systemctl enable rc-local.service
Я однажды отредактировал rc.local с помощью Блокнота в Windows, и у него появилась эта проблема.
В этом случае использование текстового редактора с поддержкой преобразования EOL, например Notepad ++, для преобразования стиля EOL в «Unix» может решить эту проблему.
Вы также можете сделать это с помощью :set ff=unix в Vim.
У меня была похожая проблема в том, что rc.local не запускался при запуске.
sshades предоставил мне следующий ответ:
Ubuntu сейчас использует systemd, а rc.local теперь считается службой, которая по умолчанию отключена. Вы можете включить rc.local, введя следующую команду и перезагрузившись:
, хотя я не проверял его решение, я думаю, что это звучит логично и будет работать. Тем не менее:
Я также нашел решение, что добавление скрипта в ./.config/autostart-scripts/ сделает свое дело
У нас была эта проблема на некоторых хост-серверах, загружающих правила FW.
На этих полях они ОЧЕНЬ быстро перезагружаются, и мы обнаружили, что просто поместили «sleep 1» в rc.local до того, как операторы загрузки, похоже, решат проблему. Я думаю, что это дало немного времени для настройки интерфейсов перед загрузкой правил FW.
Убедитесь, что скрипт rc.local является исполняемым:
Затем включите его:
Перезагрузите систему или запустите скрипт вручную, выполнив:
Статус услуги можно отобразить, запустив:
Возможно, что некоторые условия не выполняются, когда вы пытаетесь выполнить ваши команды, когда происходит rc.local выполнение, поэтому выполнение вашей команды завершается неудачей.
Я столкнулся с тем же самым, когда вручную настраивал процессор и не делал этого в rc.local . Вот мой пользовательский обходной путь, который использует update-rc.d для запуска ваших команд при запуске:
Также, Вы можете проверить /etc/network/if-up.d сценарии и посмотреть, сможете ли вы запускать команды при запуске сети.
Первая строка, startup_script.sh на самом деле загружает script.sh подать в /script.sh упоминается в третьей строке.
К сожалению, похоже, что он не делает сценарий исполняемым или не запускает сценарий. Запуск rc.local файл вручную после запуска работает отлично. Может ли chmod не запускаться при запуске или что-то еще?
3 ответа
Вы можете полностью перейти к Быструю настройку, но это не обязательно лучший вариант. Поэтому я рекомендую сначала прочитать все это.
rc.local не терпит ошибок.
Ты хочешь rc.local вести себя так. Если команда не выполняется, вы не хотите, чтобы она продолжалась с другими командами запуска, которые могли бы полагаться на ее успешное выполнение.
Поэтому, если какая-либо команда завершится неудачно, последующие команды не будут выполняться. Проблема здесь в том, что /script.sh не запустился (не то, что это не удалось, см. ниже), поэтому, скорее всего, какая-то команда до того, как это не удалось Но какой?
Это было /bin/chmod +x /script.sh ?
chmod работает нормально в любое время. Предоставлена файловая система, которая содержит /bin был установлен, вы можете запустить /bin/chmod , А также /bin установлен раньше rc.local пробеги.
При запуске от имени пользователя root /bin/chmod редко терпит неудачу. Он потерпит неудачу, если файл, с которым он работает, доступен только для чтения, и может потерпеть неудачу, если файловая система, на которой он работает, не поддерживает разрешения. Здесь нет ничего вероятного.
Кстати, sh -e это единственная причина, по которой это будет на самом деле проблема, если chmod не удалось. Когда вы запускаете файл сценария, явно вызывая его интерпретатор, не имеет значения, помечен ли файл как исполняемый. Только если бы сказал /script.sh будет иметь значение исполняемый бит файла. Так как это говорит sh /script.sh нет (если конечно /script.sh вызывает себя во время работы, что может привести к сбою из-за того, что он не является исполняемым, но вряд ли он сам себя вызывает).
Так что же не удалось?
sh /home/incero/startup_script.sh не удалось. Почти наверняка.
Мы знаем, что он побежал, потому что он скачал /script.sh ,
(В противном случае было бы важно убедиться, что он работает, на случай, если /bin не было в PATH - rc.local не обязательно иметь то же самое PATH как у вас, когда вы вошли в систему. Если /bin не были в rc.local Путь, это потребует sh быть запущенным как /bin/sh , Так как это бежало, /bin в PATH Это означает, что вы можете запускать другие команды, расположенные в /bin без полной квалификации их имен. Например, вы можете просто запустить chmod скорее, чем /bin/chmod , Тем не менее, в соответствии с вашим стилем в rc.local Я использовал полные имена для всех команд, кроме sh всякий раз, когда я предлагаю вам запустить их.)
Мы можем быть уверены, /bin/chmod +x /script.sh никогда не бежал (или вы увидите, что /script.sh был выполнен). И мы знаем sh /script.sh тоже не бегал.
Но это скачано /script.sh , Это удалось! Как это может потерпеть неудачу?
Два значения успеха
Когда человек говорит, что команда выполнена успешно, это может означать две разные вещи:
- Он сделал то, что хотел.
- Сообщается, что это удалось.
И так для неудачи. Когда человек говорит, что команда не выполнена, это может означать:
- Это не сделало то, что вы хотели.
- Сообщается, что это не удалось.
Скрипт запускается с sh -e , лайк rc.local , прекратит запуск в первый раз, когда команда сообщит об ошибке. Не имеет значения, что на самом деле сделала команда.
Если вы не собираетесь startup_script.sh сообщить об ошибке, когда он делает то, что вы хотите, это ошибка в startup_script.sh ,
- Некоторые ошибки не позволяют скрипту делать то, что вы от него хотите. Они влияют на то, что программисты называют его побочными эффектами.
- А некоторые ошибки не позволяют скрипту правильно сообщать, успешно ли он выполнен. Они влияют на то, что программисты называют его возвращаемым значением (которое в этом случае является состоянием выхода).
Скорее всего, что startup_script.sh сделал все, что должен, кроме того, что сообщил, что не удалось.
Как сообщается об успехе или неудаче
Скрипт представляет собой список из нуля или более команд. Каждая команда имеет статус выхода. Предполагая, что нет никаких сбоев в фактическом запуске сценария (например, если интерпретатор не смог прочитать следующую строку сценария во время его выполнения), статус выхода сценария:
- 0 (успех), если скрипт был пустым (т.е. не имел команд).
- N , если скрипт завершился в результате выполнения команды exit N , где N это некоторый код выхода.
- Код выхода последней команды, которая выполнялась в скрипте, в противном случае.
Когда исполняемый файл запускается, он сообщает свой собственный код завершения - они не только для скриптов. (И технически коды выхода из скриптов - это коды выхода, возвращаемые оболочками, которые их запускают.)
Например, если программа на C заканчивается exit(0); , или же return 0; в его main() функция, код 0 предоставляется операционной системе, которая предоставляет ее вызывающему процессу (который может быть, например, оболочкой, из которой была запущена программа).
0 означает, что программа выполнена успешно. Любое другое число означает, что это не удалось. (Таким образом, разные цифры могут иногда указывать на разные причины сбоя программы.)
Команды, означающие сбой
Иногда вы запускаете программу с намерением, что она потерпит неудачу. В этих ситуациях вы можете думать о его неудаче как об успехе, даже если программа не сообщает об ошибке. Например, вы можете использовать rm на файл, который вы подозреваете, уже не существует, просто чтобы убедиться, что он удален.
Тесты, предназначенные для провала
Одним из специальных видов команд является тест, под которым я подразумеваю команду, выполняемую для ее возвращаемого значения, а не для ее побочных эффектов. Таким образом, тест - это команда, которая запускается, чтобы можно было проверить ее состояние выхода (и выполнить действие).
Например, предположим, я забыл, если 4 равно 5. К счастью, я знаю сценарии оболочки:
Здесь тест [ -eq 5 ] терпит неудачу, потому что получается 4 ≠ 5 в конце концов. Это не значит, что тест не был выполнен правильно; это сделал. Его работа состояла в том, чтобы проверить, если 4 = 5, затем сообщить об успехе, если так, и об ошибке, если нет.
Видите ли, в сценариях оболочки успех также может означать истину, а неудача также может означать ложь.
Хотя echo заявление никогда не выполняется, if блок в целом возвращает успех.
Тем не менее, предположил, что я написал это короче:
Это обычная стенография. && является логическим и оператором. && выражение, которое состоит из && с утверждениями с обеих сторон, возвращает false (ошибка), если обе стороны не возвращают true (успех). Так же, как и нормальный.
Если кто-то спросит вас: "Дерек пошел в торговый центр и подумал о бабочке?" и вы знаете, что Дерек не ходил в торговый центр, вам не нужно беспокоиться, если он подумает о бабочке.
Точно так же, если команда слева от && терпит неудачу (ложь), весь && выражение сразу терпит неудачу (ложь). Утверждение на правой стороне && никогда не запускается
Вот, [ 4 -eq 5 ] пробеги. Это "не удается" (возвращая ложь). Итак, весь && выражение терпит неудачу. echo "Yeah, they're totally the same." никогда не бежит. Все вело себя, как и должно быть, но эта команда сообщает об ошибке (хотя в противном случае эквивалент if условно выше сообщает об успехах).
Если бы это был последний оператор в сценарии (и сценарий дошел до него, а не завершился в какой-то момент до него), весь сценарий сообщал бы об ошибке.
Есть много тестов помимо этого. Например, есть тесты с || ("или же"). Однако приведенного выше примера должно быть достаточно, чтобы объяснить, что такое тесты, и дать вам возможность эффективно использовать документацию, чтобы определить, является ли конкретный оператор / команда тестом.
sh против sh -e Пересмотрено
В отличие от других ваших сценариев, таких как startup_script.sh беги без -e флаг:
Следовательно, они продолжают работать, даже если команда в них сообщает об ошибке.
Это нормально и хорошо. rc.local должен вызываться с sh -e и большинство других скриптов - в том числе большинство скриптов, запущенных rc.local --не следует.
Просто не забудьте запомнить разницу:
Скрипты запускаются с sh -e выходить из отчета об ошибке в первый раз, когда содержащаяся в нем команда выходит из отчета об ошибке.
Это как если бы скрипт представлял собой одну длинную команду, состоящую из всех команд в скрипте, соединенных с && операторы.
Скрипты запускаются с sh (без -e ) продолжайте работать, пока они не доберутся до команды, которая завершает (выходит из) их, или до самого конца сценария. Успех или неудача каждой команды по существу не имеет значения (если только следующая команда не проверит это). Сценарий завершается со статусом выхода последнего запуска команды.
Помогая вашему сценарию понять, что это не такая ошибка, в конце концов
Как вы можете не допустить, чтобы ваш сценарий думал, что он провалился, а когда нет?
Вы смотрите на то, что происходит непосредственно перед тем, как все закончится.
Если команда завершилась неудачно, когда она должна была быть выполнена, выясните причину и устраните проблему.
Если команда завершилась неудачно, и это было правильно, то предотвратите распространение этого статуса ошибки.
Один из способов предотвратить распространение состояния сбоя - запустить другую успешную команду. /bin/true не имеет побочных эффектов и сообщает об успехе (так же, как /bin/false ничего не делает и тоже терпит неудачу).
Другой - убедиться, что скрипт завершен exit 0 ,
Это не обязательно то же самое, что exit 0 находясь в конце сценария. Например, может быть if -Блок, где сценарий выходит внутри.
Лучше знать, что заставляет ваш скрипт сообщать о сбое, прежде чем сообщать об успехе. Если он действительно каким-то образом терпит неудачу (в смысле не выполнения того, что вы хотите, чтобы он делал), вы не хотите, чтобы он сообщал об успехе.
Быстрое исправление
Если вы не можете сделать startup_script.sh выйти из отчета об успехе, вы можете изменить команду в rc.local который запускает его, так что команда сообщает об успехе, хотя startup_script.sh не.
В настоящее время у вас есть:
Эта команда имеет те же побочные эффекты (т.е. побочный эффект запуска startup_script.sh ), но всегда сообщает об успехе:
Помни, лучше знать почему startup_script.sh сообщает о сбое и исправляет его.
Как работает Quick Fix
Это на самом деле пример || тест, тест или тест.
Предположим, вы спросили, вынул ли я мусор или почистил сову. Если я вынес мусор, я могу честно сказать "да", даже если я не помню, чистил ли я сову или нет.
Команда слева от || пробеги. Если это удастся (правда), то правая сторона не должна бежать. Так что если startup_script.sh сообщает об успехе, true Команда никогда не запускается.
Однако если startup_script.sh сообщает о сбое [я не вывез мусор], а затем результат /bin/true [если я почистил сову] имеет значение.
/bin/true всегда возвращает успех (или истина, как мы иногда называем это). Следовательно, вся команда завершается успешно, и следующая команда в rc.local может бежать.
Дополнительное примечание об успехе / неудаче, истина / ложь, ноль / ненулевое значение.
Не стесняйтесь игнорировать это. Возможно, вы захотите прочитать это, если вы программируете на более чем одном языке (то есть, не только в сценариях оболочки).
Для создателей сценариев оболочки, использующих такие языки программирования, как C, и для программистов на C, занимающихся сценариями оболочки, возникает большая путаница:
Рассмотрим два варианта автозагрузки программ или скриптов в Ubuntu. Через графический интерфейс и с использованием файла rc.local. В предыдущих версиях автозагрузка в Ubuntu работала именно через файл rc.local, однако в последних версиях её отключили. Мы включим данную возможность.
Автозагрузка через графический интерфейс
Автозагрузка через графический интерфейс настраивается в приложении Startup Application. Заходим в приложения (пункт 1) и запускаем Startup Application (пункт 2)
Появится окно программы, где можно добавить, удалить или изменить текущие программы запускаемые при старте системы.
Нажимаем Add для добавления программы в автозагрузку. Пишем название программы и указываем путь к ней. Для теста я добавил в автозагрузку игру mahjongg.
Нажимаем Save и перезагружаем компьютер. Игра Mahjongg должна запуститься при входе в систему.
Как включить rc.local
Создаем файл rc.local
Добавляем в него содержимое:
Делаем файл исполняемым:
Включение rc.local в автозагрузку
Теперь добавляем свой скрипт либо сервис до строчки exit 0 . Я для теста добавлю команду создания папки в директории tmp
Сохраняем файл и перезагружаемся. При старте системы будет создана папка testdir в /tmp/
Про автозагрузку в Ubuntu я записал видео с примерами по каждому из способов.
Читайте также: