Почему один из двух жестких дисков выходит из спящего режима при первом графическом входе в систему Linux?

У меня есть два архивных жестких диска, которые я использую очень редко (в среднем я монтирую их разделы не чаще одного раза в неделю). Поскольку я ночью выключал свой компьютер, я пытался предотвратить их вращение при повседневной загрузке, но это кажется слишком сложным: требуется исправление ядра Linux. В качестве худшей, но более простой альтернативы я создал простой системный модуль, который переводит жесткие диски в спящий режим сразу после загрузки (ExecStart=/usr/bin/hdparm -Y /dev/disk/by-id/... а также WantedBy=multi-user.target). Это почти работает: оба диска вращаются при загрузке. Я проверил это с помощью логина терминала в tty2: sudo hdparm -C /dev/sd[bc] отчеты drive state is: standby,

Однако, как только я вхожу в графическую оболочку, один из дисков раскручивается со звуком и выдает отчет hdparm. drive state is: active/idle для этого. Это происходит как с XFCE, так и с KDE Plasma 5 (Manjaro GNU/Linux с последними обновлениями), а также с другим пользователем той же системы. После пробуждения диска я усыпляю его вручную (hdparm -Y ...), и он никогда не проснется, пока я не перезагружу компьютер. Выйти из системы, затем войти в нее, даже как другой пользователь, больше не будит ни одного диска.

Этот пробуждающий диск всегда один и тот же. Я попытался поменять местами кабели SATA этих двух жестких дисков, которые обменивались своими идентификаторами (sdb <-> sdc), но все же тот же физический жесткий диск пробуждается при первом графическом входе в систему. Этот пробуждающий диск определенно нигде не упоминается в моих файлах конфигурации по его постоянному идентификатору, потому что я приобрел его недавно (из вторых рук). Более конкретно, диск, который продолжает спать, - это Samsung HD103UJ, а диск, который пробуждается при первом графическом входе в систему, - это Samsung HD154UI.

Я отслеживаю /dev/sd[bc] доступы с помощью audd. Логи практически одинаковы для обоих дисков. Сначала я захожу в консоль tty2 и запускаю sudo hdparm -C /dev/sd[bc]: оба диска спят; затем я переключаюсь на tty7 и захожу в XFCE с экрана lightdm; Я быстро переключаюсь на tty2 и теперь один из дисков больше не спит. Суть sudo ausearch -f /dev/sdb вывод команды, соответствующий этим событиям:

comm="hdparm" exe="/usr/bin/hdparm"
comm="udisksd" exe="/usr/lib/udisks2/udisksd"
comm="hdparm" exe="/usr/bin/hdparm"
comm="udisksd" exe="/usr/lib/udisks2/udisksd"
comm="pool" exe="/usr/lib/udisks2/udisksd"
comm="pool" exe="/usr/lib/udisks2/udisksd"
...

И так далее. comm="pool" строка появляется каждые 10 минут в журнале или чаще во время работы gnome-дисков, но comm="udisksd" линия не появляется до перезагрузки. Предполагая, что audd сообщает обо всех обращениях к диску, это comm="udisksd" должен нести ответственность за пробуждение. Но почему только один из 2 жестких дисков? Возможно, нарушающий жесткий диск может быть настроен с hdparm не разбудить?

Я сравнил hdparm -I /dev/sdb а также hdparm -I /dev/sdc выходы со слиянием. Также попробовал -Iv, -i а также -iv варианты вместо -I, Различия в значительной степени ограничены уникальными идентификаторами, размерами дисков, геометрией. Единственное различие, которое может вызвать эту непоследовательность при пробуждении, - это Версия микропрограммы: 1A A 01118 на диске без пробуждения и 1A G 01118 на диске пробуждения.

0 ответов

удисксд звонки dumpe2fs -h /dev/sd?? Команда для каждого раздела ext2, ext3 и ext4, когда служба запускается и когда она монтирует / размонтирует любой диск. Мой пробуждающий жесткий диск содержит раздел ext4 и поэтому разбудил udisksd => dumpe2fs, На другом жестком диске нет разделов ext*, поэтому udisksd никогда его не разбудит.

Более подробную информацию можно найти в комментариях к этой ошибке udisks: https://github.com/storaged-project/udisks/issues/611. Ошибка исправлена ​​в udisks 2.8.4, поэтому она больше не будит никаких жестких дисков, когда несвязанный раздел смонтирован или размонтирован. При запуске udisksd все тот же жесткий диск все еще активен, поэтому я должен оставить второй системный модуль, который переводит этот жесткий диск в спящий режим после запуска службы udisks2.

Другие вопросы по тегам