Yep this was the issue!
I just manually started /usr/bin/pipewire-media-session from the command line. And it’s working!
So it appears for a default install pipewire-media-session is neither run with any of the other services nor does it have a service of it own. I will go about creating a custom systemctl service for pipewire-media-session. This sounds like a bug. Is this supposed to have it’s own service?
Can someone run a systemctl status --user pipewire-media-session?
After building a custom service for pipewire-media-session I could start it. i am still curious if this how it is supposed to be run. Does everyone else just have this service?
I had to create this service and enable/start…
❯ cat /usr/lib/systemd/user/pipewire-media-session.service
[Unit]
Description=PipeWire Media Session Service
Requires=pipewire-pulse.socket
ConditionUser=!root
Wants=pipewire.service
After=pipewire.service
Conflicts=pulseaudio.service
[Service]
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
RestrictNamespaces=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
Type=simple
ExecStart=/usr/bin/pipewire-media-session
Restart=on-failure
Slice=session.slice
[Install]
WantedBy=default.target
In short it does look like this is installed as a apart of the pipewire pacakge. There is just no instruction in it to run it as a service…
dnf provides pipewire-media-session
pipewire-0.3.25-1.fc34.i686 : Media Sharing Server
Repo : fedora
Matched from:
Filename : /usr/bin/pipewire-media-session
Wild, the service currently even asks for it but no errors are thrown…
❯ cat /usr/lib/systemd/user/pipewire-pulse.service
[Unit]
Description=PipeWire PulseAudio
# We require pipewire-pulse.socket to be active before starting the daemon, because
# while it is possible to use the service without the socket, it is not clear
# why it would be desirable.
#
# A user installing pipewire and doing `systemctl --user start pipewire-pulse`
# will not get the socket started, which might be confusing and problematic if
# the server is to be restarted later on, as the client autospawn feature
# might kick in. Also, a start of the socket unit will fail, adding to the
# confusion.
#
# After=pipewire-pulse.socket is not needed, as it is already implicit in the
# socket-service relationship, see systemd.socket(5).
Requires=pipewire-pulse.socket
ConditionUser=!root
Wants=pipewire.service pipewire-session-manager.service
After=pipewire.service pipewire-session-manager.service
Conflicts=pulseaudio.service
[Service]
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
RestrictNamespaces=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
Type=simple
ExecStart=/usr/bin/pipewire-pulse
Restart=on-failure
Slice=session.slice
[Install]
Also=pipewire-pulse.socket
WantedBy=default.target
❯ cat /usr/lib/systemd/user/pipewire.service
[Unit]
Description=PipeWire Multimedia Service
# We require pipewire.socket to be active before starting the daemon, because
# while it is possible to use the service without the socket, it is not clear
# why it would be desirable.
#
# A user installing pipewire and doing `systemctl --user start pipewire`
# will not get the socket started, which might be confusing and problematic if
# the server is to be restarted later on, as the client autospawn feature
# might kick in. Also, a start of the socket unit will fail, adding to the
# confusion.
#
# After=pipewire.socket is not needed, as it is already implicit in the
# socket-service relationship, see systemd.socket(5).
Requires=pipewire.socket
[Service]
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
RestrictNamespaces=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
Type=simple
ExecStart=/usr/bin/pipewire
Restart=on-failure
Slice=session.slice
[Install]
Also=pipewire.socket
WantedBy=default.target
