LINUX.ORG.RU
Форум — General  

Использование «удалённых файлов»

 


0

1

Всем доброго времени суток. При очередном обновлении, zypper ref && zypper dup && zypper ps отображается информация: 

Следующие запущенные процессы используют удаленные файлы:

PID  | PPID | UID  | Пользователь | Команда     | Сервис | Файлы                                         
-----+------+------+--------------+-------------+--------+-----------------------------------------------
2561 | 2553 | 1000 | user         | kwin_x11    |        | /memfd:JSVMStack:/usr/lib64/libQt5Qml.so.5    
     |      |      |              |             |        | /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5     
     |      |      |              |             |        | /memfd:JITCode:/usr/lib64/libQt5Qml.so.5      
     |      |      |              |             |        | /memfd:unknown-usage:/usr/lib64/libQt5Qml.so.5
2566 | 1    | 1000 | user         | krunner     |        | /memfd:JSVMStack:/usr/lib64/libQt5Qml.so.5    
     |      |      |              |             |        | /memfd:unknown-usage:/usr/lib64/libQt5Qml.so.5
     |      |      |              |             |        | /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5     
     |      |      |              |             |        | /memfd:JITCode:/usr/lib64/libQt5Qml.so.5      
2578 | 1    | 1000 | user         | plasmashell |        | /memfd:JSVMStack:/usr/lib64/libQt5Qml.so.5    
     |      |      |              |             |        | /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5     
     |      |      |              |             |        | /memfd:unknown-usage:/usr/lib64/libQt5Qml.so.5
     |      |      |              |             |        | /memfd:JITCode:/usr/lib64/libQt5Qml.so.5

Интересуют ответы на вопросы:

  1. Почему происходит использование этих файлов?
  2. Как помочь программам прекратить их использование? Сам для этого пробовал перезапустить их, путём перезагрузки компьютера.
  3. Следует подобные выводы обрабатывать при помощи команд вида kwin_x11 --replace, или достаточно перезагрузить компьютер?

Благодарю за внимание.

← Web-интерфейс для роутера на базе Debian/Ubuntu
Не работает переключение раслкдаки. Как завести? →

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

anonymous
()

Почему происходит использование этих файлов?

Одна программа использует файл, другая его удалила. Первая еще об этом не знает, "не отпускает" его (не отдает файловый дескриптор), система это видит и говорит что используется удаленный файл.

Как помочь программам прекратить их использование? Сам для этого пробовал перезапустить их, путём перезагрузки компьютера.

Ну в общем вариант перезапуска подходит, чем вас не устраивает?

Следует подобные выводы обрабатывать при помощи команд вида kwin_x11 --replace, или достаточно перезагрузить компьютер?

Да как вам удобнее. Вам важно чтоб приложение отпустило файлы, как вы это сделаете - отправкой определенного сигнала (если приложение это может), перезапуском приложения или перезагрузкой - без разницы. По сути пока вы не перезапустите свой kwin и вот это все, оно будет использовать старые либы. Вы же не для этого обновляетесь, верно? Но как поступить в этой ситуации - решать вам, можно и при следующем "плановом" рестарте чтоб это все запустилось как надо.

micronekodesu ★★★
()
Ответ на: комментарий от anonymous

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

Вас понял, спасибо за мнение.

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от micronekodesu

Одна программа использует файл, другая его удалила. Первая еще об этом не знает, «не отпускает» его (не отдает файловый дескриптор), система это видит и говорит что используется удаленный файл.

Это я могу понять. Хорошо.

Ну в общем вариант перезапуска подходит, чем вас не устраивает?

Мне удобнее выключить/включить компьютер в течении этого дня.

Да как вам удобнее. ....

Вы говорите понятные и хорошие вещи, благодарю вас. Однако, вы нигде не учитываете, иначе поправьте меня, что представленную информацию я вижу после перезагрузки, то есть после перезапуска программ. Именно об этом тема, по сути. Вот здесь я об этом говорю:

2. Как помочь программам прекратить их использование? Сам для этого пробовал перезапустить их, путём перезагрузки компьютера.

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

Значит это просто баг в этой васянской показывалке использования удалённых файлов.

anonymous
()
Ответ на: комментарий от openSUSE_Tumbleweed

Как помочь программам прекратить их использование? Сам для этого пробовал перезапустить их, путём перезагрузки компьютера.

Это делать в общем случае нельзя. Динамическое связывание происходит на этапе запуска программ, либо если сами программы подключают динамические библиотеки в процессе их работы. Это связывание патчит запрошенную память на предмет расстановки входов у используемых функций/переменных по косвенной адресации на реальные адреса, которые получились в результате отображения файла на память. Сложно? Ну так вы сами напросились на странную хочушку.

Радуйтесь, что в отличии от винды, хорошие ОС типа Linux не требуют перезагрузки системы при изменении версий библиотек для вновь запущенных программ.

vodz ★★★★★
()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от anonymous

Значит это просто баг в этой васянской показывалке использования удалённых файлов.

Думаете? Возможно. Однако, я всё же подожду ещё пару дней комментариев пользователей дистрибутива. Далее, если потребуется, напишу сообщение об ошибке.

П.С. Не может же так быть, что баг возник у меня одного.

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

Ты уникален, и твои проблемы уникальны. Привыкай к реалиям линукса. С вендой ты не уникален и с не уникальными проблемами встречаешься, только решать их тоже никто не станет. Как-нибудь, если баг всё ещё проявляется, через 10 лет можешь напомнить и исправят.

anonymous
()
Ответ на: комментарий от vodz

Это делать в общем случае нельзя. Динамическое связывание происходит на этапе запуска программ, либо если сами программы подключают динамические библиотеки в процессе их работы. Это связывание патчит запрошенную память на предмет расстановки входов у используемых функций/переменных по косвенной адресации на реальные адреса, которые получились в результате отображения файла на память. Сложно? Ну так вы сами напросились на странную хочушку.

Спасибо что откликнулись. Вы упоминаете использование динамических библиотек обозначенными программами, как советчик выше. Но, исходя из написанного в теме, этих файлов быть не должно. И всё же, к чему обращаются программы для «динамического связывания», если после перезагрузки этих файлов быть не должно? Далее, спускать эту ситуацию на тормозах мне не хочется. Что можно с этим сделать? Как можно повлиять, чтобы этот случай не повторился в дальнейшем?

П.С. Меня немного напрягает, что момент с перезагрузкой компьютера опускается в сообщениях. Это происходит из-за невнимательности комментирующих или я что-то упускаю по теме? Если я что-то упускаю, то что?

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от anonymous

Ты уникален, и твои проблемы уникальны. Привыкай к реалиям линукса. С вендой ты не уникален и с не уникальными проблемами встречаешься, только решать их тоже никто не станет. Как-нибудь, если баг всё ещё проявляется, через 10 лет можешь напомнить и исправят.

Вас понял, спасибо за мнение.

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

Изучай теорию.

http://ashep.org/2011/proverka-fs-i-vosstanovlenie-udalyonnyx-fajlov-v-linux/

«файл» — это лишь ссылка на индексный дескриптор файла (inode). Именно в inode хранится информация о физическом размещении файла. Когда вы удаляете файл, фактически вы просто удаляете ссылку на inode, в то время как сам дескриптор ещё какое-то время будет существовать: до тех пор, пока процесс, ранее открывший этот файл не освободит соответствующий дескриптор для записи.

greenman ★★★★★
()
Ответ на: комментарий от anonymous

Зачем гадать и надеяться на «ниможит быть»? Сам посмотри ls -l /proc/*/fd/*

Что особенного я там должен найти? Из особенного, grep memfd вижу только это: 

ls: невозможно получить доступ к '/proc/17282/fd/255': Нет такого файла или каталога
ls: невозможно получить доступ к '/proc/17282/fd/3': Нет такого файла или каталога
ls: невозможно получить доступ к '/proc/17283/fd/3': Нет такого файла или каталога
ls: невозможно получить доступ к '/proc/self/fd/255': Нет такого файла или каталога
ls: невозможно получить доступ к '/proc/self/fd/3': Нет такого файла или каталога
ls: невозможно получить доступ к '/proc/thread-self/fd/255': Нет такого файла или каталога
ls: невозможно получить доступ к '/proc/thread-self/fd/3': Нет такого файла или каталога
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:xshmfence (deleted)
/memfd:pulseaudio (deleted)

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

Ну вот, никаких libQtCore и тд. Значит твоя предыдущая васянская показывалка удалённых файлов просто глючит, как я и говорил.

anonymous
()
Ответ на: комментарий от anonymous

А memfd и должны использоваться удалёнными, так работает шаренная память.

anonymous
()
Ответ на: комментарий от openSUSE_Tumbleweed

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

Elyas ★★★★★
()
Ответ на: комментарий от greenman

Изучай теорию.
http://ashep.org/2011/proverka-fs-i-vosstanovlenie-udalyonnyx-fajlov-v-linux/

Благодарю за информацию. При выполнении, например, ls /proc/3753/fd (kwin_x11) вижу следующее, по существу: 

0 -> 'pipe:[38154]'
1 -> /home/user/.local/share/sddm/xorg-session.log
10 -> anon_inode:inotify
11 -> 'socket:[38976]'
12 -> 'anon_inode:[eventfd]'
13 -> 'socket:[37714]'
14 -> /dev/dri/renderD128
15 -> 'anon_inode:[eventfd]'
16 -> anon_inode:inotify
17 -> anon_inode:inotify
2 -> /home/user/.local/share/sddm/xorg-session.log
20 -> '/tmp/#918012 (deleted)'
3 -> 'socket:[36396]'
4 -> 'anon_inode:[eventfd]'
5 -> 'anon_inode:[eventfd]'
6 -> 'socket:[36398]'
7 -> 'anon_inode:[eventfd]'
8 -> 'socket:[37381]'
9 -> 'socket:[37391]'

Нету ничего о libQt5Qml.so. Или я не_туда/не_так смотрю?

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от Elyas

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

Если только процесс «удаление файла» или его этап протекает после перезагрузки, в рамках обслуживания файловой системы. Это разве так?

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

Нету ничего о libQt5Qml.so.

А кто обещал, что будет видно имя файла?

http://www.linuxcenter.ru/lib/books/posixbook/ch08.phtml

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

В третьих, удаление файлов в Unix происходит совершенно иначе, чем в DOS/Windows. А именно, файл считается удаленным, когда уничтожены все имена, ссылающиеся на идентификатор данного inode (то есть файл исключен из файловой системы), и закрыта последняя программа, к нему обращающаяся (то есть завершен процесс, загрузивший данные файла в память, и уничтожен индексный дескриптор файла в этом процессе). В описании атрибутов файла это выражается в том, что счетчик ссылок его inode обнуляется. Разумеется, сами по себе данные, составляющие содержание файла, физически могут продолжать существовать на диске, но для системы они уже недоступны. А поскольку содержание файла оторвано от его имени, восстановление случайно удаленного файла по фрагменту имени (на чем основаны DOS-утилиты типа UNERASE и UNDELETE) оказывается невозможным.

Пока любой файл открыт, то есть существует ссылающийся на него процесс, он продолжает существовать, даже если имя его исключено из всех каталогов, и может быть записан, скопирован, переименован, и т.д. То есть открытый каким либо процессом дескриптор данного файла - гарантия его существования, по крайней мере до завершения процесса. Именно поэтому я ранее сказал, что файл не обязательно имеет имя: в случае удаления открытого файла из каталога он некоторое время существует как бы безымянным, для поддержания его бытия достаточно открытого дескриптора, ассоциированного с inode.

Кстати, очень советую прочитать эту книгу
(Введение в POSIX'ивизм (C) Алексей Федорчук, 2005)
полностью.

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от openSUSE_Tumbleweed

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

Elyas ★★★★★
()
Ответ на: комментарий от greenman

Кстати, очень советую прочитать эту книгу
(Введение в POSIX'ивизм (C) Алексей Федорчук, 2005)
полностью.

Благодарю за рекомендацию таким способом, обязательно уделю ей внимание в течении 2019 года.

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от anonymous

Например (kwin_x11), cat /proc/3753/maps | grep libQt5Qml.so.5 отображает примерно следующее: 

75749                      /memfd:unknown-usage:/usr/lib64/libQt5Qml.so.5 (deleted)
53598                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
51168                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
52348                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
51871                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
51870                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
51869                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
51868                      /memfd:unknown-usage:/usr/lib64/libQt5Qml.so.5 (deleted)
51867                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
51866                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
52345                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
52344                      /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
52336                      /memfd:unknown-usage:/usr/lib64/libQt5Qml.so.5 (deleted)
887618                     /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
1133222                    /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
902428                     /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
902427                     /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
606865                     /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
713666                     /memfd:JITCode:/usr/lib64/libQt5Qml.so.5 (deleted)
37443                      /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5 (deleted)
37443                      /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5 (deleted)
37443                      /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5 (deleted)
37443                      /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5 (deleted)
37443                      /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5 (deleted)
37443                      /memfd:JSGCHeap:/usr/lib64/libQt5Qml.so.5 (deleted)
37442                      /memfd:JSVMStack:/usr/lib64/libQt5Qml.so.5 (deleted)
37441                      /memfd:JSVMStack:/usr/lib64/libQt5Qml.so.5 (deleted)
37445                      /memfd:unknown-usage:/usr/lib64/libQt5Qml.so.5 (deleted)
2262294                    /usr/lib64/libQt5Qml.so.5.12.0
2262294                    /usr/lib64/libQt5Qml.so.5.12.0
2262294                    /usr/lib64/libQt5Qml.so.5.12.0
2262294                    /usr/lib64/libQt5Qml.so.5.12.0
2262294                    /usr/lib64/libQt5Qml.so.5.12.0
2262294                    /usr/lib64/libQt5Qml.so.5.12.0

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

И всё же, к чему обращаются программы для «динамического связывания», если после перезагрузки этих файлов быть не должно?

Какой-то набор слов. Загрузка сегментов на выполнение означает открытие файла и его отображение на память. После открытия файла и при его удалении удаляется запись в спец файле под названием «каталог», в котором есть запись «номер инода - имя», но пока файл кем-либо открыт, сам инод остаётся занятым и из файловой системы не удаляется, то есть занятые им блоки не переходят в разряд свободных. При перезгрузки убиваются все процессы, потому все занятые иноды освобождаются. Если перезагрузка внезапна по каким-либо причинам, то нужно либо парсить логи ФС с логированием, либо, что лучше, прогонять лечилку ФС, которая найдёт такие подвисшие иноды, то есть те, которые не записаны в каком-либо каталоге.

vodz ★★★★★
()
Ответ на: комментарий от greenman

lsof | grep libQt5Qml.so

Мне казалось оно, lsof | grep kwin | grep libQt5Qml.so.5 ничего не покажет мне, а тут аж целая простыня: https://pastebin.com/7xVK7Gm6.

П.С. Может показаться, что я ничего не делаю, но я параллельно гуглю и пытаюсь разобрать man lsof.

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от vodz

Какой-то набор слов.

Приношу свои извинения за своё делитанство, я имел ввиду, что «При перезгрузки убиваются все процессы, потому все занятые иноды освобождаются.».

Если перезагрузка внезапна

Это единственный случай, когда возможна такая ситуация?

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от greenman

А кто обещал, что будет видно имя файла?

zypper ps показывает вполне очевидные вещи, вроде.

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

20 -> '/tmp/#918012 (deleted)'

Кто-то может прокомментировать эту строку?

lsof | grep kwin | grep '/tmp/#918012' показывает: 

kwin_x11   3753                         user       DEL       REG              254,2               918012 /tmp/#918012
kwin_x11   3753                         user        20u      REG              254,2     65536     918012 /tmp/#918012 (deleted)
kwin_x11   3753  3783 QXcbEvent         user       DEL       REG              254,2               918012 /tmp/#918012
kwin_x11   3753  3783 QXcbEvent         user        20u      REG              254,2     65536     918012 /tmp/#918012 (deleted)
kwin_x11   3753  3786 QDBusConn         user       DEL       REG              254,2               918012 /tmp/#918012
kwin_x11   3753  3786 QDBusConn         user        20u      REG              254,2     65536     918012 /tmp/#918012 (deleted)
kwin_x11   3753  3837 QQmlThrea         user       DEL       REG              254,2               918012 /tmp/#918012
kwin_x11   3753  3837 QQmlThrea         user        20u      REG              254,2     65536     918012 /tmp/#918012 (deleted)
kwin_x11   3753  3902 kwin_x1:d         user       DEL       REG              254,2               918012 /tmp/#918012
kwin_x11   3753  3902 kwin_x1:d         user        20u      REG              254,2     65536     918012 /tmp/#918012 (deleted)
kwin_x11   3753  3919 kwin_x11          user       DEL       REG              254,2               918012 /tmp/#918012
kwin_x11   3753  3919 kwin_x11          user        20u      REG              254,2     65536     918012 /tmp/#918012 (deleted)
kwin_x11   3753  9727 FreezeDet         user       DEL       REG              254,2               918012 /tmp/#918012
kwin_x11   3753  9727 FreezeDet         user        20u      REG              254,2     65536     918012 /tmp/#918012 (deleted)

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

Это единственный случай, когда возможна такая ситуация?

Такая — это FS в неконсистентном состоянии? Да, только внезапное отключение. Ну ещё глюки в ядре, но это уже совсем...

vodz ★★★★★
()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

Воспользовался fsck. Были проблемы на разделах, но теперь ситуация исправилась. При этом запущенные процессы всё так же используют удалённые файлы. Что можно сделать с этим?(

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

Это нормальная практика, создавать временный файл, открывать его и удалять, чтобы никто другой его не видел.

anonymous
()
Ответ на: комментарий от openSUSE_Tumbleweed

Воспользовался fsck. Были проблемы на разделах, но теперь ситуация исправилась.

Надеюсь, вы запускали в монопольном режиме?

При этом запущенные процессы всё так же используют удалённые файлы.

Но теперь то это динамические библиотеки или всё-таки файлы, которые в /tmp или в рабочих каталогах программ?

Что можно сделать с этим?

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

vodz ★★★★★
()
Ответ на: комментарий от vodz

Надеюсь, вы запускали в монопольном режиме?

Я использовал live usb stick.

... монопольном ...

Вот интересно, где-то есть де-факто глоссарий для терминов?

Но теперь то это динамические библиотеки или всё-таки файлы, которые в /tmp или в рабочих каталогах программ?

Для меня в рамках деятельности с Linux всё будет называться файлом, и пока не вижу причин это менять. Возможно, позднее.

Вам уже много раз, в том числе и я уже сказали, что это не является проблемой.

Для меня это не так. Мне досаждает подобная информация, да ещё в таком виде.

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

И зачем же доводить до такого? Я предпочитаю разбираться заранее, когда это возможно. Никому такое поведение не навязываю. К слову, нижеследующие комментарии не соответствуют действительности (речь о редакциях Leap и Tumbleweed):

Оба дистрибутива хорошо протестированы как openQA, так и участниками openSUSE, так что на обоих можно положиться в работе.
Оба дистрибутива отлично подходят для использования на настольном ПК, …

На Leap я такого поведения системы не припомню.

По итогу темы: проблема осталась открыта. Поскольку активных пользователей дистрибутива здесь мало, в то время как он выкидывает такие фокусы, решено использовать Debian.

Большое спасибо всем активным участникам форума, которые пытались помочь в меру своих возможностей. Отдельное благодарность greenman, за литературу.

openSUSE_Tumbleweed
() автор топика
Ответ на: комментарий от openSUSE_Tumbleweed

нижеследующие комментарии не соответствуют действительности

и что в них не так?

решено использовать Debian

это очень странное решение, поменять TW на Debian, учитывая, что и там такое встречается: https://unix.stackexchange.com/questions/383256/deleted-files-still-in-use-me...

kott ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Web-интерфейс для роутера на базе Debian/Ubuntu
General
Не работает переключение раслкдаки. Как завести? →