При выполнении к уровню выполнения это выполняет предыдущие уровни выполнения?
Существует подсказка в sudo страница справочника, которая объясняет, как сделать что-то вроде этого. Вот моя острота:
#!/usr/bin/bash
sudo sh -c "echo \"add this line to the code\" >> fileName"
Очевидно, необходимо будет сначала настроить пользователя, чтобы иметь sudo полномочия. sh оболочка привыкла из-за перенаправления к корневому файлу. Я также должен был выйти из кавычек, используемых для echo команда.
При переключении runlevel единственными выполняемыми вещами являются сценарии в /etc/rc.d/rc${NEW_LEVEL}.d/.
Это означает, что Вы правы: Каждый rc*.d каталог должен смочь обработать все изменения процесса/сервиса при переключении от другого runlevel. Таким образом, каждый емкостно-резистивный каталог содержит полный набор сценариев для достижения этого runlevel.
Скажите, что Вы переключаетесь на runlevel 3. /etc/rc.d/rc3.d/K* сценарии попытаются уничтожить любые процессы, которые работали в том, чем Ваш предыдущий runlevel был (могло быть любое число), и /etc/rc.d/rc3.d/S* сценарии запустят любые процессы, которые должны быть запущены (и не были уже запущены в предыдущем runlevel).
Очевидно, управление всеми этими символьными ссылками было бы реальной болью, таким образом, существуют утилиты, чтобы помочь управлять этим. На Debian и Ubuntu (по крайней мере, возможно, другие), можно использовать update-rc.d выборочно позволять/запрещать сценарии, найденные в /etc/init.d, или установить их до "значения по умолчанию" или рекомендуемых настроек для каждого сценария. Это создаст и обновит все символьные ссылки для Вас, для отражения любых изменений конфигурации, которые Вы хотите поместить на месте. На CentOS я понимаю, что можно использовать ntsysv или chkconfig сделать то же самое.
Эффективно, Вы никогда не касаетесь файлов в /etc/rc*.d/ (или /etc/rc.d/rc*.d/) самостоятельно; Вы всегда используете инструмент (например. update-rc.d, ntsysv, chkconfig) вносить любые изменения.
Если я говорю моей системе переходить к уровню выполнения 3, который означает, что это сначала пробегает уровень выполнения 0, 1, 2 и затем наконец пробегает уровень выполнения 3?
Нет, это не делает. Runlevels не последовательны тем способом.
Рассматриваемый вопрос: runlevel 0 обычно является "завершением работы" runlevel, который останавливает все сервисы и в конечном счете останавливается (и возможно выключается), система. Не было бы очень хорошо, если бы, для получения до полностью рабочей системы, init сначала вошел в runlevel 0.
Тем не менее во время процесса начальной загрузки обычно существует прогрессия. Ядро инициализирует в runlevel 1, затем передает управление к init, который обычно настраивается таким способом, которым это входит в runlevel 2 (многопользовательский, не объединяясь в сеть) сопровождаемый runlevel 3 (полностью операционный текстовый режим) и возможно runlevel 5 (полностью операционный графический режим). Но это на самом деле абсолютно настраивается, и специфические особенности того, что входит, который runlevel главным образом условно. Я думаю по крайней мере в прошлом, что Debian использовал runlevel 4 для полностью операционного графического режима, например, и на моем Хрипящем Debian, runlevels 2 и 3, кажется, идентичны (diff <(ls /etc/rc2.d) <(ls /etc/rc3.d) ничего не производит). Точно то, чему соответствует каждый runlevel, до администратора.
Также условно runlevel 6 обычно устанавливается до перезагрузки система; можно перейти непосредственно к runlevel 6 от, например, runlevel 1, особенно во время обслуживания системы, если что-то препятствует тому, чтобы ОС обычно загружалась.
Также стоит отметить, что системы не-Linux могут иметь различные идеи того, что различные runlevels для или имеют другое количество доступного runlevels. Понятие вероятно в значительной степени универсальное в *, отклоняют мир, но реализация и фактическое использование могут отличаться дико.
В целом, "runlevels" является просто удобным способом сгруппировать связанные процессы и состояние системы в управляемые пакеты, которые могут быть выбраны администратором. (И как в стороне, Windows имеет очень похожее понятие со своим отказоустойчивым режимом, отказоустойчивым с сетями, отказоустойчивыми с командной строкой, нормальной начальной загрузкой, и так далее.)