Файловый браузер и диалоговые окна файлов открываются долго или не открываются во всех приложениях

Я использую Ubuntu 20.04 с i3 в качестве оконного менеджера, но установленной подсистемой gnome.

У меня проблема, заключающаяся в том, что через некоторый случайный интервал (часы или дни) после перезагрузки любая попытка открыть thunar или nautilus или любая попытка приложения (например, Firefox) открыть диалоговое окно файла занимает минуту или больше, чтобы открыть, или просто время ожидания навсегда и требует, чтобы я убил приложение.

Как узнать, какое приложение, файл, расширение или драйвер вызывает эту задержку?

Я пробовал следующее:

  • Запуск от имени пользователя root - приложения работают нормально.
  • Отключить трекер (согласно здесь )
  • libgoa кажется актуальным ( согласно этому )
  • Попробовал взломать pulseaudio здесь
  • Выполняется наутилус со страсом; есть 30-секундный промежуток с нижеследующими строками, но я не уверен, как его интерпретировать (fd = 24 - это какой-то дескриптор файла?)
  • 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 .

  • Также как новый пользователь (также медленно): здесь
  • Как root (не медленно): здесь
6
задан 7 June 2021 в 14:07

3 ответа

У меня была такая же проблема в течение многих лет, потому что у меня довольно часто бывают перерывы в работе по крайней мере на месяц. Через некоторое время все программы, использующие системный диалог открытия файла, как бы зависают или ждут много минут.

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

2
ответ дан 28 July 2021 в 11:33

Диагностика

Думаю, вы показываете отрывок из журнала strace, указывающий на то, где происходит задержка. Было бы полезно, если бы вы разместили полную команду strace , которую вы использовали.

Действия, которые могут привести к виновнику:

  1. Пока работает strace d nautilus , в другом терминале используется

     $ pidof nautilus 
     $ lsof -p  
     

    где - это PID, возвращенный предыдущей командой. Это позволяет вам проверить, какие файловые дескрипторы (ответ на ваш вопрос : Да ) журнал strace ссылается на ( источник ). Возможно, вы захотите направить вывод по конвейеру с меньше , поскольку обычно он длинный.

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

  4. Примените вышеуказанные и любые другие диагностические команды к сравнению с тем, что корневой экземпляр (который вы упомянули , работает нормально ... , я полагаю, вы имели в виду ...порой там, где у обычного пользователя задержки уже появлялись ) выдает.

  5. Учтите, что проблема может быть связана с доступностью файловых дескрипторов и т.п., см. this .

  6. Пожалуйста, опубликуйте полный вывод команды

     $ bash -c 'time strace -fc nautilus' 
     $ bash -c 'time strace -fc thunar' 
     $ bash -c 'strace -fc time nautilus '
     $ bash -c' strace -fc time thunar '
     
  7. Пожалуйста, укажите, перемещали ли вы свой домашний каталог, если у вас была другая версия 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 , например

Связанные

  1. https://www.linuxquestions.org/questions/linux-server-73/strace-question-poll-taking-a-long-time-on-an-open-command-939714/
  2. Nautilus не запускается: .cache / tracker / meta.db not found
1
ответ дан 28 July 2021 в 11:33

Есть несколько вещей, которые могут замедлить работу Nautilus. Я видел, как это происходило с записными книжками, которые используются в основном для художественных работ и содержат - в буквальном смысле - миллионы файлов эскизов, находящихся в ~ / .cache / thumbnail . Очистка каталога немедленно повлияла на скорость запуска Nautilus (не говоря уже об освобождении немало места на диске).

Еще один элемент, на который следует обратить внимание, - это что-нибудь в ~ / .local / share / nautilus , которое может вызывать проблему, например поиск сетевого ресурса, который больше не доступен.

В качестве последней попытки, если у вас есть файл ~ / .cache / dconf / user , вы можете увидеть, есть ли проблемы с конфигурацией в настройках dconf для вашего учетная запись пользователя. Самый простой способ проверить это - переименовать ~ / .cache / dconf / user во что-то вроде ~ / .cache / dconf / user-old , а затем перезапустить оболочку, нажав Alt + F2 , чтобы вызвать ввод команды, введите r , затем нажмите Enter . Если проблема не исчезнет, ​​вы можете вернуть переименованный файл на его место.

Надеюсь, что-то здесь вам поможет.

1
ответ дан 28 July 2021 в 11:33

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

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