pulseaudio fails to create secure directory /run/user/1000/

orionbelt · Apprentice Joined: 05 Apr 2006 Posts: 179

The problem that i describe below started after successfully upgrading ~150 KDE packages from 5.13.5 to 5.14.3 yesterday. This is just a time coincidence but i'm mentioning it in case it's also the cause.

EDIT: In fact, i just noticed that media-sound/pulseaudio was also updated, to version 12.2, at the same time as the numerous KDE packages, and i missed it. So this has probably nothing to do with the KDE update, and is only related to the pulseaudio update.

After the upgrade i rebooted my system, and all worked fine, including sound/pulseaudio. However, at some later point, and without having done anything out of the ordinary, pulseaudio failed:

mike155 · Posted: Wed Dec 05, 2018 12:19 am Post subject:

When you get the message:

Fitzcarraldo · Posted: Wed Dec 05, 2018 1:09 am Post subject:

orionbelt · Apprentice Joined: 05 Apr 2006 Posts: 179

orionbelt · Apprentice Joined: 05 Apr 2006 Posts: 179

orionbelt · Apprentice Joined: 05 Apr 2006 Posts: 179

An update:

I mentioned above that i rebooted some hours ago. However, before rebooting i downgraded to media-sound/pulseaudio-11.1-r1. I attempted to restart the downgraded pulseaudio before rebooting, but it failed again. So i rebooted, and for the moment (the downgraded) pulseaudio seems to be running smoothly.

There is one more change that i made. I start my X session with "startx" at the console, and in order to minimize the risk of someone CTRL-ALT-F1-ing to the console and accessing my account, i used to run it in the background ("startx >& /dev/null &") and then logging out of the console. However, some years ago i realized that this was the reason why i was getting KDE crashes a few hours into the session... So back at the time, i switched to just running "startx" or "startx >& ~/Xorg.txt" in the foreground and keeping the console open despite the small security risk. Some time later, i switched to sddm, so startx was no longer necessary. Unfortunately, however, sddm stopped working for me after a KDE upgrade about a year ago, and despite spending hours and hours trying to fix the problem it still doesn't work... So i had to switch back to using startx from the console, but i tried running it again in the background as "startx >& /dev/null &" just in case it was now working. Lo and behold, KDE would no longer crash, and this is how i have been launching startx for about a year now.

However, this problem with pulseaudio got me thinking, because pulseaudio also fails a few hours into the session like KDE used to, and managing sessions is what ConsoleKit and elogind do, so perhaps /run/user/1000/pulse/ gets deleted after logging out of the console and it causes the problem because X is still running...

So besides downgrading pulseaudio, i am now running "startx" without putting it in the background. As i said, so far so good. If i get no trouble within a day or so, i will upgrade pulseaudio to 12.2 once again and reboot. This should determine whether the culprit is the newer version of pulseaudio and/or running startx in the background (or none of the above...)

orionbelt · Apprentice Joined: 05 Apr 2006 Posts: 179

OK, so after more than a day of usage, pulseaudio-11.1-r1 did not crash. So i re-upgraded pulseaudio to 12.2, and rebooted my system, making sure to start X again in the foreground (i.e., as "startx >& Xorg.txt" and not as "startx >& Xorg.txt &"). After a couple of days of usage, i am happy to say that pulseaudio is still going.

So it would seem that the problem was related to logging out from the console after putting startx in the background. As i said, this used to crash KDE some years ago but not any longer. I am not sure whether it stopped being a problem due to KDE doing something about it or due to ConsoleKit doing something about it. In the second case, one might hope that elogind might do something similar, but i don't suppose this can easily happen (even if it were desirable, which it may not be for reasons that escape me) since elogind is presumably not supposed to deviate much from systemd's logind.

The only other solution that i can see is using sddm, which, as i said, for some reason refuses to work on my system even after spending hours on wikis and the forums... But this will probably be a topic of another thread :-)

mega_flow · Posted: Mon Dec 10, 2018 6:13 pm Post subject:

pulseaudio like to keep running when you logout. But u make elogind to stop all procces when logging off
/etc/elogind/logind.conf "KillUserProcesses=yes"

Or u can try https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Permission_errors_bug

Hu · Administrator Joined: 06 Mar 2007 Posts: 23348

What happens if, instead of logging out the console or leaving it open, you exec startx so that no shell is left behind? I suspect your problem is that some process is watching your login shell and, when that login shell exits, the supervisor assumes (incorrectly) that all state created for that login shell can now be removed. It then proceeds to delete your /run/userUID directory. Most of your programs handle that correctly, but pulseaudio fails badly. I would consider that a bug in pulseaudio: it should not hang or crash as a result of the directory being absent. It may not be able to work properly, but it could at least fail gracefully: play no sounds, but not hang or abort any programs.