Daemon - a small and powerful daemon supervisor, with (e)logind support, for babysitting our PipeWire's user target daemons - Testing Wanted
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The daemon program itself isn't the issue. It's small and seems to do nothing unless configured.
However, the *reason* to add daemon to Slackware *right now* is pipewire. There is nothing else in Slackware that *needs* daemon. It's even in the title of the thread ("for babysitting our PipeWire's user target daemons"). So you can talk about how old daemon is, how much supervising processes occur in other distros, how it can be used to help automate php or some foot smelling program, and more, but that's not why I asked the questions I asked...
The reason ZhaoLin1457 started working this issue was to get something to launch pipewire when Wayland/Plasma5 starts and to exit pipewire when that user's session ends. He was able to find the daemon program and was able to get the developer to add the potential support needed. Now we need to get into the technical issues of adding daemon to the OS and launching/exiting pipewire. Based on discussion here, it seems adding daemon to the OS is minor and a non-issue, so that's why my focus shifted to what effects it would have when using it for pipewire.
If daemon is added and pipewire is set up to launch and exit with users logging in or logging out, does that only occur on Wayland/Plasma5 (since AFAIK, that's the only DE that currently requires it)? If it doesn't, then does it launch with any/all DEs/WMs? If so, does launching pipewire for these other DEs/WMs cause any problems?
If it doesn't cause problems and can function with all X11 and Wayland DEs/WMs, is it solid enough to take over for all those and become the primary video/audio server?
All the potential problems with adding daemon and setting up pipewire to launch/exit when needed should be found and addressed to simplify the work Pat needs to do if/when he decides to throw the switch and integrate these things into Slackware.
I'm not trying to stop daemon from being added or pipewire from launching, but rather go through the technical discussions so if it is decided to add daemon Slackware to support pipewire launching/exiting, that the transition is smooth and that it falls into the "just works" aspect of so many other things in Slackware.
How the heck you use this daemon for running and stopping that dnscrypt-proxy on user logout, when it got this feature of elogind integration only yesterday and its own developer claims that he made it with Zhao Lin, who I guess is our OP?
I'm using this daemon for start-stop dnscrypt-proxy and several user daemon is not related with elogind support. I'm using in user autostart. But if daemon can be started from global autostart and it can talk with elogind then I'll be using that feature instead.
I wrote a small "elogind-dispatcher" bash script a couple months ago that listens to login1 and runs any executable .sh scripts in a users $HOME/elogind-dispatcher directory (passing "up" at first login and "down" at last logout).
I spent some time yesterday to edit my launch scripts to use the new daemon tool, which were simplified quite a bit by not having to track and kill processes now that daemon does that. Currently I have it starting a session dbus, followed by pipewire and pipewire-pulse at first login, and they all exit at logout. It's been running fine so far and it provides pipewire integration across both console and graphical sessions (only tested at runlevel 3 so far). I still need to test it further but having a user daemon service that starts at boot is not impossible and this tool makes it a little easier to manage that.
#!/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) ARCH=i586 ;;
arm*) readelf /usr/bin/file -A | egrep -q "Tag_CPU.*[4,5]" && ARCH=arm || ARCH=armv7hl ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) ARCH=$(uname -m) ;;
esac
export ARCH
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
if [ "$ARCH" = "i386" ]; then
SLKCFLAGS="-O2 -march=i386 -mcpu=i686"
elif [ "$ARCH" = "i486" ]; then
SLKCFLAGS="-O2 -march=i486 -mtune=i686"
elif [ "$ARCH" = "i586" ]; then
SLKCFLAGS="-O2 -march=i586 -mtune=i686"
elif [ "$ARCH" = "i686" ]; then
SLKCFLAGS="-O2 -march=i686"
elif [ "$ARCH" = "s390" ]; then
SLKCFLAGS="-O2"
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
elif [ "$ARCH" = "armv7hl" ]; then
SLKCFLAGS="-O3 -march=armv7-a -mfpu=vfpv3-d16"
else
SLKCFLAGS="-O2"
fi
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 \
--enable-logind
make $NUMJOBS CFLAGS="$SLKCFLAGS" || exit 1
make install DESTDIR=$PKG || exit 1
make install-daemon-conf DESTDIR=$PKG || exit 1
make install-daemon-html DESTDIR=$PKG DAEMON_HTMLDIR=/usr/doc/$PKGNAM-$VERSION || exit 1
mv $PKG/etc/daemon.conf $PKG/etc/daemon.conf.new
mkdir -p $PKG/usr/doc/$PKGNAM-$VERSION
cp -a \
COPYING* INSTALL LICENSE README* REFERENCES \
$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
The other parts of build remains unchanged.
Please note that the (e)logind support becomes optional after the last commits, then it should be enabled on configure with the configure switch "--enable-logind"
Last edited by ZhaoLin1457; 03-04-2021 at 10:29 AM.
If daemon is added and pipewire is set up to launch and exit with users logging in or logging out, does that only occur on Wayland/Plasma5 (since AFAIK, that's the only DE that currently requires it)? If it doesn't, then does it launch with any/all DEs/WMs?
Well, IF will be adopted this global XDG autostart as place from where is launched the PipeWire daemons, they will start for any XDG compliant desktop. Not sure about the smaller WMs, but certainly they would be launched for Plasma5, both on Wayland and X11, and on XFCE.
I have no idea how you can launch a program (no matter what) only on Wayland/Plasma5 via XDG autostart, which looks the perfect place to be used for starting the PipeWire daemons.
Quote:
Originally Posted by bassmadrigal
If so, does launching pipewire for these other DEs/WMs cause any problems?
As someone who uses PipeWire main daemon since more than a half of year - since it was put in KTown and I discovered how to start it via XDG autostart, that PipeWire (main) daemon had been active in all my boxes, no matter if I was on Wayland or a X11 session.
Because there's also the way to launch it directly from XDG autostart and kill it with elogind configured to kill user processes.
Do not imagine that we must use this daemon supervisor to run PipeWire and being against it, you can block the PipeWire usage.
So, I do not seen it causing problems on Plasma5 or XFCE. It does even not conflict with PulseAudio. I have ran PipeWire along with PulseAudio until recently.
Now I switched also audio to PipeWire because it handles way better the bluetooth audio devices. At least for me.
Quote:
Originally Posted by bassmadrigal
If it doesn't cause problems and can function with all X11 and Wayland DEs/WMs, is it solid enough to take over for all those and become the primary video/audio server?
About what video/audio server you talk? There is no another audio/video server on Slackware.
Yes, there's PulseAudio as audio server, but I ran it as audio server on Wayland/Plasma5 since more than a half a year, while PipeWire being active and doing its video business. E.g. doing its work with the taskbar thumbnails.
And on PipeWire the single thing which probably conflicts with PulseAudio, is the second daemon, that pipewire-pulse compat thing, which Fedora 34 would use by default since this Spring.
BUT, I for one, and I guess that anyone else, has no intention to propose to Slackware to replace PulseAudio server for the version 15.0
Quote:
Originally Posted by bassmadrigal
All the potential problems with adding daemon and setting up pipewire to launch/exit when needed should be found and addressed to simplify the work Pat needs to do if/when he decides to throw the switch and integrate these things into Slackware.
So, you believe that those eventual issues will be found keeping the PipeWire dead, just as a dead weight dependency?
Or we will find those issues while doing thought experiments like you, who comment and lament on a thread about inventing things for Slackware 15.0, while you stay on Slackware 14.2?
At least you can install the Slackware -current on a SD-card, like ZhaoLin1457, and see yourself how the things behave and what happens on -current.
And please stop associating the daemon with PipeWire as "issues".
I am fully convinced that there are NO issues with adding this daemon supervisor on Slackware.
Maybe on Slackware itself is nothing other than PipeWire which needs it, but for users it is a fantastic useful little thingy. I've already modified some init scripts of mine to use it and it does a nice job right on /etc/rc.d
Last edited by LuckyCyborg; 03-04-2021 at 05:48 PM.
Well, IF will be adopted this global XDG autostart as place from where is launched the PipeWire daemons, they will start for any XDG compliant desktop. Not sure about the smaller WMs, but certainly they would be launched for Plasma5, both on Wayland and X11, and on XFCE.
I have no idea how you can launch a program (no matter what) only on Wayland/Plasma5 via XDG autostart, which looks the perfect place to be used for starting the PipeWire daemons.
As someone who uses PipeWire main daemon since more than a half of year - since it was put in KTown and I discovered how to start it via XDG autostart, that PipeWire (main) daemon had been active in all my boxes, no matter if I was on Wayland or a X11 session.
Because there's also the way to launch it directly from XDG autostart and kill it with elogind configured to kill user processes.
So, I do not seen it causing problems on Plasma5 or XFCE. It does even not conflict with PulseAudio. I have ran PipeWire along with PulseAudio until recently.
Now I switched also audio to PipeWire because it handles way better the bluetooth audio devices. At least for me.
So, if daemon is added and pipewire is set to use xdg autostart, pipewire will start with every xdg compliant WM/DE, but seems to have no issues in doing so? Great to hear!
Quote:
Originally Posted by LuckyCyborg
Do not imagine that we must use this daemon supervisor to run PipeWire and being against it, you can block the PipeWire usage.
Where are you getting that I'm against pipewire? I've never said that. I want to make sure that pipewire works properly on Slackware if daemon is added and launching via xdg autostart is implemented.
Quote:
Originally Posted by LuckyCyborg
About what video/audio server you talk? There is no another audio/video server on Slackware.
I never mentioned another video/audio server, but was talking about having pipewire be primetime.
Quote:
Originally Posted by LuckyCyborg
So, you believe that those eventual issues will be found keeping the PipeWire dead, just as a dead wight dependency?
Again, I am not against pipewire, I just want to make sure it works properly if Slackware launches it automatically with xdg compliant WMs/DEs.
Quote:
Originally Posted by LuckyCyborg
Or we will find those issues while doing thought experiments like you, who comment and lament on a thread about inventing things for Slackware 15.0, while you stay on Slackware 14.2?
At least you can install the Slackware -current on a SD-card, like ZhaoLin1457, and see yourself how the things behave and what happens on -current.
I'm sorry that my 14.2 install is too important to me to rely on -current. It runs internet services for many people other than me and I try to minimize downtime with it. I don't need to install it on an sd card as I have plenty of thumbdrives and can use Slackware Live, but then I'd need to take my computer down and lose all the web services while it's down and I'm testing -current.
Sorry I don't meet your idea of a Slackware user. However, that won't prevent me from trying to make sure 15.0 is a solid release!
Quote:
Originally Posted by LuckyCyborg
And please stop associating the daemon with PipeWire as "issues".
Please stop associating my posts as insinuating issues exist with daemon and/or pipewire. I want to try and find any potential issues so they can be resolved. Since I'm not able/willing to run -current, I have to pose those questions to others.
Quote:
Originally Posted by LuckyCyborg
I am fully convinced that there are NO issues with adding this daemon supervisor on Slackware.
I never suspected there were issues with daemon (which I said in my SECOND line on the post you quoted). Please read my full posts before responding so you can actually know what you're responding to. It would've saved many bytes of data...
In pipewire 0.3.23, the default config file now contains:
Code:
# Execute the given program with arguments.
#
# You can optionally start the session manager here,
# but it is better to start it as a systemd service.
# Run the session manager with -h for options.
#
#"/usr/bin/pipewire-media-session" = { args = "" }
So, just like pipewire-pulse, I guess pipewire-media-session should be started independently of pipewire.
In pipewire 0.3.23, the default config file now contains:
Code:
# Execute the given program with arguments.
#
# You can optionally start the session manager here,
# but it is better to start it as a systemd service.
# Run the session manager with -h for options.
#
#"/usr/bin/pipewire-media-session" = { args = "" }
So, just like pipewire-pulse, I guess pipewire-media-session should be started independently of pipewire.
Yup, I told already that openSUSE uses separate systemd services for the PipeWire's triad.
I for one, I use the following XDG autostart file:
/etc/xdg/autostart/pipewire-media-session.desktop
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media Session
Comment=Start the PipeWire Media Session
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
As you can see, I renounced to set particular options on a daemon config file and this works with no visible differences.
Last edited by LuckyCyborg; 03-05-2021 at 04:43 AM.
I have no idea how you can launch a program (no matter what) only on Wayland/Plasma5 via XDG autostart, which looks the perfect place to be used for starting the PipeWire daemons.
You can specify the desktop environments that must autostart an application through the key OnlyShowIn (see here), like in example below :
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media Session
Comment=Start the PipeWire Media Session
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
OnlyShowIn=KDE;XFCE;
In the example above, "PipeWire Media Session" is autostarted only by plasma (with or without wayland) or XFCE.
But, if you want "PipeWire Media Session" to be autostarted only by plasma/wayland, OnlyShowIn is not the solution. Instead, you can use the following hack :
Code:
Version=1.0
Name=PipeWire Media Session
Comment=Start the PipeWire Media Session
Exec=[ "$DESKTOP_SESSION" = "/usr/share/wayland-sessions/plasmawayland" ] && /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session[/COLOR]
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
You can specify the desktop environments that must autostart an application through the key OnlyShowIn (see here), like in example below :
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media Session
Comment=Start the PipeWire Media Session
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
OnlyShowIn=KDE;XFCE;
In the example above, "PipeWire Media Session" is autostarted only by plasma (with or without wayland) or XFCE.
But, if you want "PipeWire Media Session" to be autostarted only by plasma/wayland, OnlyShowIn is not the solution. Instead, you can use the following hack :
Code:
Version=1.0
Name=PipeWire Media Session
Comment=Start the PipeWire Media Session
Exec=[ "$DESKTOP_SESSION" = "/usr/share/wayland-sessions/plasmawayland" ] && /usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session[/COLOR]
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
--
SeB
Well, apparently the shell variables aren't expanded on those desktop files, if we rated the conversation between @ZhaoLin1457 and @raforg, the daemon's author:
I understand that the daemon supervisor got the feature of expanding itself variables from command line or configuration, right to circumvent this behavior.
So, there should be used eventually the shell.
BUT, it is worth to put this condition, considering that anyway tons of things are loaded in memory just in case?
For example, for what is haveged good for, considering that it was an workaround to a Linux issue fixed long time ago?
Anyways, I for one I do not need to condition the execution, because since several days I use PipeWire also as audio server, instead of PulseAudio one, so it should run in any desktop.
Again, I have no intention to propose to Slackware to do also this audio server switch, but it is nice to have alternatives, specially when the alternate solution works better.
Last edited by LuckyCyborg; 03-05-2021 at 01:39 PM.
Well, apparently the shell variables aren't expanded on those desktop files, if we rated the conversation between @ZhaoLin1457 and @raforg, the daemon's author:
It does not matter, because even systemd does not condition the execution for a particular WM/DE of the XDG autostart files or its targets, even it have a myriad of targets instead of 6 runlevels.
Honestly, I truly hope that Mr. Poettering does not read this particular thread and even if he does, will not notice those ideas ventilated here about conditional XDG autostart, and even he will notice them, he will just give a good laugh and call a day.
Otherwise, I praise God to save our sorry arses.
Last edited by LuckyCyborg; 03-06-2021 at 11:24 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.