Morisson
А как это?
Согласно DOC - с помощью systemd юниты монтирования можно настроить либо через файлы юнитов, либо через /etc/fstab.
Как пишут, настройка точек монтирования через /etc/fstab является предпочтительным подходом … хотя этот нюанс спорный - кому то проще отредактировать fstab, а кому то проще отредактировать соотвествующие юниты монтирования ... ну а если устраивают дефолтные настройки, то можно вообще ничего не редактировать и не создавать файл fstab.

PS - рекомендую проверить - переименуй fstab или перемести его в другое место ... и reboot
Ошибки не исчезают с опытом - они просто умнеют
А я вообще не использую fstab - просто он мне не нужен.
Файл то имеется, но он пустой, который создается автоматически при отсутствии оного
cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
Ошибки не исчезают с опытом - они просто умнеют
yurius
не вижу никаких проблем со входом. Через экран lxdm вхожу, пользователь "yurius".
Просто есть нюансы при входе - выходе - последующем входе
Привожу ссылку из DOC (без перевода)
The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed. If the user logs in more than once he should get pointed to the same directory, and it is mandatory that the directory continues to exist from his first login to his last logout on the system, and not removed in between. Files in the directory MUST not survive reboot or a full logout/login cycle.
Ошибки не исчезают с опытом - они просто умнеют
yurius
всё остальное в системе работало отлично, как всегда.
Да оно и будет работать, за исключением некоторых программ - а учитывая, что переменную подправил, то проблем вообще быть не должно.
Забудь ... просто причина проблемы интересна для ликбеза.
Ошибки не исчезают с опытом - они просто умнеют
Согласно определения DOC (перевод)
$XDG_RUNTIME_DIR определяет базовый каталог, относительно которого должны храниться специфические для пользователя несущественные файлы среды выполнения и другие файловые объекты (такие как сокеты, именованные каналы и т.д.). Каталог ДОЛЖЕН принадлежать пользователю, и он ДОЛЖЕН быть единственным, кто имеет доступ к нему для чтения и записи. Его режим доступа Unix ДОЛЖЕН быть 0700.
А простым языком - $XDG_RUNTIME_DIR есть переменная окружения, которая устанавливается автоматически при входе в систему. Она сообщает любой запущенной программе, где найти пользовательский каталог, в котором можно хранить небольшие временные файлы. А так как эта переменная устанавливается при входе в систему, то имеется прямая связь с pam_systemd.

Что можно предположить?
- не корректно выполняется вход в систему
- не правильно определены права доступа к данному каталогу (stat -c%a /run/user/1000  ...  700)
- что то еще не ведомое ...
Ошибки не исчезают с опытом - они просто умнеют
yurius
сделал на ПК так, а на ноуте - алиас создал. И там и там работает.
алиас работает только для запуска pavucontrol, а проблема с переменной окружения XDG_RUNTIME_DIR может проявиться и еще где то, так что лучше изменить значение этой переменной.
Ошибки не исчезают с опытом - они просто умнеют
yurius
Собственно, это наверное и есть РЕШЕНИЕ?
Можно и так, но лучше найти где накосячено.
У тебя не правильно определяется переменная окружения XDG_RUNTIME_DIR
По феншею, конечно, лучше найти этот косяк. ... но можно пойти и другим путем
В файле ~/.bashrc добавь строку export XDG_RUNTIME_DIR=/run/user/1000, а чтобы не перегружаться, выполни команду source ~/.bashrc и проверь, что получилось - env | grep XDG_RUNTIME_DIR - должен получить XDG_RUNTIME_DIR=/run/user/1000 .... если получил, запускай pavucontrol

Но, конечно, повторюсь, по феншею лучше найти где накосячено

EDIT - Эксперимент - меняю переменную XDG_RUNTIME_DIR и получаю как у тебя (изменил через файл ~/.bashrc)
env | grep XDG_RUNTIME_DIR
XDG_RUNTIME_DIR=/run/user
pavucontrol … и получаю
XDG_RUNTIME_DIR (/run/user) принадлежит не данному пользователю (uid 1000), а пользователю с uid 0. (Это может происходить, например, в случае подключения от имени администратора к серверу PulseAudio, запущенному от имени обычного пользователя, по родному протоколу. Не делайте так.)
Ошибки не исчезают с опытом - они просто умнеют
yurius
однако остальное не поменялось
Вообщем то это и ожидалось.
Это наблюдалось и раньше? или появилось недавно?
Ошибки не исчезают с опытом - они просто умнеют
На вскидку заметил пока один нюанс, но это к проблеме отношения иметь не должно
yurius
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled;
должно быть enabled
По этой причине тебе и приходилось заниматься ерундой
yurius
$ pulseaudio –check
pulseaudio -D
Выполни команду: systemctl enable --user pulseaudio ..... перегрузись и проверь systemctl status --user pulseaudio и pactl info
Демон должен быть запущен автоматом ... а вот если будут проблемы со стартом pavucontrol, то нужно будет копать основательно.
Ошибки не исчезают с опытом - они просто умнеют
yurius
Connection failure: Connection refused
смотри - pulseaudio или не запущен вообще или запущен от другого пользователя и что там за проблемы ... точнее, смотри выводы
- systemctl status pulseaudio
- systemctl --user status pulseaudio

PS - при нормальной режиме должно быть типа такого
systemctl status pulseaudio
Unit pulseaudio.service could not be found.

systemctl --user status pulseaudio
● pulseaudio.service - Sound Service
     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2022-04-08 14:04:50 MSK; 4h 10min ago
TriggeredBy: ● pulseaudio.socket
   Main PID: 7857 (pulseaudio)
   ... и так далее ...
Ошибки не исчезают с опытом - они просто умнеют