Как вывести систему из строя?

lampslave	# 8 лет, 7 месяцев назад
Темы: 32 Сообщения: 4801 Участник с: 05 июля 2011	А вот кстати, на bash-е бесконечный цикл можно написать или он стрелять в ногу не позволяет?

sirocco	# 8 лет, 7 месяцев назад
Темы: 29 Сообщения: 2501 Участник с: 25 июля 2007	fork-бомбу

Rarog	# 8 лет, 7 месяцев назад
Темы: 10 Сообщения: 188 Участник с: 22 января 2013	vasek Не вариант - Хорошо бы что нибудь из кернел-паник У меня подруга недавно случайно поставила жесткие квоты на /dev. Результат - kernel panic, сам бы не додумался до такого)))

Natrio	# 8 лет, 7 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	jim945 Забить оперативу, желательно с отсутсвующим свапом. Вроде как-то помогало))) ДА! Очень даже помогает :)) У меня есть довольно забавная история про отключённый свап. Однажды я настраивал Raspberry Pi под Арчем. У этой штуковины 512МБ памяти, вместо диска она использует SD-карточку, а потому я решил попробовать на ней F2FS для корня, tmpfs для /tmp, а без свапа вообще обойтись. И всё шло хорошо до тех пор, пока я не решил протестировать скорость её Ethernet-контроллера скачиванием большого файлика, а чтобы не писать его на SD, скачивал в tmpfs, куда он по размеру должен был с большим запасом поместиться. Когда файл скачался на 90%, связь с распберри прервалась и больше не восстановилась. Принудительная перезагрузка закончилась тем, что Арч стал падать во время загрузки каждый раз. Оказалось, что модуль f2fs делает ядру OOPS, а точнее сегфолтится при каждой попытке монтирования корня. Вынимаю карточку из распберри, вставляю в десктоп, и получаю то же самое – модуль f2fs на десктопе точно так же делает ручкой при попытке монтирования этого раздела с карточки, несмотря на то, что fsck.f2fs не находит никаких ошибок. В конце концов, после пары презагрузок уже на десктопе (после OOPS модуль ядра невозможно реанимировать до перезагрузки), я выяснил, что однократное монтирование раздела с опцией disable_roll_forward позволяет обойти сей злобный глюк и восстановить загрузку распберри без ошибок. Но в чём же была причина? Я провёл несколько экспериментов, и оказалось, что: 1) скачивание файла на карточку (в f2fs) любым способом проходит нормально. 2) скачивание файла в /dev/null любым способом проходит тоже нормально. 3) скачивание файла аналогичного или большего размера любым способом в tmpfs приводит к точно такому же падению с последующими OOPS при монтировании. Несмотря на то, что файл по размеру должен был помещаться и в память вообще, и в tmpfs по его видимому размеру, на самом деле при его записи в tmpfs память заканчивалась, в ядре срабатывал oom-killer, который убивал подвернувшиеся процессы, но так как память занималась не ими, а ядром, причём двухкратно – под tmpfs и (по-видимому) под буферы, ядро полностью вставало колом, и не могло завершить больше ни одной операции записи куда-либо, отсюда и странное состояние корневого раздела, настолько незапланированное разработчиками f2fs, что вызывает сегфолт при попытке смонтировать его. Конечно же, это баг реализации f2fs, но условия, в которых он проявляется, сами по себе демонстрируют, что случается, когда НЕТ СВАПА. Так что если вдруг вы решите, что свап вам не нужен, готовьтесь к самым разнообразным неожиданностям! Память может внезапно исчерпаться, и не только по вине юзерспейса, но и по вине ядра, даже если вам кажется, что памяти хватает. Oom-killer не поможет. Когда ядру не хватает памяти, могут вылезти ТАКИЕ странные баги, что вы даже не поймёте, что вообще произошло, кто виноват и что делать :) И кстати, я вовсе не уверен, что свап в файле не создаст аналогичных проблем – ведь всё, что записывается в файл, сначала попадёт в буфер, а уже потом на диск. Вы уверены, что в самый неподходящий момент памяти под буфер хватит?

Natrio

# 8 лет, 7 месяцев назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

jim945
Забить оперативу, желательно с отсутсвующим свапом. Вроде как-то помогало)))

ДА! Очень даже помогает :))

У меня есть довольно забавная история про отключённый свап.

Однажды я настраивал Raspberry Pi под Арчем.

У этой штуковины 512МБ памяти, вместо диска она использует SD-карточку, а потому я решил попробовать на ней F2FS для корня, tmpfs для /tmp, а без свапа вообще обойтись.

И всё шло хорошо до тех пор, пока я не решил протестировать скорость её Ethernet-контроллера скачиванием большого файлика, а чтобы не писать его на SD, скачивал в tmpfs, куда он по размеру должен был с большим запасом поместиться.

Когда файл скачался на 90%, связь с распберри прервалась и больше не восстановилась. Принудительная перезагрузка закончилась тем, что Арч стал падать во время загрузки каждый раз. Оказалось, что модуль f2fs делает ядру OOPS, а точнее сегфолтится при каждой попытке монтирования корня. Вынимаю карточку из распберри, вставляю в десктоп, и получаю то же самое – модуль f2fs на десктопе точно так же делает ручкой при попытке монтирования этого раздела с карточки, несмотря на то, что fsck.f2fs не находит никаких ошибок.

В конце концов, после пары презагрузок уже на десктопе (после OOPS модуль ядра невозможно реанимировать до перезагрузки), я выяснил, что однократное монтирование раздела с опцией disable_roll_forward позволяет обойти сей злобный глюк и восстановить загрузку распберри без ошибок. Но в чём же была причина?

Я провёл несколько экспериментов, и оказалось, что:
1) скачивание файла на карточку (в f2fs) любым способом проходит нормально.
2) скачивание файла в /dev/null любым способом проходит тоже нормально.
3) скачивание файла аналогичного или большего размера любым способом в tmpfs приводит к точно такому же падению с последующими OOPS при монтировании.

Несмотря на то, что файл по размеру должен был помещаться и в память вообще, и в tmpfs по его видимому размеру, на самом деле при его записи в tmpfs память заканчивалась, в ядре срабатывал oom-killer, который убивал подвернувшиеся процессы, но так как память занималась не ими, а ядром, причём двухкратно – под tmpfs и (по-видимому) под буферы, ядро полностью вставало колом, и не могло завершить больше ни одной операции записи куда-либо, отсюда и странное состояние корневого раздела, настолько незапланированное разработчиками f2fs, что вызывает сегфолт при попытке смонтировать его.

Конечно же, это баг реализации f2fs, но условия, в которых он проявляется, сами по себе демонстрируют, что случается, когда НЕТ СВАПА. Так что если вдруг вы решите, что свап вам не нужен, готовьтесь к самым разнообразным неожиданностям! Память может внезапно исчерпаться, и не только по вине юзерспейса, но и по вине ядра, даже если вам кажется, что памяти хватает. Oom-killer не поможет. Когда ядру не хватает памяти, могут вылезти ТАКИЕ странные баги, что вы даже не поймёте, что вообще произошло, кто виноват и что делать :)

И кстати, я вовсе не уверен, что свап в файле не создаст аналогичных проблем – ведь всё, что записывается в файл, сначала попадёт в буфер, а уже потом на диск. Вы уверены, что в самый неподходящий момент памяти под буфер хватит?

vasek	# 8 лет, 7 месяцев назад
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	Спасибо за советы, особенно с памятью. После Ваших советов вспомнил, что у меня для этого имеется специальный файл, открытие которого забивает не только оперативку но и swap. Зависает все намертво, для перегрузки спасает только одно — REISUB Но это очень жестко, может потом придумаю чего помягче — чтобы и зависало и память была. Смысл всего этого в том, что проверяю возможности работы заблаговременной отладочной консоли (tty9). Ошибок нет, поэтому приходится их в основном моделировать, а также подключать внука (у того, как правило, зависаний больше). Осталось выяснить два момента: 1) Преимущество отладочной консоли (tty9) перед другими tty. Теоретически вроде бы понятно, что разницы быть не должно, так как все упирается в нажатие кнопок, но проверить хотелось. 2) Проверка работы отладочной консоли (tty9) в случае не выключения компа — пишут, что зайти в нее можно, но проверить тоже не могу, не представляется случай. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 8 лет, 7 месяцев назад

Темы: 48

Сообщения: 11340

Участник с: 17 февраля 2013

Спасибо за советы, особенно с памятью.
После Ваших советов вспомнил, что у меня для этого имеется специальный файл, открытие которого забивает не только оперативку но и swap.
Зависает все намертво, для перегрузки спасает только одно — REISUB
Но это очень жестко, может потом придумаю чего помягче — чтобы и зависало и память была.
Смысл всего этого в том, что проверяю возможности работы заблаговременной отладочной консоли (tty9). Ошибок нет, поэтому приходится их в основном моделировать, а также подключать внука (у того, как правило, зависаний больше).
Осталось выяснить два момента:
1) Преимущество отладочной консоли (tty9) перед другими tty. Теоретически вроде бы понятно, что разницы быть не должно, так как все упирается в нажатие кнопок, но проверить хотелось.
2) Проверка работы отладочной консоли (tty9) в случае не выключения компа — пишут, что зайти в нее можно, но проверить тоже не могу, не представляется случай.

Ошибки не исчезают с опытом - они просто умнеют

Aivar	# 8 лет, 7 месяцев назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	Про память уже писали. Могу поделиться граблями, на которые недавно наступил: при включенном компе подключал второй монитор по S-Video (выключать железо было влом ) ). Результат - серый экран и никакой реакции ни на что. Может вырубилась только видеокарта, но отклик возымел только железный ребут. :/

Aivar

# 8 лет, 7 месяцев назад

Темы: 4

Сообщения: 6897

Участник с: 17 февраля 2011

Про память уже писали. Могу поделиться граблями, на которые недавно наступил: при включенном компе подключал второй монитор по S-Video (выключать железо было влом ) ). Результат - серый экран и никакой реакции ни на что. Может вырубилась только видеокарта, но отклик возымел только железный ребут. :/

nafanja	# 8 лет, 7 месяцев назад
Темы: 94 Сообщения: 9252 Участник с: 02 июня 2012 заблокирован	lampslave А вот кстати, на bash-е бесконечный цикл можно написать или он стрелять в ногу не позволяет? попробуй #!/bin/sh while true do $0 & echo 'ku-ku' done ))) Псевдографический инсталлятор Arch Linux ver. 3.8.2 Благодарности принимаются на ЯД 410012815723874

nafanja

# 8 лет, 7 месяцев назад

Темы: 94

Сообщения: 9252

Участник с: 02 июня 2012

заблокирован

lampslave
А вот кстати, на bash-е бесконечный цикл можно написать или он стрелять в ногу не позволяет?

попробуй

#!/bin/sh
while true
do
	$0 &
	echo 'ku-ku'
done

)))

Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874

vasek	# 8 лет, 7 месяцев назад
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	nafanja lampslave А вот кстати, на bash-е бесконечный цикл можно написать или он стрелять в ногу не позволяет? попробуй #!/bin/sh while true do $0 & echo 'ku-ku' done ))) Попробовать то я попробовал - результат ожидаемый, все это также связано с заполнением памяти. И похоже вопрос о преимуществе отладочной консоли перед другими, мною надуман. Остается проверить один пункт - незавершение выключения компа. Но выводы для себя сделал - вещь полезная. UPD..........зато научился без запинки и с требуемой паузой нажимать REISUB (двумя руками) Ошибки не исчезают с опытом - они просто умнеют

vasek

# 8 лет, 7 месяцев назад

Темы: 48

Сообщения: 11340

Участник с: 17 февраля 2013

nafanja
lampslave
А вот кстати, на bash-е бесконечный цикл можно написать или он стрелять в ногу не позволяет?
попробуй
#!/bin/sh
while true
do
	$0 &
	echo 'ku-ku'
done
)))

Попробовать то я попробовал - результат ожидаемый, все это также связано с заполнением памяти.
И похоже вопрос о преимуществе отладочной консоли перед другими, мною надуман.
Остается проверить один пункт - незавершение выключения компа.
Но выводы для себя сделал - вещь полезная.
UPD..........зато научился без запинки и с требуемой паузой нажимать REISUB (двумя руками)

Ошибки не исчезают с опытом - они просто умнеют

ivand	# 8 лет, 7 месяцев назад
Темы: 9 Сообщения: 477 Участник с: 04 января 2013	Подобно способу Natrio, но в связке obexfs+fuse была роскошная повторяемость PS: зато научился без запинки и с требуемой паузой нажимать REISUB (двумя руками) SysRq вариации при этом беспомощны

vasek	# 8 лет, 7 месяцев назад
Темы: 48 Сообщения: 11340 Участник с: 17 февраля 2013	В результате ознакомления с работой заблаговременной отладочной консоли пришел к одному интересному выводу - используя systemd (debug-shell.service) можно попасть в root shell (sh-4.2#) без установочного диска и всяких Live CD. Плюс в том, что для chroot не нужен установочный диск, а минус - злоумышленник может проникнуть в систему. И, похоже, все-таки лучше последовать совету Natrio - установить пароль на grub (все лень заняться этим). Но может я и не прав и чего то не понимаю??? Ошибки не исчезают с опытом - они просто умнеют

vasek

# 8 лет, 7 месяцев назад

Темы: 48

Сообщения: 11340

Участник с: 17 февраля 2013

В результате ознакомления с работой заблаговременной отладочной консоли пришел к одному интересному выводу - используя systemd (debug-shell.service) можно попасть в root shell (sh-4.2#) без установочного диска и всяких Live CD.
Плюс в том, что для chroot не нужен установочный диск, а минус - злоумышленник может проникнуть в систему.
И, похоже, все-таки лучше последовать совету Natrio - установить пароль на grub (все лень заняться этим).
Но может я и не прав и чего то не понимаю???

Ошибки не исчезают с опытом - они просто умнеют