pipewire/wireplumber weird behavvior and error on shutdown

Forum Forums Official Releases antiX-23 “Arditi del Popolo pipewire/wireplumber weird behavvior and error on shutdown

  • This topic has 3 replies, 2 voices, and was last updated Sep 17-4:30 pm by abc-nix.
Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #116931

      When pipewire is active on my system, I get a hang at shutdown. According to the pstree output, there’s a dbus-daemon process that won’t kill. Sometimes there’s more than one of them. Sometimes there’s also a dbus-conf process that won’t kill. None of this happens when pipewire is disabled.

      For the time being, I’ve added some lines to the /etc/init.d/01killsigs script to omit the PIDs of any dbus-daemon or dbus-conf processes and that fixes the hangs at shutdown, but if there’s a better solution I’d like to find it.

      My system is a modded chromebook and the linux audio support is still being worked on, so that might be part of the issue here. The sound card is glkda7219max in case anyone is familiar with that.

      One thing that might help is if someone could test and let me know if they also have the following behaviors for pipewire that seem strange to me:

      1) A desktop refresh reloads pipewire, pipewire-pulse, and wireplumber. Any currently playing audio gets lost and the pipewire processes come back new PIDs. The dbus-launch and dbus-daemon processes that are associated with pipewire (PIDs are initially inbetween pipewire and pipewire-pulse) do not restart and have the sam PIDs. Audio still works if you start it again after the refreesh, though.

      Generally desktop refresh doesn’t kill other running processes, right? I know that the ~/.desktop-session/startup script is re-run when doing a desktop refresh, but calling pipewire again when it’s already running doesn’t usually seem to have this effect. It even happens when I use ‘pidof pipewire || pipewire &’ in the startup script, so it seems like something must be killing the pipewire processes.

      2) Running ‘sudo pkill slimski’ (a method I use to quickly reset my session) does not kill the pipewire processes even though I would expect it in this case. The associated dbus-launch and dbus-daemon processes do get restarted, though, with new PIDs, so it’s almost like the opposite of a desktop refresh.

      Strangely, after killing slimski at least once like this, any further desktop refreshes do not affect the pipewire processes and audio will continue to play through the refresh, which like I said seems like the expected behavior.

      3) Terminating the X session (CTRL+ALT+BACKSPACE) breaks pipewire. Even though all the component process are running, it looks to me like there are now two dbus-daemon processes associated with pipewire and I think that might be the problem. Audio will not play without killing all the pipwire processes and then running ‘pipewire &’ again.

      Maybe these behaviors are unrelated to the problem I’m having (and are due to the fact that pipewire is usually a systemd service instead of a session process?), but they’re all I have to go on for now.

      For me, running ‘pstree’ on a fresh boot looks like this:

            │          │                 └─desktop-session───icewm-session───icewm
            │          ├─runsv───dbus-daemon
            │          ├─2*[runsv───getty]
            │          ├─runsv───connmand
            │          ├─runsv───udevd
            │          └─runsv
            │       └─urxvt

      Apparently the pipewire processes (including the associated dbus-launch and dbus-daemon) are not session processes like I thought. And there also seems to be 3 wireplumbers? I’m not sure I’m interpretting that line correctly. Only one instance of wireplumber shows up in htop.

      Well, any help would be appreciated. Thanks.

      EDIT: I should mention that all of this seems to be unrelated to whether I start the pipewire process individually or use the pipewire.conf method suggested in this topic, which is why I’m posting it as a separate question.

      • This topic was modified 10 months, 1 week ago by anti-apXos.
      • This topic was modified 10 months, 1 week ago by anti-apXos.
      • This topic was modified 10 months, 1 week ago by anti-apXos.

        Based on the description for a similar problem in the RedHat knowledgebase, it is probably as you say and a dbus-launch/daemon process is still running when shutting down. Cannot reproduce on my system, but i have seen this a few times on the live-usb (cannot reproduce right now for some reason). My symptoms were the shutdown process gets stuck for 2 seconds with error sending kill signals to some dbus process.

        A solution you could test, taking advantage of the desktop-session architecture, is to include an executable file named “shutdown” inside your $HOME/.desktop-session folder. Inside this, include the instruction to kill dbus-launch processes, and see if this is triggered correctly at shutdown.

        Example of $HOME/.desktop-session/shutdown

        #stop all dbus launch processes
        killall dbus-launch

        Probably the best solution would be to fix the dbus runit service so that dbus is properly stopped when the service stops. I will investigate this in the future.


          For some reason ~/.desktop-session/shutdown script is not running for me. LOAD_SHUTDOWN_FILE=”true” in desktop-session.conf and the execute permissions are set on the script, but it doesn’t seem to run at either shutdown or logout.

          Misbehaving dbus-daemon processes (and dconf.service processes) don’t seem to respond to killall from a terminal, though, so the shutdown script probably wouldn’t work either. Oddly, the same processes can be killed if I use lxtask, so I don’t know what that’s about.

          Anyway, it seems I was misunderstanding the ~/.desktop-session/startup script. The processes it launches do always seem to get restarted when you do a desktop restart, so it’s different from what I think of as a regular startup script. The ~/.icewm/startup script has more standard behavior, so I moved the pipewire call to there and now things seem to be behaving better for me.

          I still get a hang on shutdown sometimes due to a dconf-service process instead of dbus-daemon, so I’m omitting dconf-service PIDs in the shutdown script for now until I can find a better. Pipewire and dbus don’t get along on my system for some reason, but at least now only shutdown is affected.


            Would you mind editing /etc/sv/dbus/run and change the last line to:
            exec dbus-daemon --system --nofork --nopidfile

            This change is more inline with void. The previous configuration seems to be a modification of the devuan method.

            See if the issue with dbus-daemon (not dconf-service, as I don’t know who starts this process) really stops dbus daemon when the dbus service is stopped. I will also test it and see if there are any results in a few days.

            For some reason ~/.desktop-session/shutdown script is not running for me.

            If you add a line to write something to a file you can check if it is really running or not. Something like
            echo "entered desktop-session/shutdown" >> $HOME/some-file.log
            EDIT: On my installed system, the shutdown script isn’t running either. I will have to test on live-usb.

            • This reply was modified 10 months ago by abc-nix.
          Viewing 4 posts - 1 through 4 (of 4 total)
          • You must be logged in to reply to this topic.