Bug 1052437

There's an opensuse forum topic on the same issue:
https://forums.opensuse.org/showthread.php/526302-Strange-problem-with-Plasma5-Volume-Manager-(plasma5-pa)
Maybe that's also you, but I suspect not.

I was unable to reproduce the problem in my own tests.

You should be able to automatically shutdown pulseaudio by running
 pulseaudio --kill
in a shutdown script.  I put that in the script
$HOME/.config/plasma-workspace/shutdown/unpulse.sh

Note, however, that when I tried to reproduce the problem, I was not using that shutdown script.  I created a new user with no prior config for my test.  I actually wanted to test whether that shutdown script helped, but since I could not reproduce the problem, I did not get that far.

(In reply to Neil Rickert from comment #1)
> There's an opensuse forum topic on the same issue:
> https://forums.opensuse.org/showthread.php/526302-Strange-problem-with-
> Plasma5-Volume-Manager-(plasma5-pa)
> Maybe that's also you, but I suspect not.
> 
> I was unable to reproduce the problem in my own tests.
> 
> You should be able to automatically shutdown pulseaudio by running
>  pulseaudio --kill
> in a shutdown script.  I put that in the script
> $HOME/.config/plasma-workspace/shutdown/unpulse.sh
> 
> Note, however, that when I tried to reproduce the problem, I was not using
> that shutdown script.  I created a new user with no prior config for my
> test.  I actually wanted to test whether that shutdown script helped, but
> since I could not reproduce the problem, I did not get that far.

That is indeed not my thread. I'll add that this problem has actually been on my computer for a while now, but I've only just reported it. It may have even been an issue since I installed Tumbleweed, but I am unsure. Could there be a config file somewhere that needs to be fixed or regenerated? I am not familiar with how pulseaudio works.

I'm the author of the openSUSE forum thread linked to in comment #1 and confirm the reported behaviour upon second and subsequent logins of the same user.

If however there are additional users and login/logout alternates between them then pulseaudio is fine.

I've just tried the use of a shutdown script as suggested in comment #1

#!/bin/bash
#
pulseaudio --kill

... second and subsequent logins of the same user are now OK.

I reproduced the issue in QEMU/KVM with a fresh install of openSUSE Tumbleweed using the 2017-08-04 snapshot net installer.

I tried a few different setups.

Setup 1: Fresh install, KDE Workstation, default installer settings.
    - I reproduced the bug with this setup.

Setup 2: Fresh install, GNOME Workstation, default installer settings.
    - I did not reproduce the bug with this setup.

Setup 3: I started with the existing Setup 2, but with KDE Plasma installed after installation via the KDE Desktop Environment pattern.
    - I did not reproduce the bug with this setup in KDE and GNOME.
    - This must mean there is a problem with the default KDE Workstation installation.
    - This setup used GDM.

Setup 4: Fresh install, KDE Workstation, default installer settings, but with GNOME installed after installation via the GNOME Desktop Environment pattern.
    - I reproduced the bug with this setup in KDE, but not in GNOME, no matter the display manager.
    - The problem affects KDE when SDDM and LightDM are used, but not GDM.

put "KillUserProcesses=yes" in your /etc/logind.conf and you are done

From comment #5:
>   - The problem affects KDE when SDDM and LightDM are used, but not GDM.

That explains why I could not reproduce the problem.  I'm using GDM.

(In reply to Michael Hirmke from comment #6)
> put "KillUserProcesses=yes" in your /etc/logind.conf and you are done

I don't have /etc/logind.conf
Is the file supposed to be there?

(In reply to Noah Davis from comment #8)
> I don't have /etc/logind.conf
> Is the file supposed to be there?

Uncomment the line in /etc/systemd/logind.conf

Details of location and precedence of configuration files can be found here:
https://www.freedesktop.org/software/systemd/man/logind.conf.html

(In reply to Paul Tannington from comment #9)
> (In reply to Noah Davis from comment #8)
> > I don't have /etc/logind.conf
> > Is the file supposed to be there?
> 
> Uncomment the line in /etc/systemd/logind.conf
> 
> Details of location and precedence of configuration files can be found here:
> https://www.freedesktop.org/software/systemd/man/logind.conf.html

I uncommented and set KillUserProcesses=yes, but that did not work. I also tried restarting my computer after changing logind.conf in case the change would only be detected after a restart, but the bug was still there.

Unless anyone else has an idea on how to fix the root cause of this problem, I'll just use a shell script to kill pulseaudio like Neil Rickert suggested.

Actually, shell script doesn't work either because `pulseaudio --kill` doesn't work.

(In reply to Noah Davis from comment #10)
> I uncommented and set KillUserProcesses=yes, but that did not work. I also
> tried restarting my computer after changing logind.conf in case the change
> would only be detected after a restart, but the bug was still there.

I hadn't actually tried that as I'm (successfully) using the script of comment #4

I've just tried setting "KillUserProcesses=yes" in "/etc/systemd/logind.conf" and confirm that (after re-booting) it does not eliminate the bug.

I've also checked there are no other config files at:
"/etc/systemd/logind.conf.d/*.conf"
"/run/systemd/logind.conf.d/*.conf"
"/usr/lib/systemd/logind.conf.d/*.conf"
that may be overiding "/etc/systemd/logind.conf"



The script that I'm using is:

#!/bin/bash
#
# https://forums.opensuse.org/showthread.php/526302-Strange-problem-
# with-Plasma5-Volume-Manager-(plasma5-pa)
# https://bugzilla.opensuse.org/show_bug.cgi?id=1052437
#
# kill pulseaudio on KDE logout 
#     
pulseaudio --kill
#
#

saved to "~/.config/plasma-workspace/shutdown/" as "killpulse.sh"

It definitely works for me, second and subsequent logins of the same user are fine, the correct audio devices are shown by plasma5-pa.

Silly question...  you did set the executable flag on the script?

(In reply to Noah Davis from comment #11)
> Actually, shell script doesn't work either because `pulseaudio --kill`
> doesn't work.

Forgot to add...

That "pulseaudio --kill" didn't work for me from konsole:

paul@Orion-Tumble:~$ pulseaudio --kill
E: [pulseaudio] main.c: Failed to kill daemon: No such process
paul@Orion-Tumble:~$

But it does work when called by the shutdown script, did you try the script, or just assume it wouldn't work.

(In reply to Paul Tannington from comment #13)
> (In reply to Noah Davis from comment #11)
> > Actually, shell script doesn't work either because `pulseaudio --kill`
> > doesn't work.
> 
> Forgot to add...
> 
> That "pulseaudio --kill" didn't work for me from konsole:
> 
> paul@Orion-Tumble:~$ pulseaudio --kill
> E: [pulseaudio] main.c: Failed to kill daemon: No such process
> paul@Orion-Tumble:~$
> 
> But it does work when called by the shutdown script, did you try the script,
> or just assume it wouldn't work.

I actually tried the script first, it didn't work, then tried the command and it didn't work.

(In reply to Paul Tannington from comment #12)
> (In reply to Noah Davis from comment #10)
> > I uncommented and set KillUserProcesses=yes, but that did not work. I also
> > tried restarting my computer after changing logind.conf in case the change
> > would only be detected after a restart, but the bug was still there.
> 
> I hadn't actually tried that as I'm (successfully) using the script of
> comment #4
> 
> I've just tried setting "KillUserProcesses=yes" in
> "/etc/systemd/logind.conf" and confirm that (after re-booting) it does not
> eliminate the bug.
> 
> I've also checked there are no other config files at:
> "/etc/systemd/logind.conf.d/*.conf"
> "/run/systemd/logind.conf.d/*.conf"
> "/usr/lib/systemd/logind.conf.d/*.conf"
> that may be overiding "/etc/systemd/logind.conf"
> 
> 
> 
> The script that I'm using is:
> 
> #!/bin/bash
> #
> # https://forums.opensuse.org/showthread.php/526302-Strange-problem-
> # with-Plasma5-Volume-Manager-(plasma5-pa)
> # https://bugzilla.opensuse.org/show_bug.cgi?id=1052437
> #
> # kill pulseaudio on KDE logout 
> #     
> pulseaudio --kill
> #
> #
> 
> saved to "~/.config/plasma-workspace/shutdown/" as "killpulse.sh"
> 
> It definitely works for me, second and subsequent logins of the same user
> are fine, the correct audio devices are shown by plasma5-pa.
> 
> Silly question...  you did set the executable flag on the script?

Silly me, I didn't make it executable. It's now executable and it works.

(In reply to Paul Tannington from comment #9)
> (In reply to Noah Davis from comment #8)
> > I don't have /etc/logind.conf
> > Is the file supposed to be there?
> 
> Uncomment the line in /etc/systemd/logind.conf
> 
> Details of location and precedence of configuration files can be found here:
> https://www.freedesktop.org/software/systemd/man/logind.conf.html

sorry, my mistake - I meant /etc/systemd/logind.conf.

And this really works for me - I had the same problem before setting this option.

(In reply to Michael Hirmke from comment #15)
> sorry, my mistake - I meant /etc/systemd/logind.conf.
> 
> And this really works for me - I had the same problem before setting this
> option.

This is all rather odd.  As I wrote in comment #12 this doesn't work for me.  The test I conducted yesterday was quite hastily done, so I've just repeated it.


First removed the "killpulse.sh" script I placed in "~/.config/plasma-workspace/shutdown/"

Then editted "/etc/systemd/logind.conf", line 17:

- #KillUserProcesses=no
+ KillUserProcesses=yes

Saved the file, logout and re-boot.


At first login of "User 1" pulseaudio / plasma5-pa are OK.

Logout "User 1"
Login "User 1"

Now there is no sound and plasma5-pa shows "No output or input devices found"


This is with Tumbleweed snapshot 20170806 and systemd 234-2.1

Do you have according entries for pulseaudio and/or the sound driver in your journal or in your xsession-errors-:[x] file?
If you log out from the GUI and log into a console session, is pulseaudio really still running?
Perhaps not pulseaudio, but the sound driver itself is the problem?

My systems are running Tumbleweed snapshot 20170806 and systemd 234-2.1.

OK Again:
remove "killpulse.sh" script placed in "~/.config/plasma-workspace/shutdown/"
edit "/etc/systemd/logind.conf" to enable "KillUserProcesses=yes"
logout and re-boot

Then:
Login as user "paul" (to KDE session)
at this point pulseaudio / plasma5-pa are OK.
from konsole within the KDE session

paul@Orion-Tumble:~$ ps -f $(pidof pulseaudio)
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
paul      1359     1  1 12:12 ?        S<l    0:00 /usr/bin/pulseaudio --start --log-target=syslog
paul@Orion-Tumble:~$ 

Then:
Logout user "paul" (from KDE session)
ctrl-alt-f2
Login as user "paul" (to console session)

paul@Orion-Tumble:~$ ps -f $(pidof pulseaudio)
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
paul      1359     1  0 12:12 ?        S<l    0:00 /usr/bin/pulseaudio --start --log-target=syslog
paul@Orion-Tumble:~$

(Unless I'm misunderstanding that, then, yes pulseaudio is still running as the original process started at the KDE login)

Exit console session
ctrl-alt-f7 
Login as user "paul" (to KDE session)
now at this point there is no sound and plasma5-pa shows "No output or input devices found"


There is nothing in "xsession-errors-:[x]" or "messages" (I'm still using rsyslog) relating to pulse.

Responding to comment #18

When I logout, I notice that "logind" is still running.  It shuts down after a few minutes.  I'm guessing that the idea is if you logout then immediately login again, "logind" just keeps going.

I would guess that the entry in logind.conf applies when logind shuts down, rather than when you think you are logging out.  That might explain the discrepancy between what you are seeing and what another commenter is seeing.

(In reply to Neil Rickert from comment #19)
> I would guess that the entry in logind.conf applies when logind shuts down,
> rather than when you think you are logging out.  That might explain the
> discrepancy between what you are seeing and what another commenter is seeing.

It would appear so.  If I repeat the sequence of operations from Comment #18 then immediately after logout from the KDE session and login of a console session pulseaudio is still running with the PID from the KDE session.  If however I now wait then after a while pulseaudio is no longer shown as a running process.

I don't know what the timeout is, I gave it time for me to go make a coffee :)

I'm going to leave this one for the moment and simply use the "pulseaudio --kill" script, that works and an immediate re-login is possible.

I tried to find out, what the difference regarding the timeout for stopping logind between your and my system might be, but couldn't find any configurable option for it.
If you have further questions or need a different solution, I'd suggest to ask in systemd-devel@lists.freedesktop.org. Even Lennart often answers questions like that.

Sorry to be late to join to the game.

Basically PA manages its daemon lifetime for X11 session via its module-x11-xsmp module.  This module is in pulseaudio-module-x11 package, and it's loaded via /usr/bin/start-pulseaudio-x11, which is invoked by XDG autostart pulseaudio.desktop.

After the X11 session exits, PA goes to idle and exists after the timeout defined in /etc/pulse/daemon.conf:exit-idle-timeout (default 20 seconds).

So, when you set exit-idle-timeout to 0, PA will abort immediately after the logout.

But it's interesting that the issue doesn't happen with GDM.  I thought the behavior is same, but there can be some missing piece.

Late maybe, but welcome.  Thanks for the explanation :)

So, basically not a bug then.

Well, although the behavior is somewhat expected,  it's still a bug that relogin doesn't work properly.

Practically seen, I *guess* the problem is worked around by setting exit-idle-timeout to 0.  But this has another side-effect, too, so it doesn't look like a prefect answer.

I checked quickly GNOME installation, and indeed, PA quits immediately after the logout.  So, there must be something missing for other DEs.

(In reply to Takashi Iwai from comment #24)
> I checked quickly GNOME installation, and indeed, PA quits immediately after
> the logout.  So, there must be something missing for other DEs.

At the second test, it doesn't behave like that, PA process sticks (even the process for gdm) on GNOME, too.  Either I must have checked wrongly or it shows inconsistent behavior.

That said, the remaining PA process itself is expected.  The question is why KDE complains as "no output or input devices found".  I guess it's rather phonon who can't cope with the remaining PA process?

*** Bug 1059428 has been marked as a duplicate of this bug. ***

I found another workaround to the issue by creating the following startup script:

#!/bin/bash
# Kill pulseaudio on KDE logout and restart it on KDE login
     
killall pulseaudio
pulseaudio --start



I hope this helps until the bug is fixed.

PS: I'm on KDE Tumbleweed.

After log out and log in on Tumbleweed KDE/sddm pulseaudio fails to start
# pulseaudio -v
E: [pulseaudio] socket-server.c: bind(): Address already in use
E: [pulseaudio] module.c: Failed to load module "module-esound-protocol-unix" (argument: ""): initialization failed.
E: [pulseaudio] main.c: Module load failed.
E: [pulseaudio] main.c: Failed to initialize daemon.

Workaround:
# rm /tmp/.esd-1000/socket
# pulseaudio --start

I can confirm the issue still exists in the latest Tumbleweed revision. Rather surprising that something this seemingly simple is taking so long to get noticed and solved.

(In reply to Mircea Kitsune from comment #29)
> I can confirm the issue still exists in the latest Tumbleweed revision.
> Rather surprising that something this seemingly simple is taking so long to
> get noticed and solved.

I think it has been noticed and assigned. A status update would be nice though.

(In reply to Mircea Kitsune from comment #29)
> I can confirm the issue still exists in the latest Tumbleweed revision.
> Rather surprising that something this seemingly simple is taking so long to
> get noticed and solved.

It looks simple, but it's not simple at all.  Rather it's a *VERY* complicated problem.

The comment 28 might give an interesting light: maybe it's a conflict of esound stuff.

Could someone check whether commenting out the line below in /etc/pulse/default.pa changes the behavior on KDE?
  load-module module-esound-protocol-unix

(In reply to Takashi Iwai from comment #31)
> (In reply to Mircea Kitsune from comment #29)
> > I can confirm the issue still exists in the latest Tumbleweed revision.
> > Rather surprising that something this seemingly simple is taking so long to
> > get noticed and solved.
> 
> It looks simple, but it's not simple at all.  Rather it's a *VERY*
> complicated problem.
> 
> The comment 28 might give an interesting light: maybe it's a conflict of
> esound stuff.
> 
> Could someone check whether commenting out the line below in
> /etc/pulse/default.pa changes the behavior on KDE?
>   load-module module-esound-protocol-unix

I did and it looks like this now:

### Load several protocols
#.ifexists module-esound-protocol-unix.so
# load-module module-esound-protocol-unix
#.endif
load-module module-native-protocol-unix

Audio works after log out and log in. KDE seems to behave normally so far.

Hi.

For info, I'm having the same issue on 2 systems (one of them OpenSuse is a VM).  Running OpenSuse Tumbleweed updated today 17.feb.2018.

In both cases I  have edited file /etc/pulse/default.pa with

"### Load several protocols
#.ifexists module-esound-protocol-unix.so
# load-module module-esound-protocol-unix
#.endif
load-module module-native-protocol-unix"

and now audio still works after loging out from KDE.

Thanks for the tip.

Regards

This is probably due to a leftover esd socket.
Please check the output of ll -h /tmp/.esd-*/socket after logging out?
If any sockets are shown, delete them and try to log in again and try sound.

I just tried here and despite there being left over sockets (pulseaudio not running anymore), sound worked just fine after logging in.

I would expect pulse to clean them on shutdown though.

(In reply to Takashi Iwai from comment #31)
> (In reply to Mircea Kitsune from comment #29)
> > I can confirm the issue still exists in the latest Tumbleweed revision.
> > Rather surprising that something this seemingly simple is taking so long to
> > get noticed and solved.
> 
> It looks simple, but it's not simple at all.  Rather it's a *VERY*
> complicated problem.
> 
> The comment 28 might give an interesting light: maybe it's a conflict of
> esound stuff.
> 
> Could someone check whether commenting out the line below in
> /etc/pulse/default.pa changes the behavior on KDE?
>   load-module module-esound-protocol-unix

With the same problem in my system. After this line commented out all good after logout/login.

/etc/pulse/default.pa applicable section looks like this now:

### Load several protocols
#.ifexists module-esound-protocol-unix.so
# load-module module-esound-protocol-unix
#.endif
load-module module-native-protocol-unix

Thank you much; Takashi!!!

I think I found the culprit.

Pulseaudio stores its native socket in /run/user/uid/pulse/ and the esd socket in /tmp/.esd-uid/.
$XDG_RUNTIME_DIR gets deleted when the user doesn't have any running sessions anymore, but the contents of /tmp/.esd-uid remain.
Pulseaudio remains running in the background (which it really shouldn't, it's inaccessible at that point) and keeps the esd socket alive.
As the native socket doesn't exist anymore, the pulse clients try to start a new instance, but that fails as the esd socket is still there.

I can reproduce this issue on my openSUSE Tumbleweed system. Editing /etc/pulse/default.pa does solve it, as per previous comments.

(In reply to Fabian Vogt from comment #36)
> I think I found the culprit.
> 
> Pulseaudio stores its native socket in /run/user/uid/pulse/ and the esd
> socket in /tmp/.esd-uid/.
> $XDG_RUNTIME_DIR gets deleted when the user doesn't have any running
> sessions anymore, but the contents of /tmp/.esd-uid remain.
> Pulseaudio remains running in the background (which it really shouldn't,
> it's inaccessible at that point) and keeps the esd socket alive.
> As the native socket doesn't exist anymore, the pulse clients try to start a
> new instance, but that fails as the esd socket is still there.

So this indicates that the discrepancy between PA's expectation and the X session cleanup behavior.  PA expects that it's still accessible after logout, and it does cleanup by itself after the defined timeout.  Meanwhile the session management already clears up the whole /run/user/* without killing PA.

We need to ask PA upstream about this...

OK, now some feedback from PA devs:

- If we start PA via systemd user service, everything should work fine;
  PA quits properly at session close

- If PA is started by other way, and logind clears the PA socket in $XDG_RUNTIME_DIR, it's a job of the logind or whatever who clears $XDG_RUNTIME_DIR.

For testing the first point, check "systemctl --user status pulseaudio"
I guess this is disabled as default.  Enable it via "systemctl --user enable pulseaudio", then relogin / retest.  It should work even without the esound hack in /etc/pulse/default.pa.

But, this method has a drawback: this means that PA is invoked even by the login on console, not only on X session.

BTW, I confirmed that KillUserProcesses=yes in logind.conf doesn't make any difference on TW regarding PA.  PA process remains after logout.  I'm testing on XFCE.

systemd-devs, is this expected?

(In reply to Takashi Iwai from comment #39)
> OK, now some feedback from PA devs:
> 
> - If we start PA via systemd user service, everything should work fine;
>   PA quits properly at session close
> 
> - If PA is started by other way, and logind clears the PA socket in
> $XDG_RUNTIME_DIR, it's a job of the logind or whatever who clears
> $XDG_RUNTIME_DIR.

That would be pam_systemd. It says about XDG_RUNTIME_DIR:

"Path to a user-private user-writable directory that is bound to the user login time on the machine. It is automatically created the first time a user logs in and removed on the user's final logout"
"If a user logs in once, then logs out again, and logs in again, the directory contents will have been lost in between, but applications should not rely on this behavior and must be able to deal with stale files."

Aren't there other sessions remaining of the user after logout? Wasn't user session lingering (`man loginctl`) enabled for given user?
What is content of /proc/$PID_OF_PA/cgroup?

(In reply to Michal Koutný from comment #42)
> Aren't there other sessions remaining of the user after logout?

No.

> Wasn't user
> session lingering (`man loginctl`) enabled for given user?

loginctl user-status shows "no".
I didn't touch about the setup from today's fresh installation.

> What is content of /proc/$PID_OF_PA/cgroup?

12:hugetlb:/
11:memory:/
10:pids:/user.slice/user-1000.slice/session-1.scope
9:freezer:/
8:cpu,cpuacct:/
7:rdma:/
6:cpuset:/
5:net_cls,net_prio:/
4:blkio:/
3:perf_event:/
2:devices:/user.slice
1:name=systemd:/user.slice/user-1000.slice/session-1.scope
0::/user.slice/user-1000.slice/session-1.scope

And now I received a fix patch from PA upstream dev to address this issue properly.

I built test packages in OBS home:tiwai:pa-fix-leap42.3 and home:tiwai:pa-fix-tw repos, respectively.  Both seem working fine on my VM quick tests.
Can anyone check whether these work, too?

Once after confirmed, I'll submit the fix to Leap / TW.

(In reply to Takashi Iwai from comment #44)
> And now I received a fix patch from PA upstream dev to address this issue
> properly.
> 
> I built test packages in OBS home:tiwai:pa-fix-leap42.3 and
> home:tiwai:pa-fix-tw repos, respectively.  Both seem working fine on my VM
> quick tests.
> Can anyone check whether these work, too?
>
> Once after confirmed, I'll submit the fix to Leap / TW.

I tried it on my TW system and pulseaudio stopped running as soon as I logged
out.

(clearing systemd-maintainers needinfo flag)

OK, I submitted the fix to Factory now.  The update for Leap 42.3 was submitted, too, as well as the update for SLE15/Leap 15.0.

I'll keep my test fix packages in OBS for a while until these updates get released.

Although the mystery about non-working logind KillUserProcesses isn't solved yet, the bug itself is fixed now.  So let's close.

This is an autogenerated message for OBS integration:
This bug (1052437) was mentioned in
https://build.opensuse.org/request/show/581120 42.3 / pulseaudio

openSUSE-RU-2018:0617-1: An update that has one recommended fix can now be installed.

Category: recommended (important)
Bug References: 1052437
CVE References: 
Sources used:
openSUSE Leap 42.3 (src):    pulseaudio-9.0-8.1