LINUX.ORG.RU

Я положил систему с помощью grep. Что я сделал не так?

 


2

7

Привет.

Есть физический сервер с Oracle Linux 7.5, с ядром uek-5 и с последними обновами.

Набрал простую команду по ssh:

grep -r -i RETP /sys/*

и после этого сервер завис полностью. Сказать, что я был в шоке — ничего не сказать.

Последнее в консоли:

grep: /sys/kernel/slab/:a-0000056/free_calls: Function not implemented
grep: /sys/kernel/slab/skbuff_head_cache/alloc_calls: Function not implemented
grep: /sys/kernel/slab/skbuff_head_cache/free_calls: Function not implemented
grep: /sys/kernel/slab/task_struct/alloc_calls: Function not implemented
grep: /sys/kernel/slab/task_struct/free_calls: Function not implemented
grep: /sys/kernel/slab/:d-0000016/alloc_calls: Function not implemented
grep: /sys/kernel/slab/:d-0000016/free_calls: Function not implemented
grep: /sys/kernel/slab/:0000232/alloc_calls: Function not implemented
grep: /sys/kernel/slab/:0000232/free_calls: Function not implemented
grep: /sys/kernel/slab/:0000128/alloc_calls: Function not implemented
grep: /sys/kernel/slab/:0000128/free_calls: Function not implemented
grep: /sys/kernel/slab/kmem_cache_node/alloc_calls: Function not implemented
grep: /sys/kernel/slab/kmem_cache_node/free_calls: Function not implemented
grep: /sys/kernel/slab/:a-0000064/alloc_calls: Function not implemented
grep: /sys/kernel/slab/:a-0000064/free_calls: Function not implemented
grep: /sys/kernel/slab/:0005888/alloc_calls: Function not implemented
grep: /sys/kernel/slab/:0005888/free_calls: Function not implemented

ssh завис, консоль через ILO была просто чёрной.

Что я сделал не так? Как через grep я мог положить систему? На вируталке с такой же ОС не смог воспроизвести проблему. А это был почти prod, к счастью, сервер пока новый и только билдится.

P.S> grep запускать через sudo.

★★★

Что я сделал не так? Как через grep я мог положить систему?

Было у меня также. Не делай так.

Deleted ()

Моя ванга говорит, что если зависло на /sys, значит в каком-то драйвере баг.

UVV ★★★★★ ()

Ребята, Ubuntu 18.04 зависает точно так же. Попробовал на домашнем ПК. Вируталки не зависают, только физика.

4 раза подряд только что проделал эксперимент, система зависает. В консоли выводится сообщение о ACPI и система фризится.

Что это за бред? Я не пойму.

P.S. grep надо через sudo делать.

iljuase ★★★ ()
Последнее исправление: iljuase (всего исправлений: 1)
Ответ на: комментарий от iljuase

в логах на Ubunru:

Sep 23 18:13:39 vodka-PC kernel: [ 2920.259625] ACPI Exception: AE_ERROR, While parsing command line (20170831/dbinput-1213)
Sep 23 18:13:39 vodka-PC crontab[1299]: (vodka3) LIST (vodka3)
Sep 23 18:14:01 vodka-PC CRON[2158]: (vodka3) CMD (. $OMD_ROOT/etc/omd/site.conf ; curl http://localhost:$CONFIG_APACHE_TCP_PORT/vodka3/check_mk/run_cron.py >/dev/null 2>&1)
Sep 23 18:14:01 vodka-PC CRON[2159]: (vodka3) CMD ([ ! -e /omd/sites/vodka3/etc/check_mk/conf.d/microcore.mk -a -d /omd/sites/vodka3/var/check_mk/notify/bulk ] && cmk --notify send-bulks)
Sep 23 18:14:03 vodka-PC /usr/lib/gdm3/gdm-x-session[1694]: (II) event5  - Logitech G102 Prodigy Gaming Mouse: SYN_DROPPED event - some input events have been lost.
Sep 23 18:14:03 vodka-PC org.gnome.Shell.desktop[1831]: Window manager warning: CurrentTime used to choose focus window; focus window may not be correct.
Sep 23 18:14:03 vodka-PC shutter.desktop[2040]: GdkPixbuf-LOG **: gdk_pixbuf_from_pixdata() called on: at /usr/bin/shutter line 2891.
Sep 23 18:14:03 vodka-PC shutter.desktop[2040]: GdkPixbuf-LOG **: #011Encoding raw at /usr/bin/shutter line 2891.
Sep 23 18:14:03 vodka-PC /usr/lib/gdm3/gdm-x-session[1694]: (--) NVIDIA(GPU-0): DFP-0: disconnected
Sep 23 18:14:03 vodka-PC /usr/lib/gdm3/gdm-x-session[1694]: (--) NVIDIA(GPU-0): DFP-0: Internal TMDS
Sep 23 18:14:03 vodka-PC /usr/lib/gdm3/gdm-x-session[1694]: (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock
Sep 23 18:14:03 vodka-PC /usr/lib/gdm3/gdm-x-session[1694]: (--) NVIDIA(GPU-0):
Sep 23 18:14:03 vodka-PC /usr/lib/gdm3/gdm-x-session[1694]: (--) NVIDIA(GPU-0): Samsung S24D390 (DFP-1): connected
Sep 23 18:14:03 vodka-PC /usr/lib/gdm3/gdm-x-session[1694]: (--) NVIDIA(GPU-0): Samsung S24D390 (DFP-1): Internal TMDS
Sep 23 18:14:03 vodka-PC /usr/lib/gdm3/gdm-x-session[1694]: (--) NVIDIA(GPU-0): Samsung S24D390 (DFP-1): 600.0 MHz maximum pixel clock
Sep 23 18:14:03 vodka-PC gsd-media-keys[2005]: g_variant_get_va: assertion 'value != NULL' failed
Sep 23 18:14:03 vodka-PC gsd-media-keys[2005]: g_variant_unref: assertion 'value != NULL' failed
Sep 23 18:14:03 vodka-PC org.gnome.Shell.desktop[1831]: current session already has an ibus-daemon.
Sep 23 18:14:04 vodka-PC dbus-daemon[906]: [system] Activating via systemd: service name='org.freedesktop.GeoClue2' unit='geoclue.service' requested by ':1.264' (uid=1000 pid=1831 comm="/usr/bin/gnome-shell " la
bel="unconfined")
Sep 23 18:14:04 vodka-PC systemd[1]: Starting Location Lookup Service...
Sep 23 18:14:04 vodka-PC dbus-daemon[906]: [system] Successfully activated service 'org.freedesktop.GeoClue2'
Sep 23 18:14:04 vodka-PC systemd[1]: Started Location Lookup Service.
Sep 23 18:14:04 vodka-PC gnome-shell[1831]: Telepathy is not available, chat integration will be disabled.
Sep 23 18:14:04 vodka-PC gnome-shell[1831]: JS WARNING: [/usr/share/gnome-shell/extensions/ubuntu-dock@ubuntu.com/appIcons.js 1028]: unreachable code after return statement
Sep 23 18:14:04 vodka-PC bluetoothd[917]: Failed to set mode: Blocked through rfkill (0x12)

iljuase ★★★ ()

не делай grep по /sys/

/thread

Harald ★★★★★ ()
Ответ на: комментарий от iljuase

Жаль, что на зависший Oracle Linux ещё не купили лицензию. На системах с купленной лицензией нельзя экспериментировать.

RHEL 'чтобы поиграться' тоже отсутствуют. Придётся ждать 'планового' ребута серверов, чтобы спровоцировать зависание и открыть кейс вендору. Если разрешат, конечно...

iljuase ★★★ ()

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

amd_amd ★★★★ ()

Попробовал на ораньж пай пк+ с армбианом, повисело и отвисло, брат жив. На i7 под арчем даже и не зависало толком. На фряхе тоже не висло, брат жив снова. Так что у тебя что то не так.

burato ★★★★★ ()
Ответ на: комментарий от burato

На серваке с Oracle Linux 2 процессора Intel® Xeon® Gold 6142 (в сумме 32 ядра и 64 потока) и 256 ГБ RAM, дома i5-6400 (4 ядра) и 16 GB RAM.

Дома система крайне неотзывчивая становится и приходится делать reset, на серваке ctrl + c не работала, новая ssh-сессия не открывалась, через ilo тупо чёрный экран.

iljuase ★★★ ()
Ответ на: комментарий от iljuase

Не работай под рутом (c) (tm) (r)

Дебилы б... (r) (tm) (c)

Nastishka ★★★★★ ()

Локализуй проблему:

for file in $(find /sys/kernel); do echo "$file"; grep -i RETP "$file"; done

Возможно там какое-нибудь устройство через которое можно обратиться ко всей отображаемой памяти для твоей архитектуры (256 тб для amd64), и греп там немножко тонет.

slowpony ★★★★ ()
Последнее исправление: slowpony (всего исправлений: 1)
Ответ на: комментарий от slowpony

Но grep же работает в 1 поток, и если даже он будет парсить файл размером 256ТБ — разве ситсема должна повсинуть?

iljuase ★★★ ()
Ответ на: комментарий от iljuase

Должна виртуальная память кончиться. ЕМНИП, в бубунте overcommit разрешён по дефолту - это значит, что OOM не придёт. Ну и если там свопа дохера - оно не виснет, оно в своп всю эту чухню складывает. А это медленно.

Deleted ()
Ответ на: комментарий от Deleted

Перед зависаниями я смотрел free -m в соседнем терминале, свободной памяти было много.

+свопа дома нет.

iljuase ★★★ ()
Последнее исправление: iljuase (всего исправлений: 1)
Ответ на: комментарий от iljuase

Можно продолжать теоретизировать после того как станет понятно на каком файлике затыкаемся.

А так, внутренняя Ванга подсказывает, что у нас с одной стороны паровозик грепа катится, а с другой - ядро пытается на полном ходу ему рельсы подкладывать. В смысле, «файлик» этот. И, возможно, оно утилизирует больше одного cpu core на это.

slowpony ★★★★ ()
Последнее исправление: slowpony (всего исправлений: 1)
Ответ на: комментарий от iljuase

grep отлично вешает. Давно известно. Ничего нового.

anonymous ()
Ответ на: комментарий от slowpony

Вы мне не поверите, то с помощью вашей конструкции ничего не зависает... А если сделать так, как я написал — зависает.

iljuase ★★★ ()
Ответ на: комментарий от r0ck3r

конечно, можно набрать специальную юникодную последовательность в notepad.exe

anonymous ()
Ответ на: комментарий от iljuase

Просто find по умолчанию никогда не ходит по символическим ссылкам, а 'grep -r' ходит по тем, что есть в командной строке, куда ты их загоняешь по '*'.
Попробуй сравнить структуру /sys на реальной и виртуальной машинах, максимально близких по железу и операционке, может и найдёшь в чём фокус.

ABW ★★★★★ ()
Ответ на: комментарий от ABW

Просто find по умолчанию никогда не ходит по символическим ссылкам

...по ссылке наверно уходит в /proc, а там полно странных файлов, которые по нормальному не открыть.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от r0ck3r

интересно, я есть ли воспроизводимые пути вызова BSoD на Windows?

Да, раньше в одной из функций WinAPI был баг из-за отсутствия проверки деления на 0. При вызове этой функции с определённым аргументом винда падала в синий экран.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)

Считывать все подряд псевдофайлы - идея выглядит так себе. Но было бы интересно, на каких именно файлах глохнет.

anonymous ()
Ответ на: комментарий от iljuase

Тогда так:

strace -T -s 4096 grep -r -i RETP /sys/*


Или так:
strace -o ~/grep.strace -T -s 4096 grep -r -i RETP /sys/*

Но если ожидается хард ресет - файлик может оказаться недописан или поврежден, так что лучше глазками в реалтайме, наверное.

slowpony ★★★★ ()
Ответ на: комментарий от slowpony

Что только не придумают, чтобы только не подойти к проблеме по уму. Ведь grep непаралельный, надо вначале выяснить, оно замирает на одном файле или находит бесконечное количесво тут же генерируемых файлов и захлёбывается в этом. А потом уже делать всякие strace на конкретном каталоге/файле.

vodz ★★★★★ ()
Ответ на: комментарий от vodz

Я так понимаю, проблема не в том, что grep где-то там захлёбывается, а в том, что при этом ложится вся система.

Legioner ★★★★★ ()

Хороший «ручной вирус».

У меня grep на файлах amd-(что-то там) выдал чёрный экран, после нескольких секунд изображение появилось, но из-за артефактов ничего непонятно. Такого авангарда, который происходит на экране, я ещё не у одного художника не видел.

anonymous ()

если ты на винде из с правами администратора запустишь простенький скрипт читающий всю опертивку(из под оминаже можно по идее да)
любая винда зависнет

если ты из под админа в винде начнешь читать ACPI прошивок работающих жестких дисков-все зависнет

и еще тыща сценариев

то что ты решил грипнуть «потомушто могу» а там сотни «неактивных драйверов»(которые вешают ядро если читать их без инициализации)...

повесить ACPI на вин/линукс современном дело двух строк скрипто-кода, и под админа конечноже

missxu ()
Ответ на: комментарий от Legioner

Я так понимаю, проблема не в том, что grep где-то там захлёбывается, а в том, что при этом ложится вся система.

А я так понимаю, что проблема не выявлена. С тем же успехом может оказаться, что дело не в поиске как таковом, а в бесконечном количестве файлов в каталогах и выжирании всей памяти на их «имена», ибо /sys славится замкнутыми ссылками и кольцеванием дерева. Но это одна из версий.

vodz ★★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

Что это за дистрибутив, в котором система ложится от одной программы, выжравшей память? Даже если лимиты не настроены, есть же OOM-Killer. Форк-бомбы тут нет, один процесс.

Legioner ★★★★★ ()

Manjaro - вывод команды - куча строк с «Отказано в доступе».

Alexonline ★★★ ()
Ответ на: комментарий от Legioner

Если всю память съела программа из юзерспейса - ее пристрелит OOM.
Если всю память съело ядро - мы увидим kernel panic.

Наверное, не память. Но это, опять же, чисто теоретически.

В сислоге там ничего не осталось интересного после «зависания»?

slowpony ★★★★ ()
Ответ на: комментарий от slowpony

Если есть своп на медленном диске - OOM не придёт (система уйдет в IO, и это будет бесконечно долго).

Deleted ()
Ответ на: комментарий от Legioner

Любой, у которого большой своп на медленном устройстве.

Deleted ()

Что я сделал не так?

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

Вируталки не зависают, только физика

Виртуалки эмулируя железо могут говорить что всё ок (вместо реальной операции стоит затычка).

no-such-file ★★★★★ ()

с ядром uek-5

Unbreakable, стало быть, Linux Kernel.

thesis ★★★★★ ()
Ответ на: комментарий от Deleted

У других систем с нормальным шедулером приходит.

Shadow ★★★★★ ()
Ответ на: комментарий от slowpony

Если всю память съела программа из юзерспейса - ее пристрелит OOM.

Перед этим система будет долго тупить. А получить выедание grep-ом кучи памяти с 100% загрузкой CPU - запросто. Достаточно генерировать в файле скажем единичку без \n и при любом следующем чтении.

vodz ★★★★★ ()
Ответ на: комментарий от Shadow

Ну ты не в теме, видимо. Шедулер тот же. И если система лезет в своп и активно работает с пмятью, кидая туда-обратно страницы - она получает бооольшииеее тормоза. OOM придёт. Но не скоро.

Deleted ()
Ответ на: комментарий от Deleted

У bsd там есть в коде приоритеты, и при форкбомбе даже можно дождаться ответа на tty. У linux'a не дождёшься, а oom killer замочит что-нибудь полезное вместо того, что надо. Просто ситуациия настолько синтетическая, что хватает лимитов и cgroups.

Shadow ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.