скрипты в системе запуска rc.local

Question 1

Обнаружена странная проблема, сегодня я только что обновил Ubuntu с 17.04 по 17.10 и перезагрузил систему. Однако мой компьютер не может попасть на рабочий стол, кажется, что он заблокирован моим скриптом в /etc/rc.local. Сценарии вроде этого:

sslocal -c /home/kinka/azure.conf

И, комментируя скрипт, я могу нормально войти в свой Ubuntu. Кроме того, работает сценарий в фоновом режиме.

sslocal -c /home/kinka/azure.conf &

Я не знаю, что приводит к такому изменению?

Question 2

Основная причина заключается в том, что по своей природе она последовательна.

Что вам нужно понять, так это то, что /etc/rc.local существует для совместимости со старой системой инициализации SysV для воспитания служб, и SysV изначально начинался как последовательный системный путь назад в старые добрые времена AT & amp; T Unix. Как объясняет хаос в его ответе:

SysV выполняет сценарии в последовательном порядке, основываясь на их числе в имени файла. Systemd этого не делает. Если зависимости выполняются, systemd запускает сценарии немедленно, не соблюдая нумерацию имен скриптов.

Вторая причина заключается в том, что rc.local сам по себе является скриптом (заметила строку #!/bin/sh -e?). Скрипты по своей природе также являются последовательными, поэтому, если одна команда еще не закончила или не была помещена в фоновом режиме, сценарию придется ждать, пока программа A сделает свой mumbo jumbo или не сработает полностью, прежде чем что-либо еще может произойти. Кроме того, обратите внимание на комментарии в верхней части файла:

# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.

Таким образом, ваш sslocal -c /home/kinka/azure.conf просто удерживает системный заложник и не позволяет сценарию выйти и завершить загрузку системы. Вот и все.

Question 3

Question 4

Основная причина заключается в том, что по своей природе она последовательна.

Что вам нужно понять, так это то, что /etc/rc.local существует для совместимости со старой системой инициализации SysV для воспитания служб, и SysV изначально начинался как последовательный системный путь назад в старые добрые времена AT & amp; T Unix. Как объясняет хаос в его ответе:

SysV выполняет сценарии в последовательном порядке, основываясь на их числе в имени файла. Systemd этого не делает. Если зависимости выполняются, systemd запускает сценарии немедленно, не соблюдая нумерацию имен скриптов.

Вторая причина заключается в том, что rc.local сам по себе является скриптом (заметила строку #!/bin/sh -e?). Скрипты по своей природе также являются последовательными, поэтому, если одна команда еще не закончила или не была помещена в фоновом режиме, сценарию придется ждать, пока программа A сделает свой mumbo jumbo или не сработает полностью, прежде чем что-либо еще может произойти. Кроме того, обратите внимание на комментарии в верхней части файла:

# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.

Таким образом, ваш sslocal -c /home/kinka/azure.conf просто удерживает системный заложник и не позволяет сценарию выйти и завершить загрузку системы. Вот и все.

Question 5

Основная причина заключается в том, что по своей природе она последовательна.

Что вам нужно понять, так это то, что /etc/rc.local существует для совместимости со старой системой инициализации SysV для воспитания служб, и SysV изначально начинался как последовательный системный путь назад в старые добрые времена AT & amp; T Unix. Как объясняет хаос в его ответе:

SysV выполняет сценарии в последовательном порядке, основываясь на их числе в имени файла. Systemd этого не делает. Если зависимости выполняются, systemd запускает сценарии немедленно, не соблюдая нумерацию имен скриптов.

Вторая причина заключается в том, что rc.local сам по себе является скриптом (заметила строку #!/bin/sh -e?). Скрипты по своей природе также являются последовательными, поэтому, если одна команда еще не закончила или не была помещена в фоновом режиме, сценарию придется ждать, пока программа A сделает свой mumbo jumbo или не сработает полностью, прежде чем что-либо еще может произойти. Кроме того, обратите внимание на комментарии в верхней части файла:

# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.

Таким образом, ваш sslocal -c /home/kinka/azure.conf просто удерживает системный заложник и не позволяет сценарию выйти и завершить загрузку системы. Вот и все.

Sergiy Kolodyazhnyy · Accepted Answer · 22 May 2018 в 17:19

Основная причина заключается в том, что по своей природе она последовательна.

Что вам нужно понять, так это то, что /etc/rc.local существует для совместимости со старой системой инициализации SysV для воспитания служб, и SysV изначально начинался как последовательный системный путь назад в старые добрые времена AT & amp; T Unix. Как объясняет хаос в его ответе:

SysV выполняет сценарии в последовательном порядке, основываясь на их числе в имени файла. Systemd этого не делает. Если зависимости выполняются, systemd запускает сценарии немедленно, не соблюдая нумерацию имен скриптов.

Вторая причина заключается в том, что rc.local сам по себе является скриптом (заметила строку #!/bin/sh -e?). Скрипты по своей природе также являются последовательными, поэтому, если одна команда еще не закончила или не была помещена в фоновом режиме, сценарию придется ждать, пока программа A сделает свой mumbo jumbo или не сработает полностью, прежде чем что-либо еще может произойти. Кроме того, обратите внимание на комментарии в верхней части файла:

# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.

Таким образом, ваш sslocal -c /home/kinka/azure.conf просто удерживает системный заложник и не позволяет сценарию выйти и завершить загрузку системы. Вот и все.

Спасибо за ответ вашего пациента. Однако наиболее смущает то, что скрипт работает до ubuntu 17.04 , но блокирует загрузку в ubuntu 17.10 . Почему вышло такое перерыв? Может быть, это моя ошибка, если не использовать ее правильно. — Kinka, 22 October 2017 в 05:52
Поведение должно быть последовательным, поскольку rc.local является стандартным файлом, если только что-то не изменилось ни с вашего конца (скорее всего), так и с конца systemd. Я не буду глупо размышлять здесь. — Sergiy Kolodyazhnyy, 22 October 2017 в 07:11

Sergiy Kolodyazhnyy · Accepted Answer · 18 July 2018 в 04:54

Основная причина заключается в том, что по своей природе она последовательна.

Что вам нужно понять, так это то, что /etc/rc.local существует для совместимости со старой системой инициализации SysV для воспитания служб, и SysV изначально начинался как последовательный системный путь назад в старые добрые времена AT & amp; T Unix. Как объясняет хаос в его ответе:

SysV выполняет сценарии в последовательном порядке, основываясь на их числе в имени файла. Systemd этого не делает. Если зависимости выполняются, systemd запускает сценарии немедленно, не соблюдая нумерацию имен скриптов.

Вторая причина заключается в том, что rc.local сам по себе является скриптом (заметила строку #!/bin/sh -e?). Скрипты по своей природе также являются последовательными, поэтому, если одна команда еще не закончила или не была помещена в фоновом режиме, сценарию придется ждать, пока программа A сделает свой mumbo jumbo или не сработает полностью, прежде чем что-либо еще может произойти. Кроме того, обратите внимание на комментарии в верхней части файла:

# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.

Таким образом, ваш sslocal -c /home/kinka/azure.conf просто удерживает системный заложник и не позволяет сценарию выйти и завершить загрузку системы. Вот и все.

Sergiy Kolodyazhnyy · Accepted Answer · 24 July 2018 в 18:11

Основная причина заключается в том, что по своей природе она последовательна.

Что вам нужно понять, так это то, что /etc/rc.local существует для совместимости со старой системой инициализации SysV для воспитания служб, и SysV изначально начинался как последовательный системный путь назад в старые добрые времена AT & amp; T Unix. Как объясняет хаос в его ответе:

SysV выполняет сценарии в последовательном порядке, основываясь на их числе в имени файла. Systemd этого не делает. Если зависимости выполняются, systemd запускает сценарии немедленно, не соблюдая нумерацию имен скриптов.

Вторая причина заключается в том, что rc.local сам по себе является скриптом (заметила строку #!/bin/sh -e?). Скрипты по своей природе также являются последовательными, поэтому, если одна команда еще не закончила или не была помещена в фоновом режиме, сценарию придется ждать, пока программа A сделает свой mumbo jumbo или не сработает полностью, прежде чем что-либо еще может произойти. Кроме того, обратите внимание на комментарии в верхней части файла:

# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.

Таким образом, ваш sslocal -c /home/kinka/azure.conf просто удерживает системный заложник и не позволяет сценарию выйти и завершить загрузку системы. Вот и все.

скрипты в системе запуска rc.local

3 ответа

Другие вопросы по тегам:

Похожие вопросы: