А что если загрузиться вот так:
Передать INIT=/bin/sh(or /bin/bash)параметр ядру через командную строку GRUB или аналогичными способами, затем загрузиться;
После загрузки оболочки немедленно выйти. Затем компьютер не реагирует ни на одну нажатую клавишу.
Мне очень любопытно узнать оПОЛОЖЕНИЕ ДЕЛсистемы в данный момент. Как я узнал, initэто первый процесс, который будет выполнен после загрузки ядра и всех остальных процессов, которые будут удалены forkиз него, похоже, что если выполнить его, /bin/shкак описано выше, а не initс помощью обычной процедуры загрузки, то в системе больше не будет никаких процессов и нечего делать.
Это холостой ход, как бег?
while (1) {
sleep(1);
}
или что еще?
Спасибо всем за ваши советы.Возможно, дополнительная информация будет полезна,которые я раньше считал ненужными.
Недавно я работал на сервере CentOS 7.2, и один раздел диска XFS не является нормальным, так как он тратит бесконечное время на проверку и восстановление при загрузке системы. Я планировал отредактировать, /etc/fstabчтобы отключить автоматическое монтирование этого раздела. Поскольку обычная процедура загрузки зависала, я использовал init=/bin/bashзагрузку системы в bash. После редактирования я небрежно fstabвыполнил shell ,exitзатем на экране не было никакой реакции на нажатие любой клавиши, включая Ctrl-Alt-Del, и не было никакой информации, вызвавшей панику ядра(Я не мог сказать, был ли процессор загружен, потому что в комнате было очень шумно). Я считал его бездействующим, просто бездельничающим. Это явление заставило меня задуматься о вопросе, который я записал в начале.
И сегодня вечером я провел несколько тестов на своем ноутбуке с Debian 8.Явная паника.
решение1
Я удивлен. Я понял, что завершение PID 1вызывает панику ядра. Я могу рассказать вам, что произошло в этом случае.
Поведение паники настраивается. С параметрами по умолчанию вы достигнетепетлявыглядит именно так, как вы говорите.
Используемая функция задержки:задокументированокак "занятое ожидание". Этонетожидается переход ЦП в энергосберегающие состояния сна, используемые, когда ОС находится в состоянии обычного бездействия.
Если вы посмотрите на обратную трассировку, напечатанную паникой, я думаю, вы увидите, что все это происходит в sys_exit(). Я думаю, технически PID 1 не уничтожается, он просто никогда не возвращается из этого системного вызова. Все остальные ЦП останавливаются первыми.
(Есть что-то, что называется"загрузочный поток бездействия". Я не вижу, чтобы он был вовлечен в этот процесс. AFAICT, вы никогда не сможете увидеть этот поток. И если вы хотите понять это как поток бездействия, вам также придется спросить, что обеспечивает поток бездействия для других процессоров, когда они включены).
решение2
Неправда, что система ничего не делает, если не запущен ни один процесс уровня пользователя. У системы есть кучапотоки ядра, которые запустило само ядро. Они в основном спят, но периодически просыпаются, чтобы выполнить свою задачу. Потоки ядра выполняют только код пространства ядра, т. е. у них нет никаких отображений памяти на уровне пользователя. Это отдельные процессы, поскольку они независимо планируются и имеют уникальные идентификаторы процессов.
Если вы запустите ps aux, вы сможете распознать потоки ядра по квадратным скобкам, окружающим имя потока.
решение3
В системе нет запущенных процессов. Поэтому нет цикла занятости, как вы написали (который бы загружал ЦП на 100%). Ядро все еще может обрабатывать прерывания, но процесса нет. ЦП будет простаивать.
Подробности можно найти здесь, висточник kernel_init(), программа выполняется аналогично execve(). Это также означает, что выполнение не возвращается (см. execve(3p)).