LINUX.ORG.RU
ФорумTalks

Атрибуты в /dev

 lsattr


0

1

Наберите от рута lsattr -al /dev/ только на всякий случай на некритичном компе - что произойдёт?

Добавлю что получилось у меня, по /var/log/messages

Nov 28 02:38:39 nb2 kernel: [4438721.540616] NET: Registered protocol family 40
Nov 28 02:38:39 nb2 kernel: [4438721.613867] tun: Universal TUN/TAP device driver, 1.6
Nov 28 02:38:39 nb2 kernel: [4438721.683373] Non-volatile memory driver v1.3
Nov 28 02:38:39 nb2 kernel: [4438721.877780] Btrfs loaded, crc32c=crc32c-intel
Nov 28 02:38:39 nb2 kernel: [4438721.935117] serial 00:02: LSR safety check engaged!
Nov 28 02:42:14 nb2 kernel: [    0.000000] Linux version 5.10.0-26-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.197-1 (2023-09-29)
Nov 28 02:42:14 nb2 kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-26-amd64 root=UUID=b595a138-37e4-4775-8edd-27e7455d14a1 ro acpi_backlight=vendor "acpi_osi=!Windows 2012" module_blacklist=echi_pci,ehci_hcd quiet

Как видно, lsattr подгрузил пачку каких-то ненужных модулей. А через некоторое время (секунд 15?) ноут молча ребутнулся, похоронив открытые окна за полтора месяца :(.

Корень причины понятен: в отличие от нормальных людей, у которых файловые флаги отдаются через stat(2), в линуксе чтоб их получить надо делать какое-то ioctl на открытый файловый дескриптор (и открывание с O_PATH не годится). Отсюда последствия: 1) на симлинках не работает, 2) попытка чтения их из chr/blkdev или pipe может иметь побочные эффекты т.к. открывание таких файлов их имеет (но в итоге всё равно фейлится, по крайней мере для файлов устройств). Тут кстати, неустранимый race получается - невозможно пытаться прочитать флаги, будучи уверенным что не откроешь случайно файл какого-нить устройства. Хорошо хоть следовать по симлинкам можно запретить через O_NOFOLLOW, а то было бы совсем печально.

Механизм конкретно моего сценария - точно не пойму, но есть два предположения: 1) грузится какой-то забагованный модуль (не обязательно из тех четырёх, ведь они могут и молча грузиться не отправляя ничего в dmesg) который спустя недолгое время роняет ядро 2) активируется какой-то hw watchdog, который допустим надо после этого оповещать раз в 10 секунд для избежания аварийных ребутов

★★★★★

Последнее исправление: firkax (всего исправлений: 3)
$ sudo lsattr -al /dev/
/dev/.                       ---
/dev/..                      Extents
lsattr: Operation not supported While reading flags on /dev/nvidia-uvm-tools
lsattr: Operation not supported While reading flags on /dev/nvidia-uvm
/dev/nvidia-caps             ---
lsattr: Operation not supported While reading flags on /dev/ptp1
lsattr: Operation not supported While reading flags on /dev/vcsa6
lsattr: Operation not supported While reading flags on /dev/vcsu6
lsattr: Operation not supported While reading flags on /dev/vcs6
lsattr: Operation not supported While reading flags on /dev/vcsa5
...

Ничего страшного не произошло, дальше там все то же самое, где-то ---, где-то not supported

up: для чистоты эксперимента запустил от рута без sudo - то же самое

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

А и ещё - в dmesg ничего не написалось при первом запуске команды?

dmesg -T можно чтобы с нормальными таймстампами было.

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
/dev/.                       ---
/dev/v4l                     ---
/dev/shm                     ---
/dev/block                   ---
/dev/disk                    ---
/dev/dri                     ---
/dev/bus                     ---
/dev/char                    ---
/dev/snd                     ---
/dev/vfio                    ---
/dev/mapper                  ---
/dev/net                     ---
/dev/bsg                     ---
/dev/input                   ---
/dev/dma_heap                ---

Остальное — строки вида

lsattr: Operation not supported While reading flags on /dev/null

В dmesg ничего нет. Debian 13, ноут, могу еще на роутере проверить (openwrt, mips)

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

Что за флешмоб?) ничего криминального команда не делает. Для статистики мне кажется бесполезно кого-то ещё ждать, вывод примерно одинаковый будет у всех.

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

Ну, у меня последствия другие получились (немного неприятные), и я даже проверил потом ещё раз.

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

Настрой ramoops или другой способ сохранить oops. Возможно это даст подсказку.

Ну и lsattr через «strace -ttt» запусти, чтобы было видно сколько времени оно выполняет операции.

На slackware-15dev нет проблемы.

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

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

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

Тогда пардон. Пробовал на Astra Linux, вывод примерно такой же как в первом комментарии.

evgenanato
()

открытые окна за полтора месяца

Любителей дрочить на аптайм наказали. Компьютер положено вечером выключать, а не копить окошки.

ox55ff ★★★★★
()

Скорее всего это x86 проблемы. Это уже считай мёртвая платформа. Её никто не тестит и там могут быть баги. Преходи на x86_64.

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

Дело не в аптайме, а в том что начатые дела прерывать и потом вспоминать не хочется, а так же в логах консолей что-то отложенное на «разобрать потом» бывает. Ребут потратит ещё кучу времени и сил лишних. Вот теперь придётся к сожалению.

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

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

firkax ★★★★★
() автор топика
Последнее исправление: firkax (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)