Я использую Ubuntu 20.04 с i3 в качестве оконного менеджера, но установленной подсистемой gnome.
У меня проблема, заключающаяся в том, что через некоторый случайный интервал (часы или дни) после перезагрузки любая попытка открыть thunar или nautilus или любая попытка приложения (например, Firefox) открыть диалоговое окно файла занимает минуту или больше, чтобы открыть, или просто время ожидания навсегда и требует, чтобы я убил приложение.
Как узнать, какое приложение, файл, расширение или драйвер вызывает эту задержку?
Я пробовал следующее:
journalctl
показывает ниже, когда (например) nautilus, наконец, работает У меня есть несколько машин с очень похожими настройками, только у одной такое поведение. Я не могу понять, какое приложение или библиотека является виновником.
Вывод strace -t -o / tmp / nautilus nautilus
:
20:15:32 write(24, "\1\0\0\0\0\0\0\0", 8) = 8
20:15:32 poll([{fd=24, events=POLLIN}], 1, 0) = 1 ([{fd=24, revents=POLLIN}])
20:15:32 read(24, "\1\0\0\0\0\0\0\0", 16) = 8
20:15:32 write(24, "\1\0\0\0\0\0\0\0", 8) = 8
20:15:32 futex(0x56241fa9c880, FUTEX_WAKE_PRIVATE, 2147483647) = 0
20:15:32 close(24) = 0
20:15:32 eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK) = 24
20:15:32 write(24, "\1\0\0\0\0\0\0\0", 8) = 8
20:15:32 write(6, "\1\0\0\0\0\0\0\0", 8) = 8
20:15:32 futex(0x56241ef26dc0, FUTEX_WAKE_PRIVATE, 1) = 1
20:15:32 futex(0x56241ef26910, FUTEX_WAKE_PRIVATE, 1) = 1
20:15:32 futex(0x56241ef1c038, FUTEX_WAKE_PRIVATE, 1) = 1
20:15:32 poll([{fd=24, events=POLLIN}], 1, 25000) = 1 ([{fd=24, revents=POLLIN}])
20:15:32 read(24, "\1\0\0\0\0\0\0\0", 16) = 8
20:15:32 poll([{fd=24, events=POLLIN}], 1, 25000) = 0 (Timeout)
20:15:57 write(24, "\1\0\0\0\0\0\0\0", 8) = 8
20:15:57 futex(0x56241fa9c880, FUTEX_WAKE_PRIVATE, 2147483647) = 0
20:15:57 close(24) = 0
Из журнала:
Apr 20 20:32:35 aubrey dbus-daemon[1180]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.134190' (uid=1000 pid=1450204 comm="nautilus " label="unconfined")
Apr 20 20:32:35 aubrey systemd[1]: Starting Hostname Service...
Apr 20 20:32:35 aubrey dbus-daemon[1180]: [system] Successfully activated service 'org.freedesktop.hostname1'
Apr 20 20:32:35 aubrey systemd[1]: Started Hostname Service.
Apr 20 20:32:35 aubrey nautilus[1450204]: Called "net usershare info" but it failed: Failed to execute child process “net” (No such file or directory)
Apr 20 20:32:45 aubrey ddclient[1450366]: WARNING: file /var/cache/ddclient/ddclient.cache, line 3: Invalid Value for keyword 'ip' =
Редактировать:
Вышеупомянутый след - это просто вывод strace - t -o / tmp / nautilus nautilus
- очень подробный журнал, но с tail -f
я могу проверить его там, где он зависает, и именно здесь я вижу такую запись как 20:15:32 опрос ([{fd = 7, events = POLLIN}], 1, 25000) = 0 (Тайм-аут)
, за которым следуют 30+ секунд ничего (затем он начинается и очень подробный опять таки).
fd, о котором сообщает lsof, если я правильно его понимаю, выглядит так:
nautilus 1719429 coljac 7u a_inode 0,13 0 17491 [eventfd]
Лучшие записи из strace -c nautilus
следующие (да, опрос - номер один):
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
22.70 0.011333 2 3988 poll
16.55 0.008265 1 5018 4490 stat
9.31 0.004647 2 1966 131 futex
7.73 0.003859 1 2119 1385 recvmsg
7.33 0.003660 1 3612 1441 openat
4.76 0.002375 2 1038 436 access
4.29 0.002140 1 1424 read
3.60 0.001799 1 1356 105 readlink
3.50 0.001748 0 1868 mmap
3.30 0.001646 8 188 getdents64
3.14 0.001568 0 2232 close
2.38 0.001188 0 1758 fstat
2.14 0.001067 0 1150 munmap
1.99 0.000993 2 337 writev
1.67 0.000833 92 9 clone
1.57 0.000782 2 367 write
1.47 0.000733 3 190 mprotect
Вывод из lsof | wc -l
: 1340334
Редактировать 2:
В настоящее время thunar не открывается вообще - происходит сбой с сообщением Не удалось зарегистрироваться: истекло время ожидания
. Вывод команды strace -c thunar
выглядит следующим образом:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
50.53 0.002814 3 882 792 openat
28.21 0.001571 4 354 mmap
4.79 0.000267 2 96 read
3.75 0.000209 2 90 fstat
3.54 0.000197 2 96 close
3.48 0.000194 1 109 mprotect
1.87 0.000104 5 18 poll
1.45 0.000081 0 165 1 futex
1.31 0.000073 2 28 write
...
Если я запускаю strace -t thunar
, я также вижу это в выводе до того, как он зависнет:
futex(0x564445b9ff70, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=7, events=POLLIN}], 1, 25000) = 1 ([{fd=7, revents=POLLIN}])
read(7, "\1\0\0\0\0\0\0\0", 16) = 8
poll([{fd=7, events=POLLIN}], 1, 25000
lsof -p
возвращает следующее:
thunar 2036483 coljac 7u a_inode 0,13 0 17491 [eventfd]
Еще один выход из strace thunar
, который не открывается, это:
20:29:32 read(7, "\1\0\0\0\0\0\0\0", 16) = 8
20:29:32 poll([{fd=7, events=POLLIN}], 1, 25000) = 0 (Timeout)
20:29:58 write(7, "\1\0\0\0\0\0\0\0", 8) = 8
20:29:58 futex(0x5566ad906ba0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
20:29:58 close(7) = 0
20:29:58 write(6, "\1\0\0\0\0\0\0\0", 8) = 8
20:29:58 futex(0x5566ad8e1f70, FUTEX_WAKE_PRIVATE, 1) = 1
20:29:58 futex(0x5566ad8e1b90, FUTEX_WAKE_PRIVATE, 1) = 1
20:29:58 futex(0x5566ad8d9058, FUTEX_WAKE_PRIVATE, 1) = 1
20:29:58 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/charset.alias", O_RDONLY) = -1 ENOENT (No such file or directory)
20:29:58 write(2, "Failed to register: Timeout was "..., 40) = 40
20:29:58 poll([{fd=4, events=POLLIN}], 1, 0) = 1 ([{fd=4, revents=POLLIN}])
20:29:58 read(4, "\1\0\0\0\0\0\0\0", 16) = 8
20:29:58 futex(0x7f0dccfb72a0, FUTEX_WAKE_PRIVATE, 1) = 1
20:29:58 poll([{fd=4, events=POLLIN}], 1, 0) = 0 (Timeout)
Дополнительные выходные данные strace находятся здесь, на pastebin .
У меня была такая же проблема в течение многих лет, потому что у меня довольно часто бывают перерывы в работе по крайней мере на месяц. Через некоторое время все программы, использующие системный диалог открытия файла, как бы зависают или ждут много минут.
pkill gvfsd-trash
Должно исправить проблему, и все программы, зависающие и ожидающие диалог открытия файла, должны немедленно возобновить работу после уничтожения gvfsd-trash
.
Еще одно замечание: gvfsd-trash
перезапускается через некоторое время, возможно, caja
или любой другой файловый браузер, или сам системный диалог открытия файлов. Это не первая проблема с gvfsd-trash
, и я начинаю затаивать обиду, однако, я не хочу удалять gvfsd
, который мне нужен для монтирования USB флешек и смартфона по MTP. Поэтому я выбрал решение методом грубой силы и сделал недоступным только двоичный файл gvfsd-trash
, например, переименовав его:
sudo mv /usr/libexec/{gvfsd-trash,.bak}
Он может находиться в другом месте на разных системах, попробуйте спросить менеджера пакетов, например, позвонив по телефону:
dpkg -L gvfs-daemons | grep trash
Остерегайтесь последствий. Без gvfsd-trash
вы не сможете получить доступ к специальному пути trash:///
URI через файловый браузер! Лично я никогда этим не пользовался. Вы также можете получить доступ к удаленным файлам вручную в папках .Trash
, которые существуют для каждой точки монтирования и в вашем доме, например:
~/.local/share/Trash
/media/mounted-external-harddrive/.Trash
Похоже, что проблема заключается в комбинации gvfsd-trash и D-Bus. Похоже, что в багтрекере gvfs есть соответствующая проблема, которая уже исправлена, но еще не распространена на мою систему.
В течение многих лет я использовал другое решение, а именно запуск каждой программы в новом сеансе DBus с префиксом dbus-launch
для наиболее важных программ, таких как Firefox и текстовые редакторы. Однако, это влечет за собой ряд проблем, поскольку каждый сеанс порождает как минимум пять процессов gvfsd
и, возможно, другие, и сеанс D-Bus не закрывается, закрывая открытую в нем программу, а количество сеансов D-Bus в целом ограничено, поэтому через некоторое время вы не сможете запускать программы.
Думаю, вы показываете отрывок из журнала strace, указывающий на то, где происходит задержка. Было бы полезно, если бы вы разместили полную команду strace
, которую вы использовали.
Действия, которые могут привести к виновнику:
Пока работает strace
d nautilus
, в другом терминале используется
$ pidof nautilus
$ lsof -p
где
- это PID, возвращенный предыдущей командой.
Это позволяет вам проверить, какие файловые дескрипторы (ответ на ваш вопрос : Да ) журнал strace ссылается на ( источник ). Возможно, вы захотите направить вывод по конвейеру с меньше
, поскольку обычно он длинный.
Опция -c
может дополнительно помочь в выявлении узких мест ( источник ), вероятно, ваш опрос
. Со страницы man strace
:
-c
- только сводка
Подсчитывать время, количество вызовов и ошибок для каждого системного вызова и сообщать сводку при выходе из программы , подавление обычного вывода
. Это пытается показать системное время (время процессора, затраченное на работу в ядре) независимо от времени настенных часов.
Если -c используется с -f, сохраняются только общие итоги для всех отслеживаемых процессов.
Это пример того, как выглядят выходные данные
% времени в секундах usecs / call calls errors syscall
------ ----------- --- -------- --------- --------- ----------------
18,29 0,009128 4 2058 mmap
15,19 0,007580 7 989 1 опрос
11,96 0,005967 2 2465 318 openat
6,76 0,003374 1 2187 закрыть
...
Проверьте другие случаи отложенного запуска наутилуса и луны, чтобы подтвердить аналогичную закономерность.
Примените вышеуказанные и любые другие диагностические команды к сравнению с тем, что корневой экземпляр (который вы упомянули , работает нормально ... , я полагаю, вы имели в виду ...порой там, где у обычного пользователя задержки уже появлялись ) выдает.
Учтите, что проблема может быть связана с доступностью файловых дескрипторов и т.п., см. this .
Пожалуйста, опубликуйте полный вывод команды
$ bash -c 'time strace -fc nautilus'
$ bash -c 'time strace -fc thunar'
$ bash -c 'strace -fc time nautilus '
$ bash -c' strace -fc time thunar '
Пожалуйста, укажите, перемещали ли вы свой домашний каталог, если у вас была другая версия Ubuntu и была ли она обновлена, и т. д. , так как может быть актуальным . Также попробуйте создать временного пользователя, чтобы увидеть, появится ли проблема. Это было бы дополнительным доказательством сравнения с root.
ИЗМЕНИТЬ : сравнение того, что вы получаете, с пользователями
, tester
и root
, для bash -c 'time strace -fc nautilus'
показывает следующую существенную разницу в том, что может тратить ~ 30 секунд при запуске:
:
(org.gnome.Nautilus: 2641915 ): Tracker-WARNING **: 18: 30: 21.999: Возврат
к серверной части шины, прямой сервер не удалось инициализировать: не удалось найти файл данных
ase file: '/ home / coljac / .cache / tracker / meta.db '.
tester
:
(org.gnome.Nautilus: 2976790): dbind-WARNING **: 20: 45: 38.814: Не удалось' t зарегистрироваться в шине доступности: не получил ответа. Возможные причины: удаленное приложение не отправило ответ, политика безопасности шины сообщений заблокировала ответ, истекло время ожидания ответа или было разорвано сетевое соединение.
strace: Процесс 2976919 прикреплен
strace: Процесс 2976920 прикреплен
** (org.gnome.Nautilus: 2976790): ПРЕДУПРЕЖДЕНИЕ **: 20:46: 04.102: Невозможно получить содержимое файла закладок: Ошибка при открытии файла /home/tester/.gtk-bookmarks: Нет такого файла или каталога
root
:
** (org. gnome.Nautilus: 2980894): ПРЕДУПРЕЖДЕНИЕ **: 21: 00: 42.191: Невозможно получить содержимое файла закладок: Ошибка при открытии файла /root/.gtk-закладки: нет такого файла или каталога
** (org.gnome.Nautilus: 2980894): ПРЕДУПРЕЖДЕНИЕ **: 21: 00: 42.191: невозможно получить содержимое файла закладок: ошибка открытия файл /root/.gtk-bookmarks: Нет такого файла или каталога
strace: Процесс 2980907 прикреплен
Nautilus-Share-Message: 21: 00: 42.241: Вызывается "net usershare info", но это не удалось : Не удалось выполнить дочерний процесс «net» (такого файла или каталога нет)
Итак, тестер
vs. root
показывает предупреждение, которое может помочь с диагностикой . Странно то, что такое же предупреждение не отображается для
.
Я бы подождал, пока вы не опубликуете дополнительную информацию после предложенного диагноза.
А пока я предлагаю (ядерное оружие?) Обходной путь.
Я предполагаю, что ваши "несколько машин" с очень похожими настройками "являются своего рода клонами (по крайней мере, вначале) друг друга.
Если это так, и вы не найдете решения (после диагностики) ), и это вас достаточно беспокоит, вы можете попробовать снова клонировать из одной из ваших рабочих систем с помощью clonezilla
, например
Есть несколько вещей, которые могут замедлить работу Nautilus. Я видел, как это происходило с записными книжками, которые используются в основном для художественных работ и содержат - в буквальном смысле - миллионы файлов эскизов, находящихся в ~ / .cache / thumbnail
. Очистка каталога немедленно повлияла на скорость запуска Nautilus (не говоря уже об освобождении немало места на диске).
Еще один элемент, на который следует обратить внимание, - это что-нибудь в ~ / .local / share / nautilus
, которое может вызывать проблему, например поиск сетевого ресурса, который больше не доступен.
В качестве последней попытки, если у вас есть файл ~ / .cache / dconf / user
, вы можете увидеть, есть ли проблемы с конфигурацией в настройках dconf
для вашего учетная запись пользователя. Самый простой способ проверить это - переименовать ~ / .cache / dconf / user
во что-то вроде ~ / .cache / dconf / user-old
, а затем перезапустить оболочку, нажав Alt + F2 , чтобы вызвать ввод команды, введите r
, затем нажмите Enter . Если проблема не исчезнет, вы можете вернуть переименованный файл на его место.
Надеюсь, что-то здесь вам поможет.