Наутилус замораживается, не может использоваться и не может быть уничтожен

Я испытываю самую странную проблему прямо сейчас. Наутилус по существу не работает правильно теперь. Мой рабочий стол замораживается, нажимание и щелкание правой кнопкой не работают, я ничего не могу открыть в наутилусе и т.д. Это просто повреждается. Проблема состоит в том, что я не могу точно уничтожить его ни с чем.

while true; sudo killall -9 nautilus ; done не уничтожает его.

Я не могу выйти из системы, потому что я прямо в середине длинной загрузки, и я не собираюсь уничтожать ее, если я могу помочь ей. Есть ли что-то, что я могу сделать для перезагрузки наутилуса без того, чтобы выходить из системы?

7
задан 30 August 2011 в 16:55

5 ответов

У меня была такая же проблема.

Не удалось перемонтировать один из внешних USB-накопителей из-за того, что «устройство занято».

lsof обнаружил, что файл был открыт уже закрытым приложением.

ps показал, что приложение все еще работает, несмотря на уже закрытое окно.

kill -9 также не работал с этим приложением.

Поскольку umount -f также только что пожаловался, что устройство занято , я, наконец, решил отключить USB-кабель внешнего накопителя.

В этот самый момент все ожидающие выполнения kill -9 s, казалось, имели место - и наутилус, и все еще работающее приложение закрылись и исчезли из моего вывода ps .

2
ответ дан 20 December 2013 в 00:12

Вы попробовали nautilus -q уже?

Это выходит (и перезапуски) из наутилуса. Я использую его, когда это зависает или когда я должен "обновить" его после установки новых действий контекста наутилуса

1
ответ дан 23 November 2019 в 06:31

К вашему сведению у меня была та же проблема. В моем случае это, кажется, вызывается дефектной точкой монтирования где-нибудь в моем дереве FS.

А именно, преступник был самбой, монтируются (cifs), который перестал работать из-за меня теряющий VPN. Поскольку наутилус упоминает их под 'Сетью' на левой боковой панели, я предполагаю, что это заставило это зависать. Как обходное решение я повторно смонтировался, все мои объемы (sudo монтируют-a), и теперь наутилус является быстро реагирующим снова.

5
ответ дан 23 November 2019 в 06:31

Выполнение команды

killall nautilus

зафиксированный это для меня - это может помочь будущему посетителю.

3
ответ дан 23 November 2019 в 06:31

Когда Наутилус перестал отвечать и не мог быть уничтожен, он оказалось, что у меня 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 выполняться впоследствии от управления рабочим столом.

4
ответ дан 14 May 2020 в 09:31

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

Похожие вопросы: