Ubuntu rc local не работает

Как на Ubuntu 18.04 включить rc.local

Раньше ( Precise, Trusty ) я использовал конфигурационный файл rc.local дабы прописать путь до скриптов если хотел чтобы они запускались вместе с системой, а тут нужно было прописать запуск RocketChat , но на Ubuntu 18.04 Server такого файла нет. Как быть, может можно его вернуть . Вроде как можно, вот об этом и пойдет речь в текущей заметке.

Создаю файл сервиса:

$ sudo nano /etc/systemd/system/rc-local.service

$ sudo chmod +x /etc/rc.local

$ sudo systemctl enable rc-local

$ sudo systemctl start rc-local

$ sudo systemctl status rc-local | head -n5

● rc-local.service — /etc/rc.local Compatibility

Loaded: loaded (/etc/systemd/system/rc-local.service; enabled-runtime; vendor preset: enabled)

Active: active (exited) since Thu 2019-01-24 20:21:10 MSK; 9min ago

Создаю файл /etc/rc.local

$ sudo nano /etc/rc.local

$ sudo chmod +x /etc/rc.local

Включаю созданный сервис и запускаю:

$ sudo systemctl enable rc-local

Created symlink /etc/systemd/system/multi-user.target.wants/rc-local.service → /etc/systemd/system/rc-local.service.

$ sudo systemctl start rc-local.service

$ sudo systemctl status rc-local.service

● rc-local.service — /etc/rc.local Compatibility

Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset:

Active: active (exited) since Thu 2019-01-24 20:21:10 MSK; 7s ago

Process: 733 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)

Jan 24 20:21:10 srv-bionic systemd[1]: Starting /etc/rc.local Compatibility.

Jan 24 20:21:10 srv-bionic systemd[1]: Started /etc/rc.local Compatibility.

Теперь если мне что-либо нужно запустить вместе с системой, к примеру скрипт, мне остается только выше строки exit 0 прописать путь до скрипта и в момент когда система будет загружаться выполнится мой скрипт.

Проверяю, в конфигурационный файл /etc/rc.local добавляю

$ sudo nano /etc/rc.local

echo 1 > /tmp/user

На заметку: Файл сервиса также можно создать используя следующую команду:

$ sudo systemctl edit —full rc-local

Затем создаю также файл и добавляю ему атрибуты запуска, как выше, если бы делал все вручную.

$ sudo tee /etc/rc.local

Скрипт успешно отработал. Значит и моя строка запуска RocketChat также произведет запуск вместе с загрузкой системы как я и планировал. Пока считаю данную заметку выполненной, если что будет добавить я вернусь к ней. А пока на этом всё, с уважением автор блога Олло Александр aka ekzorchik.

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще 🙂

Карта МКБ: 4432-7300-2472-8059

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

[Решено]Не выполняется скрипт rc.local (странная ситуевина)

[Решено]Не выполняется скрипт rc.local

Сообщение ZugDuk » 16.10.2008 14:54

В моей ксубунте, автоматически не стартует скрипт rc.local
Точнее стартовать пытается, но пишет ошибку.

Идет загрузка, запускаются различные сервисы, самым последним в очереди, перед самым логином, идет rc.local
Выглядит он так.

Re: [Решено]Не выполняется скрипт rc.local

Сообщение blackdevil » 16.10.2008 19:42

Права на файл смотрели?

Re: [Решено]Не выполняется скрипт rc.local

Сообщение ZugDuk » 17.10.2008 09:32

Смотрел.
На /etc/rc.local
owner — rwx
group — rx
other — rx

На /etc/init.d/rc.local
owner — rwx
group — rx
other — rx

Видимо дело не в этом

Re: [Решено]Не выполняется скрипт rc.local

Сообщение rm_ » 17.10.2008 10:27

Источник

Почему rc.local не запускает все мои команды, и что я могу с этим поделать?

У меня есть следующее rc.local сценарий:

Первая строка, startup_script.sh на самом деле загружает script.sh подать в /script.sh упоминается в третьей строке.

К сожалению, похоже, что он не делает сценарий исполняемым или не запускает сценарий. Запуск rc.local файл вручную после запуска работает отлично. Может ли chmod не запускаться при запуске или что-то еще?

3 ответа

Вы можете полностью перейти к Быструю настройку, но это не обязательно лучший вариант. Поэтому я рекомендую сначала прочитать все это.

rc.local не терпит ошибок.

rc.local не предоставляет способ разумного восстановления после ошибок. Если какая-либо команда не выполняется, она останавливается. Первая строка, #!/bin/sh -e вызывает его выполнение в оболочке, вызываемой -e флаг. -e флаг — это то, что делает скрипт (в этом случае 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 , Это удалось! Как это может потерпеть неудачу?

Два значения успеха

Когда человек говорит, что команда выполнена успешно, это может означать две разные вещи:

1. Он сделал то, что хотел.
2. Сообщается, что это удалось.

И так для неудачи. Когда человек говорит, что команда не выполнена, это может означать:

1. Это не сделало то, что вы хотели.
2. Сообщается, что это не удалось.

Скрипт запускается с 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 на файл, который вы подозреваете, уже не существует, просто чтобы убедиться, что он удален.

Нечто подобное, вероятно, происходит в startup_script.sh , как раз перед тем, как он перестает работать. Последняя команда, выполняемая в сценарии, вероятно, сообщает о сбое (даже если его «сбой» может быть совершенно нормальным или даже необходимым), что приводит к сбою в сообщении сценария.

Тесты, предназначенные для провала

Одним из специальных видов команд является тест, под которым я подразумеваю команду, выполняемую для ее возвращаемого значения, а не для ее побочных эффектов. Таким образом, тест — это команда, которая запускается, чтобы можно было проверить ее состояние выхода (и выполнить действие).

Например, предположим, я забыл, если 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 Пересмотрено

Поскольку #! линия (см. также этот вопрос) в верхней части /etc/rc.local имеет 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, занимающихся сценариями оболочки, возникает большая путаница:

В сценариях оболочки:

1. Возвращаемое значение 0 означает успех и / или правда.
2. Возвращаемое значение чего-то кроме 0 означает неудачу и / или ложь.

В программировании на С:

1. Возвращаемое значение 0 означает ложь..
2. Возвращаемое значение чего-то кроме 0 значит правда.
3. Не существует простого правила, что означает успех, а что — неудача. Иногда 0 означает успех, в других случаях это означает неудачу, в других случаях это означает, что сумма двух только что добавленных вами чисел равна нулю. Возвращаемые значения в общем программировании используются, чтобы сигнализировать широкий спектр различных видов информации.
4. Числовой статус завершения программы должен указывать на успех или неудачу в соответствии с правилами для сценариев оболочки. То есть, хотя 0 означает false в вашей программе на C, вы все равно возвращаете свою программу 0 в качестве кода завершения, если вы хотите, чтобы он сообщал об успешном выполнении (которое оболочка затем интерпретирует как true).

Источник