Daemon - a small and powerful daemon supervisor, with (e)logind support, for babysitting our PipeWire's user target daemons - Testing Wanted

bassmadrigal · 03-02-2021, 06:16 PM

Quote:

Originally Posted by LuckyCyborg

Look, I believe that this thread is about this particular daemon supervisor which ZhaoLin1457 tried to adapt with a series of feature requests (in fact there is a big one: the elogind integration and several minor others), to solve a problem which the non-systemd distributions have today: how the heck we manage the "user target" daemons designed for systemd?

No matter how we start the PipeWire, be it from the global XDG autostart, be it from the user local one or even form ~/.profile fact is that PipeWire needs something which gives it a context kinda similar with systemd's user target service.

Today in the wild exists a single non-systemd program which is capable to ensure keeping alive a "user target" daemon and to quit it on user logout: this daemon supervisor which was tailored after months of discussions about what's best.

However, even the main suspect to be client of this daemon supervisor is PipeWire, its utility is heavily large. We have now a tool to simulate the systemd behavior for its user target services, then to be handled any other program of this type.

So, I believe that appropriate with the subject of this thread is IF we should adopt this little and smart daemon supervisor on Slackware and which advantages gives.

The point in getting daemon added into Slackware is for pipewire support. Sure, it may have additional benefits that can be used, but I think pipewire would currently be the main reason Pat would consider it.

Quote:

Originally Posted by LuckyCyborg

Did you ever used this PipeWire? Probably not, because you have known that there could not be such thing like /etc/rc.d/rc.pipewire because it is a service supposed to be started per user, after user logins and be stopped after user logouts. That's WHY we should invent particular supervisors and all those discussions.

No, I haven't used Pipewire, because I'm not running -current. But rc.pipewire (or something similar) could absolutely be supported, but not in the way you're thinking. It wouldn't be called by any startup scripts in /etc/rc.d/, but would be an easy place for admins to basically enable/disable the service without needing to edit things in /etc/xdg/autostart/ (as it is not common for admins to need to edit those files). Instead, there could be a /usr/bin/start-pipewire or some type of script that daemon can run that in turn will check and see if rc.pipewire is executable. rc.pipewire could then launch the actual pipewire executable.

Quote:

Originally Posted by LuckyCyborg

This PipeWire audio/video server is right now a requirement for Plasma5 on Wayland, otherwise many things does not work. And we do not started yet to use it as an audio server, when (trust me) we will find out that it cannot be started on demand. And let's do not talk about web browsers, as they started to use PipeWire for screen sharing and WebRTC.

Honestly I believe that making people to believe that's and can be optional, is a pretty bad idea as may introduce many strange and at first sight unrelated issues on system. Like: the remote desktop and taskbar thumbnails on Wayland/Plasma5 does not work, but also the Signal's screensharing does not work on XFCE and X11 and SkypeForWeb does not see the webcam.

It is optional if you are not running Plasma5 on Wayland (but becomes required if you are). Pat doesn't seem to be pushing Wayland + Plasma5 as the default to the masses right now (at least, not on purpose, although, I think sddm sometimes defaults to the Plasma5 Wayland session), so pipewire for most users won't need to be started just yet. As Wayland becomes more prevalent and solid, then I suppose Pat will start favoring Wayland over Xorg.

0XBF · 03-02-2021, 07:09 PM

I built the daemon program using OP's scripts and tried running it using the suggested autostart script:

Quote:

Originally Posted by ZhaoLin1457

The usage is quite simple. To start the PipeWire instance supervised by this "daemon" you need only a XDG .desktop file put on /etc/xdg/autostart/pipewire.desktop with this content:

Code:

Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -fB /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1

It does not seem to work properly for me. Also note that pulseaudio is also on the autostart list and if it beats pipewire in the race then pipewire will detect it and refuse to start.

I tried disabling pulseaudio first with an xdg autostart script copying the system pulseaudio.desktop to my ~/.config/autostart and setting it to "Hidden=true". However that no longer disables pulseaudio from autostarting. I would hazard a guess that now that pulse has elogind support built in that its getting a cue to autostart from elogind or something. I had to disable pulseaudio with "autospawn=no" in a custom ~/.config/pulse/client.conf to stop it finally.

From there I got no audio server, with daemon installed and the xdg autostart script in place. I also tried putting it in ~/.config/autostart but no luck there either. If I enter the Exec line "/usr/bin/daemon -fB /usr/bin/pipewire" directly into a terminal it starts and runs until logout as expected. Not sure what to make of the not autostarting though.

LuckyCyborg · 03-02-2021, 07:30 PM

Quote:

Originally Posted by 0XBF

I built the daemon program using OP's scripts and tried running it using the suggested autostart script:

It does not seem to work properly for me. Also note that pulseaudio is also on the autostart list and if it beats pipewire in the race then pipewire will detect it and refuse to start.

I tried disabling pulseaudio first with an xdg autostart script copying the system pulseaudio.desktop to my ~/.config/autostart and setting it to "Hidden=true". However that no longer disables pulseaudio from autostarting. I would hazard a guess that now that pulse has elogind support built in that its getting a cue to autostart from elogind or something. I had to disable pulseaudio with "autospawn=no" in a custom ~/.config/pulse/client.conf to stop it finally.

From there I got no audio server, with daemon installed and the xdg autostart script in place. I also tried putting it in ~/.config/autostart but no luck there either. If I enter the Exec line "/usr/bin/daemon -fB /usr/bin/pipewire" directly into a terminal it starts and runs until logout as expected. Not sure what to make of the not autostarting though.

Well, apparently those days this daemon supervisor source code was a moving target...

Looks like that additional features was added to complete what they discussed, and right now the code is on polishing stage - I seen a post from @raforg about a imminent next release.

So, I suggest you to look for the later post here of @ZhaoLin1457 as I followed the trip and every time it worked.

I for one, I use this right now with the latest git commits:

/etc/xdg/autostart/pipewire.desktop

Code:

[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -f -n pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1

/etc/daemon.conf.d

Code:

pipewire bind,respawn,pidfiles=~/.daemon

With the note that looks like the patch proposed here should not applied anymore. Anyway it does not apply clean anymore.

Code:

vanya@darkstar:~# ps xa | grep pipewire
 1868 ?        S      0:00 /usr/bin/daemon -f -n pipewire /usr/bin/pipewire
 1881 ?        Sl     0:00 pipewire: /usr/bin/pipewire
 1893 ?        Sl     0:00 /usr/bin/pipewire-media-session
 9629 pts/7    S+     0:00 grep pipewire
vanya@darkstar:~#

From what I read from the daemon's man page, it have extensive logging (even to syslog) and debugging features, you may try to enable them for debugging.

ZhaoLin1457 · 03-02-2021, 07:45 PM

Hi,

this is the latest build system:

daemon.SlackBuild

Code:

#!/bin/bash

# Copyright 2005-2018  Patrick J. Volkerding, Sebeka, MN, USA
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

cd $(dirname $0) ; CWD=$(pwd)

PKGNAM=daemon
VERSION=${VERSION:-$(echo $PKGNAM-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}
BUILD=${BUILD:-1}

NUMJOBS=${NUMJOBS:-" -j$(expr $(nproc) + 1) "}

# Automatically determine the architecture we're building on:
if [ -z "$ARCH" ]; then
  case "$( uname -m )" in
    i?86) export ARCH=i586 ;;
    arm*) export ARCH=arm ;;
    # Unless $ARCH is already set, use uname -m for all other archs:
       *) export ARCH=$( uname -m ) ;;
  esac
fi

# If the variable PRINT_PACKAGE_NAME is set, then this script will report what
# the name of the created package would be, and then exit. This information
# could be useful to other scripts.
if [ ! -z "${PRINT_PACKAGE_NAME}" ]; then
  echo "$PKGNAM-$VERSION-$ARCH-$BUILD.txz"
  exit 0
fi

TMP=${TMP:-/tmp}
PKG=$TMP/package-$PKGNAM

rm -rf $PKG
mkdir -p $TMP $PKG
cd $TMP
rm -rf $PKGNAM-$VERSION
tar xvf $CWD/$PKGNAM-$VERSION.tar.?z || exit 1
cd $PKGNAM-$VERSION || exit 1
chown -R root:root .
find . \
  \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \
  -exec chmod 755 {} \+ -o \
  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
  -exec chmod 644 {} \+

./configure --prefix=/usr

make $NUMJOBS || make || exit 1
make html || exit 1
make install DESTDIR=$PKG
make install-daemon-conf DESTDIR=$PKG

mv $PKG/etc/daemon.conf $PKG/etc/daemon.conf.new

mkdir -p $PKG/usr/doc/$PKGNAM-$VERSION
cp -a \
  COPYING* INSTALL LICENSE README* REFERENCES daemon.1.html \
  $PKG/usr/doc/$PKGNAM-$VERSION

# If there's a CHANGELOG, installing at least part of the recent history
# is useful, but don't let it get totally out of control:
if [ -r CHANGELOG ]; then
  DOCSDIR=$(echo $PKG/usr/doc/*-$VERSION)
  cat CHANGELOG | head -n 1000 > $DOCSDIR/CHANGELOG
  touch -r CHANGELOG $DOCSDIR/CHANGELOG
fi

mkdir -p $PKG/install
cat $CWD/doinst.sh > $PKG/install/doinst.sh
cat $CWD/slack-desc > $PKG/install/slack-desc

# Build the package:
cd $PKG
/sbin/makepkg -l y -c n $TMP/$PKGNAM-$VERSION-$ARCH-$BUILD.txz

doinst.sh

Code:

#!/bin/sh
config() {
  NEW="$1"
  OLD="`dirname $NEW`/`basename $NEW .new`"
  # If there's no config file by that name, mv it over:
  if [ ! -r $OLD ]; then
    mv $NEW $OLD
  elif [ "`cat $OLD | md5sum`" = "`cat $NEW | md5sum`" ]; then # toss the redundant copy
    rm $NEW
  fi
  # Otherwise, we leave the .new copy for the admin to consider...
}

config etc/daemon.conf.new

slack-desc

Code:

# HOW TO EDIT THIS FILE:
# The "handy ruler" below makes it easier to edit a package description. Line
# up the first '|' above the ':' following the base package name, and the '|'
# on the right side marks the last column you can put a character in. You must
# make exactly 11 lines for the formatting to be correct. It's also
# customary to leave one space after the ':'.


      |-----handy-ruler------------------------------------------------------|
daemon: daemon (turns other processes into daemons)
daemon:
daemon: Daemon turns other processes into daemons. There are many tasks that
daemon: need to be performed to correctly set up a daemon process. This can
daemon: be tedious. Daemon performs these tasks for other processes. This is
daemon: useful for writing daemons in languages other than C, C++ or Perl
daemon: (e.g. `/bin/sh`, Java).
daemon:
daemon: http://libslack.org/daemon/
daemon:
daemon:

fetch-daemon.sh

Code:

#!/bin/sh

# Copyright 2019  Patrick J. Volkerding, Sebeka, Minnesota, USA
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

# Pull a stable branch + patches
BRANCH=${1:-main}

# Clear download area:
rm -rf daemon

# Clone repository:
git clone https://github.com/raforg/daemon.git

# checkout $BRANCH:
( cd daemon 
  git checkout $BRANCH || exit 1
)

HEADISAT="$( cd daemon && git log -1 --format=%h )"
DATE="$( cd daemon && git log -1 --format=%cd --date=format:%Y%m%d )"
LONGDATE="$( cd daemon && git log -1 --format=%cd --date=format:%c )"
# Cleanup.  We're not packing up the whole git repo.
( cd daemon && find . -type d -name ".git*" -exec rm -rf {} \; 2> /dev/null )
mv daemon daemon-${DATE}_${HEADISAT}
tar cf daemon-${DATE}_${HEADISAT}.tar daemon-${DATE}_${HEADISAT}
xz -9 -f daemon-${DATE}_${HEADISAT}.tar
rm -rf daemon-${DATE}_${HEADISAT}
touch -d "$LONGDATE" daemon-${DATE}_${HEADISAT}.tar.xz
echo
echo "daemon branch $BRANCH with HEAD at $HEADISAT packaged as daemon-${DATE}_${HEADISAT}.tar.xz"
echo

The XDG autostart file and the additional configuration file are as described by @LuckyCyborg there:

https://www.linuxquestions.org/quest...ml#post6226672

/etc/xdg/autostart/pipewire.desktop

Code:

[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -f -n pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1

/etc/daemon.conf.d/pipewire.conf

Code:

pipewire bind,respawn,pidfiles=~/.daemon

Please fetch the latest source code for using with this.

ZhaoLin1457 · 03-02-2021, 07:54 PM

Quote:

Originally Posted by LuckyCyborg

Well, apparently those days this daemon supervisor source code was a moving target...

Looks like that additional features was added to complete what they discussed, and right now the code is on polishing stage - I seen a post from @raforg about a imminent next release.

Yes, in the last days in the daemon's source code was added the features which we discussed in precedence and there was a lot of commits.

However, now the things should be calmed down, as he @raforg announced that he prepares for the next release tomorrow.

https://github.com/raforg/daemon/iss...ment-789295070

0XBF · 03-02-2021, 08:23 PM

Okay I got the xdg autostart working properly. Not sure what the issue was before but I rebuilt to the latest post and set up that conf file in /etc/daemon.conf.d and its starting. Side question: Is there any reason thats a better method than using the flags for bind, respawn, and pidfiles? (i.e. "/usr/bin/daemon -f -B -r --pidfiles=~/.daemon /usr/bin/pipewire")

Anyways, now I that its starting properly I have run into a second problem: pipewire-pulse. Are you guys running this at all? It is meant to run in place of a pulseaudio server and allows programs that expect pulse to still run. The recommended way to start pipewire-pulse AFAIK is via the /etc/pipewire/pipewire.conf file, in the last stanza:

Code:

exec = {
    ## <program-name> = { [args = "<arguments>"] }
    #
    # Execute the given program with arguments.
    #
    # Start the session manager. Run the session manager with -h for
    # options.
    #
    # The bluetooth module is disabled by default because it causes
    # conflicts with PulseAudio. If you disable PulseAudio or don't
    # load its bluetooth module, you can enable it here with -e bluez5
    #
    "/usr/bin/pipewire-media-session" = { args = "bluez5"}
    #
    # You can optionally start the pulseaudio-server here as well
    # but it better to start it as a systemd service.
    # It can be interesting to start another daemon here that listens
    # on another address with the -a option (eg. -a tcp:4713)
    #
    "/usr/bin/pipewire-pulse" = { "#args" = "-a tcp:4713" }
}

Which I have uncommented and it starts pipewire-pulse fine. However daemon misses this one when exiting. Prior to last logout I get:

Code:

$ ps aux | grep pipewire
bob      23364  0.0  0.0   4112  2680 ?        S    20:06   0:00 /usr/bin/daemon -f -n pipewire /usr/bin/pipewire
bob      23369  0.0  0.1 101600  9560 ?        S<l  20:06   0:00 pipewire: /usr/bin/pipewire
bob      23374  0.1  0.2 147404 16756 ?        S<l  20:06   0:00 /usr/bin/pipewire-media-session bluez5
bob      23375  0.0  0.0  81468  5472 ?        S<l  20:06   0:00 /usr/bin/pipewire-pulse
bob      23678  0.0  0.0   3996  2152 pts/1    S+   20:07   0:00 grep pipewire

Then logout and back in, I get:

Code:

bob      23364  0.0  0.0   4112  2680 ?        S    20:06   0:00 /usr/bin/daemon -f -n pipewire /usr/bin/pipewire
bob      23369  0.0  0.0      0     0 ?        Z<   20:06   0:00 [pipewire] <defunct>
bob      23375  0.0  0.0  81468  5472 ?        S<l  20:06   0:00 /usr/bin/pipewire-pulse
bob      23765  0.0  0.0   4004  2128 tty1     S+   20:08   0:00 grep pipewire

If the pipewire-pulse line is commented out in /etc/pipewire/pipewire.conf then there is no left over programs running after logout (i.e. pipewire and pipewire-media-session exit fine, just not pipewire-pulse).

I was handling this problem with killing pipewire programs with wrapper scripts till now, and have been using the line "pkill --parent $PIPEWIRE_PID" before killing pipewire to get around this problem. Not sure how best to proceed with daemon, perhaps as another autostart service?

LuckyCyborg · 03-02-2021, 08:33 PM

Quote:

Originally Posted by 0XBF

Okay I got the xdg autostart working properly. Not sure what the issue was before but I rebuilt to the latest post and set up that conf file in /etc/daemon.conf.d and its starting. Side question: Is there any reason thats a better method than using the flags for bind, respawn, and pidfiles? (i.e. "/usr/bin/daemon -f -B -r --pidfiles=~/.daemon /usr/bin/pipewire")

Anyways, now I that its starting properly I have run into a second problem: pipewire-pulse. Are you guys running this at all? It is meant to run in place of a pulseaudio server and allows programs that expect pulse to still run. The recommended way to start pipewire-pulse AFAIK is via the /etc/pipewire/pipewire.conf file, in the last stanza:

Code:

exec = {
    ## <program-name> = { [args = "<arguments>"] }
    #
    # Execute the given program with arguments.
    #
    # Start the session manager. Run the session manager with -h for
    # options.
    #
    # The bluetooth module is disabled by default because it causes
    # conflicts with PulseAudio. If you disable PulseAudio or don't
    # load its bluetooth module, you can enable it here with -e bluez5
    #
    "/usr/bin/pipewire-media-session" = { args = "bluez5"}
    #
    # You can optionally start the pulseaudio-server here as well
    # but it better to start it as a systemd service.
    # It can be interesting to start another daemon here that listens
    # on another address with the -a option (eg. -a tcp:4713)
    #
    "/usr/bin/pipewire-pulse" = { "#args" = "-a tcp:4713" }
}

Which I have uncommented and it starts pipewire-pulse fine. However daemon misses this one when exiting. Prior to last logout I get:

Code:

$ ps aux | grep pipewire
bob      23364  0.0  0.0   4112  2680 ?        S    20:06   0:00 /usr/bin/daemon -f -n pipewire /usr/bin/pipewire
bob      23369  0.0  0.1 101600  9560 ?        S<l  20:06   0:00 pipewire: /usr/bin/pipewire
bob      23374  0.1  0.2 147404 16756 ?        S<l  20:06   0:00 /usr/bin/pipewire-media-session bluez5
bob      23375  0.0  0.0  81468  5472 ?        S<l  20:06   0:00 /usr/bin/pipewire-pulse
bob      23678  0.0  0.0   3996  2152 pts/1    S+   20:07   0:00 grep pipewire

Then logout and back in, I get:

Code:

bob      23364  0.0  0.0   4112  2680 ?        S    20:06   0:00 /usr/bin/daemon -f -n pipewire /usr/bin/pipewire
bob      23369  0.0  0.0      0     0 ?        Z<   20:06   0:00 [pipewire] <defunct>
bob      23375  0.0  0.0  81468  5472 ?        S<l  20:06   0:00 /usr/bin/pipewire-pulse
bob      23765  0.0  0.0   4004  2128 tty1     S+   20:08   0:00 grep pipewire

If the pipewire-pulse line is commented out in /etc/pipewire/pipewire.conf then there is no left over programs running after logout (i.e. pipewire and pipewire-media-session exit fine, just not pipewire-pulse).

I was handling this problem with killing pipewire programs with wrapper scripts till now, and have been using the line "pkill --parent $PIPEWIRE_PID" before killing pipewire to get around this problem. Not sure how best to proceed with daemon, perhaps as another autostart service?

I believe that you should make another XDG autostart service for pipewire-pulse. The question is how to keep the order of starting them...

Quote:

# You can optionally start the pulseaudio-server here as well
# but it better to start it as a systemd service.

That probably we should read as another daemon supervised running instance.

BTW, honestly I for one, I don't used yet the pipewire-pulse.

Regarding the config files, I understand that some elements can be reusable, for example you can set

Code:

* pidfiles=~/.daemon

And this will apply to any instance.

But probably @ZhaoLin1457 can explain better for what they are better to use...

LuckyCyborg · 03-03-2021, 02:32 AM

I've managed to configure the PipeWire and is PulseAudio compat audio server, by using a separate (autostart) services for them.

/etc/daemon.conf.d/pipewire.conf

Code:

pipewire-main  bind,respawn,pidfiles=~/.daemon
pipewire-pulse bind,respawn,pidfiles=~/.daemon

/etc/xdg/autostart/pipewire-main.desktop

Code:

[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -f -n pipewire-main /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1

/etc/xdg/autostart/pipewire-pulse.desktop

Code:

[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -f -n pipewire-pulse /usr/bin/pipewire-pulse
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1

So, the PipeWire daemons works for me both as audio and video and no matter if I login and logout as root or unprivileged user, the result is always:

Code:

vanya@darkstar:~# ps xa | grep pipewire
 2978 ?        S      0:00 /usr/bin/daemon -f -n pipewire-pulse /usr/bin/pipewire-pulse
 2985 ?        Sl     0:00 pipewire-pulse: /usr/bin/pipewire-pulse
 2990 ?        S      0:00 /usr/bin/daemon -f -n pipewire-main /usr/bin/pipewire
 2992 ?        Sl     0:00 pipewire-main: /usr/bin/pipewire
 2995 ?        Sl     0:00 /usr/bin/pipewire-media-session bluez5
 3372 pts/7    S+     0:00 grep pipewire
vanya@darkstar:~#

BTW, I've disabled the PulseAudio globally on /etc/pulse/client.conf for "autospawn = no" and adding "Hidden=true" on /etc/xdg/autostart/pulseaudio.desktop

igadoter · 03-03-2021, 02:40 AM

Perhaps such Pipeire behavior is just bug. What's opinion of KDE developers about this situation?

chris.willing · 03-03-2021, 02:46 AM

Is the xdg autostart mechanism OK for non-graphical logins? I guess the video side of pipewire implies there is a graphical login but if the daemon supervisor is supposed to be generic, then other non-graphical daemons need to be supported; hence a way to autostart the supervisor too.

chris

LuckyCyborg · 03-03-2021, 02:48 AM

Quote:

Originally Posted by igadoter

Perhaps such Pipeire behavior is just bug. What's opinion of KDE developers about this situation?

The PipeWire is not developed by KDE, but it is a RedHat project.

And perhaps is just about our wrong setup of it, because looks like the openSUSE uses separate systemd (user) services for pipewire, pipewire-mediasession and pipewire-pulse.

LuckyCyborg · 03-03-2021, 02:52 AM

Quote:

Originally Posted by chris.willing

Is the xdg autostart mechanism OK for non-graphical logins? I guess the video side of pipewire implies there is a graphical login but if the daemon supervisor is supposed to be generic, then other non-graphical daemons need to be supported; hence a way to autostart the supervisor too.

chris

The XDG autostart mechanism is for desktop sessions only.

Probably we could launch well the supervised PipeWire daemons from ~/.profile as the daemon itself goes happy on background, but from what I understand, the PipeWire things needs a valid DBUS session setup.

BUT, for what is good a video server on console?

However, the daemon itself is a console application with no graphics requirements, which I seen in its docs that can run also in init scrips and even launched by inetd.

LuckyCyborg · 03-03-2021, 03:00 AM

WOW! The PipeWire is much better than PulseAudio on handling bluetooth devices!

My bluetooth speakers connects and disconnects absolutely perfect.

With PulseAudio I needed several tries for the associated controls to appear on the PulseAudio applet of Plasma5.

igadoter · 03-03-2021, 03:01 AM

Quote:

Originally Posted by LuckyCyborg

The PipeWire is not developed by KDE, but it is a RedHat project.

And perhaps is just about our wrong setup of it, because looks like the openSUSE uses separate systemd (user) services for pipewire, pipewire-mediasession and pipewire-pulse.

That's bad. I am not surprised to see here systemd. Perhaps correct question is: can we run PipeWire without systemd?

LuckyCyborg · 03-03-2021, 03:03 AM

Quote:

Originally Posted by igadoter

That's bad. I am not surprised to see here systemd. Perhaps correct question is: can we run PipeWire without systemd?

Did you ever read this very thread before asking this?

For what the heck you think we invented a daemon supervisor with elogind integration?

Yes, we can run properly those PipeWire daemons without systemd, using the daemon supervisor which is the subject of this thread.