Загрузить в режиме восстановления с установщика, проделай все запрошенные шаги, далее через chroot удали все из /tmp и активируй tmp.mount.

Анон говнарь.

Сделай просто в рабочей системе umount /tmp
удали всё в /tmp/*
Pulse не может гадить, user space, Karl!

Pulse не может

Да нет, может. Ради любопытства сейчас посмотрел у себя, сидя под Arch в корень Debian /tmp - точно такая же картина.

Штук 100 этих /tmp/pulse-PKdhtXMmr18n. Правда все старые, лет пять похоже уже там лежат некоторые.

Удалил. Сейчас в Debian перезагружусь, посмотрю появятся ли. Интересно.

посмотрю появятся ли

Не, не появляются.

Загрузился в Debian, обновил apt update, вернулся в Arch, в Debian'овском /tmp пусто и чисто.

Какие-то хвосты из прошлой жизни, наверное.

Может

Ответ на: комментарий от anonymous 12.03.21 11:09:15

как видим проблема подтведилась.

чтоб удалить достаточно сделать

mount –bind / /mnt/root

но каждый раз всё поновой

но каждый раз всё поновой

Это я не могу подтвердить. Прошлый раз под Hyper-V туда/сюда перегружался. Сейчас на голом железе повторил - у меня они больше не появляются на реальном /tmp.

На tmpfs - да, есть такие директории и сейчас. И они понятно что пропадают вместе с tmpfs. До файловой системы не добираются.

Debian10 + KDE.

Нужно звать специалистов по порядку запуска сервисов, видимо.

Сделай просто в рабочей системе umount /tmp

За такое по рукам нужно бить.

а смысл? ДНК уже не исправишь…

не могу подтвердить

Теперь могу.

Оказывается стабильно воспроизводится на 4.19 ядре. Все прошлые попытки были на 5.4 из bpo - и там не воспроизводится.

накатил «чо дали» из bpo, а дали 5.10

Linux 5.10.0-0.bpo.3-amd64 x86_64

тож самое.

А в наше время точно надо /tmp в fstab держать?

Ну, пока других мыслей нет. Несколько раз перезагружался в 5.4 - всё чисто.

На 4.19 каждый раз появляется это /tmp/pulse-XXXXXXX до монтирования /tmp в tmpfs.

Сравнивал daemon.log с обоих - никаких особых отличий не вижу до /tmp.

это https://pastebin.com/UnvjJzPx чистый tmp в 5.4

это https://pastebin.com/nQU9uMHn мусорный tmp в 4.19

В общем наиграл следующее:

У меня в 4.19 слишком быстро загружаются модули ядра snd_hda_intel и snd_hda_codec_realtek, которые и провоцируют /tmp/pulse-XXXXXXX раньше времени. В 5.4 они просто случайно, похоже, позже подгружаются.

Если их в blacklist, тогда всё чисто загружается.

Когда потом руками modprobe snd_hda_intel - вот тут и появляется это /tmp/pulse-XXXXXXX, но уже в tmpfs, как положено. (Причем - именно на intel; на realtek никаких /tmp/pulse не появляется, молча модуль загружается)

Как заставить их загружаться с задержкой - так и не разобрался.

Где-то тут собака порылась.

Устал играть в это, пардон.

Огромное СПАСИБО!

плюс в карму

Как правильно /tmp в tmpfs сделать в debian

ИМХО, вам нужно монтировать юнитом, запись из fstab убрать. Главное указать в юните нужную очерёдность.

ага… что-то типа этого Как правильно /tmp в tmpfs сделать в debian

скажу по секрету… шопотом…

если так сделать, то не только pulse успеет ссыкнуть… но и многие другие нагадить побольшому %(((((((

Там про юнит tmp.mount. Какой порядок загрузки ему прописать это уже отдельный вопрос.

скажу по секрету

Нет уж, показывайте свой юнит tmp.mount и что у него с порядком запуска. Такое добавляли ?:

[Install]
WantedBy=local-fs-pre.target

бобёр выдыхай...

выдохнул…

уронил полностью систему… полчаса удалял свой tmp.mount

если можете помочь - дайте нормальный юнит.

Устал

Отдохнул.

Но теперь без физического доступа к той машине. И линуксы там доступны сейчас только через HyperV. А в таком режиме не видно, что лечить: ничего не болеет. Это только на реальном железе происходит.

На самом деле я тоже пытался вчера навесить зависимости на tmp.mount. И это можно сказать работает. Если не считать, что загрузка происходит некорректно и в итоге пытается войти в Single Mode (это там где Control-D or root password). Работает в том смысле, что /tmp не пачкается.

По-моему реальнее всё-таки со стороны модулей или udev какие-то костыли придумать. Может попробовать из Ubuntu украсть ее /etc/modprobe.d/alsa-base.conf ?

извиняюсь

два раза за день уронить систему…

беру отпуск на пару дней…

беру отпуск

Это всегда хорошо.

Добрался физически до своей машины - проверил теорию с /etc/modprobe.d/alsa-base.conf спёртую из Ubuntu 20.04

Это работает у меня. Беда в том, что я не понимаю почему работает. Но работает. /tmp не пачкается.

При этом по

journalctl -xb -o short-iso-precise | grep -E 'snd_hda|/tmp'

Это - с alsa-base.conf

2021-03-14T19:56:56.860646+0700 omsiz97.berg kernel: snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
2021-03-14T19:56:56.954215+0700 omsiz97.berg systemd[1]: Mounting /tmp...
2021-03-14T19:56:56.957070+0700 omsiz97.berg systemd[1]: Mounted /tmp.

Это - без

2021-03-14T19:53:14.904711+0700 omsiz97.berg kernel: snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
2021-03-14T19:53:15.180279+0700 omsiz97.berg systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway.
-- Каталог /tmp, который был указан в качестве точки монтирования (во втором
2021-03-14T19:53:15.180767+0700 omsiz97.berg systemd[1]: Mounting /tmp...
2021-03-14T19:53:15.182737+0700 omsiz97.berg systemd[1]: Mounted /tmp.

Было бы здорово, если бы кто-нибудь объяснил, что там такого в убунтовской alsa-base.conf происходит. Но в принципе - работает и чудненько.

Используй tmp.mount из поставки systemd.

ЧЯДНТ

$ systemctl cat /tmp

# /run/systemd/generator/tmp.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target

[Mount]
Where=/tmp
What=tmpfs
Type=tmpfs
Options=nosuid,nodev,noatime,mode=1777

$systemctl enable tmp.mount

кака было така есть %((((((((

вылечилось

Точно не знаю как, но…

что сделал (вчера): обновил систему до: Debian GNU/Linux bullseye/sid x86_64 обновил ядро до: 5.10.0-4-amd64

неделю назад: tmp.mount взял из /usr/share/systemd несколько дней назад: выключил гипертридинг

как-то так %)))