Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages
hi Dylan, On Tue, 29 Aug 2023, Dylan Aïssi wrote: Le mar. 29 août 2023 à 00:27, Boud Roukema a écrit : PROPOSAL (1): Should the user be informed when doing the system upgrade? More specifically, would a one-line warning to the user be considered acceptable, as a post-install script? E.g. something like: This is a discouraged behavior. Pipewire is updated every ~ two weeks, if it displays messages for each update that will annoy people and I will receive a wave of complaints to disable it. Fair enough. Especially with Mobian/trixie (Mobian/bookworm before the release of bookworm as stable), an upgrade after a week can often update 300 to 400 packages. PROPOSAL (2): Add the following file (under the default licence for pipewire - Expat - no need to complicate the licensing further): cat > debian/pipewire-pulse.README.Debian << EOF This would be possible but as you said pipewire-pulse is not the only user service here that means we should do the same for all other packages providing a user service. Looks like a waste of resources as it is the expected behavior. But the other services do not have a name that sounds like they are "part" of pipewire. Pipewire-jack and so on do not have /lib/systemd/user/ entries. In any case, I've proposed (Debian level, but should obviously be pushed upstream if appropriate) to adjust the man page: https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/23 commit af0a1acb PROPOSAL (3) Add the following file for the overall pipewire documentation: This proposal seems more appropriate :-) merge requests to improve this file are more than welcome :-P here is the git repo: https://salsa.debian.org/utopia-team/pipewire MR proposed: https://salsa.debian.org/utopia-team/pipewire/-/merge_requests/23 commit d4ca0381 (I didn't see an easy way of splitting these two commits into two separate merge requests through the web interface.) I also want to mention our pipewire wiki page: https://wiki.debian.org/PipeWire if you consider it lacks some information then edits are also welcome :-). Thanks - I'll see if I can do something useful there. As the interactions between all these components is complex, the safest way is to restart your device after an update of pipewire. True. But in the long term, we could imagine that pipewire - like any Debian software component - could be used by organisations or groups running services for large numbers of people where frequent reboots are considered unacceptable - maybe a big radio or tv station, for example? While sysadmins of those sorts of services are expected to thoroughly know the software they use, they'll still make errors, and may wish to avoid a reboot, and may consider that pipewire "should" allow upgrading without a reboot. Or eventually you can try to only close your session and then reopen a new one to restart user services. So on a pinephone, 'sudo systemctl restart phosh', I assume. The upstream wiki [1] provides the following command to restart pw/wp services, but before filling a new bug, I would at least try to restart my device anyway. systemctl --user restart wireplumber pipewire pipewire-pulse I was doing that for some time, and then (incorrectly) thought that I could drop off the pipewire-pulse part. [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting Anyway, my two-part MR is posted (the CI pipeline failed, for reasons presumably unrelated to my changes). Cheers Boud
Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages
Hi Boud, Le mar. 29 août 2023 à 00:27, Boud Roukema a écrit : > > PROPOSAL (1): > > Should the user be informed when doing the system upgrade? More specifically, > would a one-line warning to the user be considered acceptable, as a > post-install > script? E.g. something like: > > "Please recommend that users restart all scripts running pipewire (such as > pipewire, pipewire-pulse)" This is a discouraged behavior. Pipewire is updated every ~ two weeks, if it displays messages for each update that will annoy people and I will receive a wave of complaints to disable it. > PROPOSAL (2): > > Add the following file (under the default licence for pipewire - Expat - no > need to complicate the licensing further): > > cat > debian/pipewire-pulse.README.Debian << EOF > Relation to pipewire and upgrades > = > > The pipewire-pulse systemd service runs independently of the pipewire > service. Both run as user services and are not restarted when a > system-level upgrade is performed by the root user. If you wish to > check that you restart pipewire-pulse whenever the pipewire is > upgraded using dpkg or apt, then consider using either > "checkrestart" in the "debian-goodies" package [1] or "needrestart" [2]. > These need to be run as root user, but aim to check for both > system and user services that need restarting. > > [1] https://tracker.debian.org/pkg/debian-goodies > [2] https://tracker.debian.org/pkg/needrestart > EOF This would be possible but as you said pipewire-pulse is not the only user service here that means we should do the same for all other packages providing a user service. Looks like a waste of resources as it is the expected behavior. > PROPOSAL (3) > Add the following file for the overall pipewire documentation: > > cat >> debian/pipewire.README.Debian << EOF > > > After upgrading pipewire > > > A system-level upgrade of pipewire will not automatically restart all > pipewire-related services. After an upgrade of pipewire, you may check > the output of "pw-dump" to see if you forgot to restart some services, > e.g. > >$ pw-dump |grep -nE "core\.(version|name)|process\.binary" > > or you may use "checkrestart" [1] or "needrestart" [2] with > sudo or as root user. > > [1] https://tracker.debian.org/pkg/debian-goodies > [2] https://tracker.debian.org/pkg/needrestart > EOF This proposal seems more appropriate :-) merge requests to improve this file are more than welcome :-P here is the git repo: https://salsa.debian.org/utopia-team/pipewire I also want to mention our pipewire wiki page: https://wiki.debian.org/PipeWire if you consider it lacks some information then edits are also welcome :-). > Independent of proposals (1) + (2) + (3), the 'pw-dump' > output gives me the feeling that restarting pipewire > should force the restart of all the related services - but > I don't know how well they are expected to work together > when according to pw-dump they are using inconsistent > pipewire versions. As the interactions between all these components is complex, the safest way is to restart your device after an update of pipewire. Or eventually you can try to only close your session and then reopen a new one to restart user services. The upstream wiki [1] provides the following command to restart pw/wp services, but before filling a new bug, I would at least try to restart my device anyway. systemctl --user restart wireplumber pipewire pipewire-pulse [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting Best regards, Dylan
Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages
hi Dylan,
On Mon, 28 Aug 2023, Dylan Aïssi wrote:
I think the bug you are describing is a kind of duplicate of #1027136 [1]
filled against xdg-desktop-portal. So, I will quote the smcv's answer here [2]:
I think (the) xdg-desktop-portal user service(s) should be stopped before
removing the package. Is that possible?
Not really: maintainer scripts happen in the context of the overall system
(as root) and there is not really a good way to inject service-management
commands into user sessions. Other per-user services like PulseAudio,
Pipewire, gpg-agent and so on are not stopped when you remove them either.
I see your point: from the system point of view, it's the user's responsibility
to know that if s/he upgrades pipewire, then s/he should either restart *all*
services running pipewire, or *none* of them (or live dangerously with a mix
:P).
However, in that case, we should inform (at least) the user who knows
enough to look in the obvious place: /usr/share/docs/pipewire-pulse/; this
is currently empty except for 'copyright' and 'changelog.Debian.gz'.
At least one moderately experienced user (me) doesn't know much about
pipewire, and messed up. I assumed (incorrectly) that pipewire-pulse
would be automatically restarted if pipewire were restarted.
Here are two non-exclusive proposals.
PROPOSAL (1):
Should the user be informed when doing the system upgrade? More specifically,
would a one-line warning to the user be considered acceptable, as a post-install
script? E.g. something like:
"Please recommend that users restart all scripts running pipewire (such as pipewire,
pipewire-pulse)"
PROPOSAL (2):
Add the following file (under the default licence for pipewire - Expat - no
need to complicate the licensing further):
cat > debian/pipewire-pulse.README.Debian << EOF
Relation to pipewire and upgrades
=
The pipewire-pulse systemd service runs independently of the pipewire
service. Both run as user services and are not restarted when a
system-level upgrade is performed by the root user. If you wish to
check that you restart pipewire-pulse whenever the pipewire is
upgraded using dpkg or apt, then consider using either
"checkrestart" in the "debian-goodies" package [1] or "needrestart" [2].
These need to be run as root user, but aim to check for both
system and user services that need restarting.
[1] https://tracker.debian.org/pkg/debian-goodies
[2] https://tracker.debian.org/pkg/needrestart
EOF
My guess is that an extra file debian/pipewire-pulse.docs won't be
needed for this to be automatically installed. I tried both
checkrestart and needrestart, which both gave credible answers
(e.g. 'No user sessions are running outdated binaries.')
It's unclear to me if xdg-desktop-portal or other related programs
also need a similar debian/xdg-desktop-portal.README.Debian file.
After the udpate to pipewire 0.3.78 and restarting pipewire, 'pw-dump'
showed all the following as still being pipewire clients at version
0.3.77-1:
$ cat old-pw-dump | grep -n -B14 0\.3\.77 | sed -e "s/\(machine-id.\).*\'/\1:
/"
659-"type": "PipeWire:Interface:Client",
660-"version": 3,
661-"permissions": [ "r", "w", "x", "m" ],
662-"info": {
663- "change-mask": [ "props" ],
664- "props": {
665-"application.language": "C.UTF-8",
666-"application.name": "xdg-desktop-portal",
667-"application.process.binary": "xdg-desktop-portal",
668-"application.process.host": "mobian",
669-"application.process.id": 1685,
670-"application.process.user": "mobian",
671-"clock.power-of-two-quantum": true,
672-"core.name": "pipewire-mobian-1685",
673:"core.version": "0.3.77",
--
709-"info": {
710- "change-mask": [ "props" ],
711- "props": {
712-"application.language": "C.UTF-8",
713-"application.name": "gsd-power",
714-"application.process.binary": "gsd-power",
715-"application.process.host": "mobian",
716-"application.process.id": 1171,
717-"application.process.machine-id":
718-"application.process.user": "mobian",
719-"client.api": "pipewire-pulse",
720-"clock.power-of-two-quantum": true,
721-"config.name": "pipewire-pulse.conf",
722-"core.name": "pipewire-mobian-853",
723:"core.version": "0.3.77",
--
759-"info": {
760- "change-mask": [ "props" ],
761- "props": {
762-"application.language": "C",
763-"application.name": "CallAudio",
764-"application.process.binary": "callaudiod",
765-"application.process.host": "mobian",
766-"application.process.id": 1040,
767-"application.process.machine-id":
768-"application.process.user": "mobian",
769-"client.api": "pipewire-pulse",
770-"clock.power-of-two-quantum": true,
771-"config.name": "pipewire-pulse.conf",
772-
Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages
Hello Boud, Le ven. 25 août 2023 à 13:09, a écrit : > > * What outcome did you expect instead? > > What I expected was that the dpkg/apt system and/or the systemd system > should have recognised that the old 'pipewire-pulse' process was invalid > and should have forced it to restart with the 0.3.78-1 version. > I think the bug you are describing is a kind of duplicate of #1027136 [1] filled against xdg-desktop-portal. So, I will quote the smcv's answer here [2]: >> I think (the) xdg-desktop-portal user service(s) should be stopped before >> removing the package. Is that possible? > > Not really: maintainer scripts happen in the context of the overall system > (as root) and there is not really a good way to inject service-management > commands into user sessions. Other per-user services like PulseAudio, > Pipewire, gpg-agent and so on are not stopped when you remove them either. Best regards, Dylan [1] https://bugs.debian.org/1027136 [2] https://bugs.debian.org/1027136#10
Bug#1050498: Info received (Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages)
hi all If systemd does not provide the relation that is needed, then the package 'checkrestart' in 'debian-goodies' https://tracker.debian.org/pkg/debian-goodies or 'needrestart' https://tracker.debian.org/pkg/needrestart might be needed instead. Cheers Boud
Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages
I stopped and started 'pipewire-pulse' with 'systemctl --user ...'
and checked the pw-dump output.
The systemd package 'xdg-desktop-portal' remained at 0.3.77-1,
i.e. the same bug seems to exist for xdg-desktop-portal.
So presumably whatever solution is preferred for 'pipewire-pulse'
should probably also be implemented for 'xdg-desktop-portal'.
I'll try to add an "affects xdg-desktop-portal" tag to this bug
report...
The following output is from *after* stopping and restarting
pipewire-pulse.
$ pw-dump
...
"id": 35,
"type": "PipeWire:Interface:Client",
"version": 3,
"permissions": [ "r", "w", "x", "m" ],
"info": {
"change-mask": [ "props" ],
"props": {
"application.language": "C.UTF-8",
"application.name": "xdg-desktop-portal",
"application.process.binary": "xdg-desktop-portal",
"application.process.host": "mobian",
"application.process.id": 1685,
"application.process.user": "mobian",
"clock.power-of-two-quantum": true,
"core.name": "pipewire-mobian-1685",
"core.version": "0.3.77",
"cpu.max-align": 16,
"default.clock.max-quantum": 2048,
"default.clock.min-quantum": 32,
...
$ dpkg -l |grep xdg-desktop
ii xdg-desktop-portal1.16.0-3
arm64desktop integration portal for Flatpak and Snap
ii xdg-desktop-portal-gtk1.14.1-1
arm64GTK+/GNOME portal backend for xdg-desktop-portal
ii xdg-desktop-portal-wlr0.7.0-1
arm64xdg-desktop-portal backend for wlroots
Bug#1050498: pipewire-pulse systemd service not restarted despite dpkg upgrade of all pipewire packages
Package: pipewire-pulse
Version: 0.3.78-1
Severity: normal
Dear pipewire maintainers,
* What led up to the situation?
I'm trying to getting Mobian Pinephone (PP) audio phone calls to fully
work (person on remote phone hears me and I hear the person on the
remote phone). See
https://salsa.debian.org/Mobian-team/packages/alsa-ucm-conf/-/issues/8
https://salsa.debian.org/Mobian-team/packages/alsa-ucm-conf/-/issues/9
for details.
A bug related to callaudiod in pipewire-0.3.77 was reported to be fixed
in 0.3.78: https://gitlab.com/mobian1/callaudiod/-/issues/30 .
I had pipewire 0.3.77-1 from Mobian/Debian/trixie installed.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I compiled pipewire 0.3.78-1 from Debian (salsa) source with
'fakeroot debian/rules binary'
after applying the two patches in debian/patches/ .
I installed all the newly compiled *.deb files that matched names that I
already had
from 0.3.77-1, using dpkg -i *.deb. More specifically, I did:
'for i in gstreamer1.0-pipewire_0.3.78-1_arm64.deb
libpipewire-0.3-0_0.3.78-1_arm64.deb libpipewire-0.3-modules_0.3.78-1_arm64.deb
libspa-0.2-bluetooth_0.3.78-1_arm64.deb libspa-0.2-jack_0.3.78-1_arm64.deb
libspa-0.2-libcamera_0.3.78-1_arm64.deb libspa-0.2-modules_0.3.78-1_arm64.deb
pipewire_0.3.78-1_arm64.deb pipewire-alsa_0.3.78-1_arm64.deb
pipewire-audio_0.3.78-1_all.deb
pipewire-audio-client-libraries_0.3.78-1_all.deb
pipewire-bin_0.3.78-1_arm64.deb pipewire-jack_0.3.78-1_arm64.deb
pipewire-pulse_0.3.78-1_arm64.deb; do sudo dpkg -i ${i}; done'
four times, as a brute force alternative to working out in which order the
packages depended on each other. The first three times each reported missing
dependencies, but fewer each time. The fourth iteration appeared to be
error-free.
I checked that the apt system was clean with
dpkg --audit
which gave an empty response.
I restarted pipewire (several times).
* What was the outcome of this action?
Some phone calls worked :). And some phone calls failed :(.
More specifically, after analysing and tidying log files for my main bug,
I found that the old /usr/bin/pipewire-pulse (0.3.77-1) is still running.
The output of 'pw-dump' shows that there is a mix of 0.3.78-1 and 0.3.77-1
running in parallel. I've kept this situation for the purposes of reporting
this bug, but I'll kill off the old pipewire-pulse process after filing the bug
report.
* What outcome did you expect instead?
What I expected was that the dpkg/apt system and/or the systemd system
should have recognised that the old 'pipewire-pulse' process was invalid
and should have forced it to restart with the 0.3.78-1 version.
SUGGESTED SOLUTIONS:
(1) dpkg or the debian/control or other debian/* file - if pipewire
is re-installed and pipewire-pulse is present, then pipewire-pulse
must not only be updated to the same version, but any processes
actually running must be restarted too. This depends on whether the
debian/* files force restarting of the systemd services or not.
If the services are restarted, then it seems to me that pipewire-pulse
must be restarted along with pipewire (if pipewire-pulse is installed).
(2) systemd alone - if (i) the pipewire-pulse service exists, and (ii)
pipewire is restarted, then (iii) pipewire-pulse must be restarted. I
can only make an educated guess as to what the systemd rules for this
should be. My guess is:
/lib/systemd/user/pipewire.service
PropagatesStopTo=pipewire-pulse
/lib/systemd/user/pipewire-pulse.service
StopPropagatedFrom=pipewire
since a 'restart' is presumably a stop and a start. There doesn't
seem to be a pair PropagatesRestartTo and RestartPropagatesTo.
COMMENT: If upstream has a separate 'pipewire-pulse' package, then
this issue should presumably be also fixed upstream.
DIAGNOSTICS:
$ dpkg -l |grep pipewire
ii gstreamer1.0-pipewire:arm64 0.3.78-1
arm64GStreamer 1.0 plugin for the PipeWire multimedia server
ii libpipewire-0.3-0:arm64 0.3.78-1
arm64libraries for the PipeWire multimedia server
ii libpipewire-0.3-modules:arm64 0.3.78-1
arm64libraries for the PipeWire multimedia server - modules
ii pipewire:arm640.3.78-1
arm64audio and video processing engine multimedia server
ii pipewire-alsa:arm64 0.3.78-1
arm64PipeWire ALSA plugin
ii pipewire-audio0.3.78-1
all recommended set of PipeWire packages for a standard audio desktop
use
ii pipewire-audio-client-libraries 0.3.78-1
all transitional package for pipewire-alsa and pipewire-jack
ii pipewire-bin 0.3.78-1
arm64PipeWire multimedia server -
