Почему один из двух жестких дисков выходит из спящего режима при первом графическом входе в систему 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.