Зависание системы при выключении

Хмм, я ловил только один раз фриз, именно фриз на данном этапе.

workstation login: 

Но спустя 2-3 минуты система выключилась как ни в чем ни бывало.

Я, на всякий случай, давал системе на возможные размышления около часа :) Не решилась.

Присоединяюсь к вопросу. Помогает Ctrl+Alt+Delete - и я ухожу на перезагрузку. Потом выключаю.

Т.к. у меня не повторялось, возможности проверить не было, но: SysRQ + REISUB не работает в этом состоянии?

Я нагуглил лишь одну тему, в которой симпотмы как у меня (т.е. спустя н-ное количество времени система все таки выключилась), ноги растут от какого-то сервиса, который фейлится при остановке и подвешивает систему.
http://forums.debian.net/viewtopic.php?t=117746
Возможно у вас и ТС проблема в том же, но у меня пока нет идей как это отдебажить.

Оракулы ругают systemd

Зря. С появлением systemd система стала завершать работу мгновенно. Очень даже радует.

p.s. Debian 8.2 (KDE)

Включи логи пред. сеансов и смотри. Дебаг systemd также гуглится легко.

У меня на ноуте аналогичная проблема в связке wi-fi & nfs. Последняя не может отмонтироваться при уже выключенном wi-fi. Решается прописыванием дополнительных зависимостей.

gnome, gdm?

gnome, gdm?

No. Такое можно ловить даже без иксов.

В общем объявляю этот тред домом безумия и предрассудков.

Протанцевав всё это время с своими машинами выяснил, что зависания бывают при участии root-hub'a в системе. А точнее, если после загрузки я в dmesg вижу что у системы проблемы с работой одного из хабов - я могу узнать его адрес и отключить. Выразить это безумие можно в наколенкоскрипте:

#!/bin/bash

[ "$(dmesg | grep -i 'unable to enumerate USB device')" ] && {
        workpath="/sys/bus/pci/drivers/ehci-pci"

        name=$(find "${workpath}/" -name "0000:00:*")
        [ ! "${name}" ] && { echo 'no name found'; exit 12; }

        shortname=$(basename ${name})

        echo "${shortname}" > "${workpath}/unbind"
        if [ $? -eq 0 ]; then
                echo "${shortname} unbind - OK"
        else
                echo "${shortname} unbind - FAIL"
        fi
}

Если это условие выполнено - 10-12 тестовых перезагрузок, и никаких смерто-фризов.

Но теперь градус моего непонимания (и безумия) поднимается, и вступают предрассудки. В большей части случаев в dmesg'e нету той самой ошибки, что бы её вот так починить. Ну и в таком случае опять 7 из 10 ребутов - фриз. И я предполагаю что когда система идёт на выключение/перезагрузку она не всегда в правильной последовательности отключает хабы (или оно вообще не должно их выключать?), от чего возникает это зависание. Почему я так решил? Потому что если отыскать адрес, для примера, моего хабчика, и отключить его (echo -n '0000:00:14.0' > /sys/bus/pci/drivers/xhci_hcd/unbind) - я получаю немедленный фриз смерти, который (может уже от отчаянья) аналогичен таковому при неудачной перезагрузке.

Теперь вопрос к знатокам: где можно посмотреть/поправить порядок выключения при выключении/перезагрузке?

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

И в дополнение. Обнаружил что я ошибался, когда считал что если нету «unable to enumerate USB device» в dmesg, то с хабом всё в порядке. Нашел неприметные строки, которые может прольют немного света на это всё.

[  +0.009899] ehci-pci 0000:00:1d.0: can't setup: -110
[  +0.000346] ehci-pci 0000:00:1d.0: init 0000:00:1d.0 fail, -110

0000:00:1d.0 это тот самый хаб, для которого применяется скрипт. Может всё просто из-за него? Куда копать по этому поводу? Мрак.

В общем, для себя проблему я решил. Просто варварски избавляясь от проблемного хаба. В /etc/rc.local

[ -d "/sys/bus/pci/devices/0000:00:1d.0/" ] && {
        echo 1 > "/sys/bus/pci/devices/0000:00:1d.0/remove"
}

exit 0

Пока сколько и как бы не выключал/ребутил - ни единого разрывазависания. Может кому тоже так повезёт.