Я испытываю самую странную проблему прямо сейчас. Наутилус по существу не работает правильно теперь. Мой рабочий стол замораживается, нажимание и щелкание правой кнопкой не работают, я ничего не могу открыть в наутилусе и т.д. Это просто повреждается. Проблема состоит в том, что я не могу точно уничтожить его ни с чем.
while true; sudo killall -9 nautilus ; done
не уничтожает его.
Я не могу выйти из системы, потому что я прямо в середине длинной загрузки, и я не собираюсь уничтожать ее, если я могу помочь ей. Есть ли что-то, что я могу сделать для перезагрузки наутилуса без того, чтобы выходить из системы?
У меня была такая же проблема.
Не удалось перемонтировать один из внешних USB-накопителей из-за того, что «устройство занято».
lsof
обнаружил, что файл был открыт уже закрытым приложением.
ps
показал, что приложение все еще работает, несмотря на уже закрытое окно.
kill -9
также не работал с этим приложением.
Поскольку umount -f
также только что пожаловался, что устройство занято
, я, наконец, решил отключить USB-кабель внешнего накопителя.
В этот самый момент все ожидающие выполнения kill -9
s, казалось, имели место - и наутилус, и все еще работающее приложение закрылись и исчезли из моего вывода ps
.
Вы попробовали nautilus -q
уже?
Это выходит (и перезапуски) из наутилуса. Я использую его, когда это зависает или когда я должен "обновить" его после установки новых действий контекста наутилуса
К вашему сведению у меня была та же проблема. В моем случае это, кажется, вызывается дефектной точкой монтирования где-нибудь в моем дереве FS.
А именно, преступник был самбой, монтируются (cifs), который перестал работать из-за меня теряющий VPN. Поскольку наутилус упоминает их под 'Сетью' на левой боковой панели, я предполагаю, что это заставило это зависать. Как обходное решение я повторно смонтировался, все мои объемы (sudo монтируют-a), и теперь наутилус является быстро реагирующим снова.
Выполнение команды
killall nautilus
зафиксированный это для меня - это может помочь будущему посетителю.
Когда Наутилус перестал отвечать и не мог быть уничтожен, он оказалось, что у меня sshfs
завис. Так что это помогло убить его:
killall sshfs
Когда sshfs
зависает, это иногда приводит к зависанию файлового браузера таким образом, что его нельзя убить, но sshfs
все еще можно убит. Уничтожение sshfs
в этой ситуации позволяет убить (и перезапустить) файловый браузер. Иногда файловый браузер закрывается при завершении sshfs
; иногда он может даже начать реагировать немедленно, и его не нужно убивать.
Конечно, это не всегда работает, потому что зависание файлового браузера, такого как Nautilus, даже в конкретном описанном здесь сценарии, когда kill -9
было неэффективным, не всегда связано с проблемой. с sshfs
. Тем не менее, это, кажется, довольно распространенная причина проблемы.
Уничтожение sshfs
также останавливает другую активность файловой системы посредством монтирования sshfs
. Когда sshfs
работает со сбоями, вы, вероятно, захотите этого. Когда это не так, и какая-то другая проблема зависает в вашем файловом браузере, вы не можете.
Когда процесс не может быть остановлен, даже с помощью SIGKILL
, даже с правами суперпользователя — что здесь описывается в вопросе, происходящем с nautilus
— обычно это происходит потому, что процесс застрял в непрерываемом сне (см. также комментарий 3dGrabber).1
Это нормально, когда процесс переходит в непрерывный сон на очень короткие промежутки времени. Процессы взаимодействуют с ядром через системные вызовы. Некоторые системные вызовы во время выполнения не могут быть прерваны сигналами, поэтому любые сигналы, отправленные процессу, должны ожидать завершения системного вызова. Обычно это происходит, и тогда сигнал принимается. Но когда системный вызов, который не может быть прерван, зависает, процесс никогда не может получить сигнал, если только зависание не может быть остановлено каким-либо другим способом.
Уничтожение процесса достигается путем отправки ему сигнала. По умолчанию команда kill
отправляет SIGTERM
, который процессы могут обрабатывать по своему усмотрению и поэтому иногда неэффективны. Более жестким способом убить процесс является SIGKILL
(который отправляет kill -9
или kill -KILL
). Процессы не могут игнорировать SIGKILL
, , но они по-прежнему не получают его, находясь в непрерывном спящем режиме.
Частой причиной продолжительного непрерывного сна являются неисправные драйверы, в том числе драйверы файловой системы. Драйверы часто реализуются в виде модулей ядра, и хотя большинство модулей ядра можно загружать и выгружать, если один из них выходит из строя и не может завершить операцию, часто нет разумного и безопасного способа принудительно остановить его, продолжая использовать систему. Чтобы завершить процесс, который застрял в непрерывном спящем режиме, обычно необходимо перезагрузить компьютер. Драйверы
FUSE являются основным исключением.Когда они выходят из строя, вам часто не нужно перезагружаться. В FUSE детали доступа к файловой системе реализованы вне ядра, в обычной программе. Для доступа к данным в файловой системе FUSE программа по-прежнему будет выполнять системные вызовы, но ядро делегирует их через модуль FUSE программе-обработчику.
sshfs
— это драйвер файловой системы FUSE. При доступе к данным на монтировании sshfs
выполняется системный вызов, который делегирует работу процессу sshfs
. (За кулисами для монтирования файловой системы sshfs
был запущен /usr/bin/sshfs
. Или вы могли запустить команду sshfs
вручную.) В случае сбоя это может привести к тому, что программа, пытающаяся получить доступ к файловой системе sshfs
, останется в непрерывном спящем режиме, однако сам процесс sshfs
может оставаться неубиваемым. Когда этот процесс уничтожается, системный вызов прерывается, возвращая код ошибки, указывающий на сбой, и программа, выполнившая системный вызов, может завершиться или продолжить работу.
Неисправности, вызывающие продолжительный непрерывный сон, не уникальны для sshfs
. Они могут произойти с любой файловой системой, FUSE или нет, хотя, если это не FUSE файловая система, вам, вероятно, придется перезагрузиться. Существуют и другие часто используемые файловые системы FUSE, в которых это могло произойти, например ntfs-3g
. Это происходит нечасто ни с одной файловой системой, но на практике похоже, это происходит чаще с sshfs
, чем с большинством других файловых систем FUSE.
Любая программа, выполняющая системный вызов, использующий неисправный драйвер файловой системы, может столкнуться с этим. Но обычно вы, по крайней мере, пытаетесь получить доступ к файлу на монтировании sshfs
и, таким образом, имеете некоторое представление о том, что может быть не так. В отличие,файловые браузеры часто обращаются к данным за пределами того места, где вы сейчас работаете, чтобы избежать предоставления устаревшей информации о таких вещах, как, какие файловые системы в настоящее время смонтированы и сколько на них свободного места, а иногда и для получения информации в фоновом режиме для создания эскизов.
1 Еще один сценарий, в котором это может произойти, — когда это зомби-процесс. Однако, в отличие от процесса, застрявшего в непрерывном спящем режиме, процессы-зомби редко вызывают проблемы, поскольку единственный ресурс, который они занимают, — это строка в таблице процессов ядра. Процессы-зомби nautilus
обычно остаются незамеченными. В частности, это не должно мешать процессу nautilus
выполняться впоследствии от управления рабочим столом.