Description of problem: pulseaudio should not be triggered when a user logs in via SSH. It seems to make no sense, so "KISS" alone would be a reason to request that. Additionally, it leads to issues like bz1885553, where this happened: a) user logins via SSH b) pulseaudio started c) bluetooth packages installed, triggered by pulseaudio in a way leading to a systemd crash Let's just cut off the whole chain in preventing the first thing which seems to serve no purpose at all for SSH logins from remote: prevent pulseaudio from being run. Version-Release number of selected component (if applicable): All rhel8 versions affected, it seems How reproducible: always Steps to Reproduce: - Login as user via SSH (also happens for Xorg/Wayland, but might make sense then) user@<uid>.service executes this spawns "systemd --user" Actual results: 1. "systemd --user" sets up pulseaudio.socket (listening on /run/user/<uid>/pulse/native) as part of reaching sockets.target this is because pulseaudio.socket is installed (/usr/lib/systemd/user/sockets.target.wants/pulseaudio.socket) 2. "systemd --user" sets up pulseaudio.service as part of reaching default.target this is because pulseaudio.service is installed (/etc/systemd/user/default.target.wants/pulseaudio.service) 2.) is then in our other scenarios leading to issues. Expected results: Pulseaudio should not be triggered when a user logs in via SSH.
Hi engineering, any updates? rhel8.4 would be a chance to fix this..
No update. I have no idea where to begin with this.. I will try to ask someone who knows about systemd and the ssh login process and how we can disable pulseaudio in the ssh case.
Thanks. I would plainly request the removal of the 'sockets.target.wants/pulseaudio.socket' in Fedora or systemd upstream, and then wait for someone to scream. It might need to be reintroduced for desktop sessions, and the way to do it properly needs discussion. Just doing it by default, for example when someone logs in via ssh, is causing issues.
Brainstormed today with our partner about this. For normal service units, we can define filter criteria. For example microcode_ctl is not run in virtual guests, /usr/lib/systemd/system/microcode.service : ConditionVirtualization=false If pulseaudio.socket could have something like this, for example evaluating environment variables could then be used to understand if the user is running x11/wayland and only then run pulseaudio.
This is a possibility, but I'm not sure this is feasible at all, indeed the user may spawn a VNC service and want to benefit from the audio (I believe VNC has audio support as well). I think this should be handled at 'systemd --user' level, more globally. For example, it doesn't make sense to start 'systemd --user' when a sftp session is started (for now it starts). When a ssh session is started, startup of 'systemd --user' should be done only *on demand*, e.g. when the user does a systemctl --user command for example.
Hi, all This issue is disappeared from RHEL 8.3 which uses this version of pulseaudio: ~~~ pulseaudio-13.99.1-1.el8.x86_64 ~~~ Thank you.
yzheng, I'm using CentOS 8 Stream using the package pulseaudio-14.0-2.el8.x86_64 and I still have this problem. Occurs when someone logs in via SSH and also spawns a process when certain cronjobs start.
Hi, Jeffrey You're right... I found this only does not happen on the root user. The non-root users' ssh logins still generate the pulseaudio process. Thank you.
Tested CentOS Stream 14.0-4.el8.x86_64, which appears to be the latest. Remote root logins do not spawn the pulseaudio processes (as mentioned before), but non-root remote logins still spawn processes. Is there a way to disable this in the configuration? Thanks in advance.
Either socket or the service should be enabled but not both at the same time. How to start pulseaudio (or pulse socket) just for the sessions associated with seat that actually have access to sound card is something to figure out.