LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-02-2021, 02:22 AM   #1
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,022

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


If you experimented with the PipeWire, either for bringing its services up for Wayland/Plasma5 or you wanted it as PulseAudio replacement, you know that it is a special kind of "daemon", basically just a program which has no idea to stop itself on user logout like PulseAudio, supposed to be managed by systemd as a "user target" service.

From the various experiments, looks like we have a proper way to start this PipeWire daemon, on early stage of desktop session's loading, using the XDG autostart.

However, until now, we haven't a consistent way to stop it on user logout, out of instructing elogind to kill user processes on logout. And this is not a desired behavior by many, as also are killed things like screen or tmux.

I believe that (ideally) we need a generic way to handle auto-quitting on user logout, considering that in future maybe we will want to handle more of those "user target" services designed for systemd based distributions.

A generic way like this is a daemon supervisor integrated with (e)logind which knows to quit its client program (and its own instance) on user logout, but there was no such thing.

So, I proposed this (e)logind integration (for auto-quitting) to the developer of "daemon", a small but features rich daemon supervisor which is capable to turn on well behaved daemons even bash scripts.

https://github.com/raforg/daemon/issues/1

The feature request was accepted and now its implementation is on advanced stage - soon will be made a stable release with it.

So, as more testing as we can is needed. Specially on Slackware, because it was requested and "designed" specially for it.

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
On the graphical session startup the "daemon" will be executed with instructions to run "pipewire" and to watch user sessions for logout. And to stay on foreground, BTW...

No more customization is needed, as the "daemon" will known to quit itself and its client on user logout.

As I tested myself, this works fine, both as root and unprivileged user, but will be very useful if there's more testing. With the note that the developer himself uses Debian and tests it against systemd, so we are only who can test this feature exactly for what we need it.

To build this "daemon" we need to grab the code from its "main" branch from GitHub, and bellow the scripts which I use.

fetch-daemon.sh was borrowed and adapted from Mr. Volkerding's fetch-efibootmgr.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
daemon.SlackBuild was also adapted from one of Mr. Volkerding's build scripts.
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

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/slack-desc > $PKG/install/slack-desc

# Build the package:
cd $PKG
/sbin/makepkg -l y -c n $TMP/$PKGNAM-$VERSION-$ARCH-$BUILD.txz
And the associated 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:
Like I said, from my own tests, looks like the "daemon" handles well the PipeWire service, and there could be further customization like ensuring that the PipeWire daemon runs and eventually restarting it on crash or that a unique instance of PipeWire is started per user.

But, I believe that the really nice thing of this design is that the usage of this "daemon" is not limited to PipeWire babysitting, but could be used for any other "user target" daemons designed to be run by systemd.

However, the usefulness of this daemon supervisor is way over its (right now unique) feature of (e)logind integration, as it can be used by various services, and for turning on well behaved daemons various applications and even scripts.

For example, the Laravel Framework, a well known MVC Framework made on PHP, needs to run a background program (of course written on PHP) to execute various off-line tasks. This "daemon" is a nice solution for having even a background service written on PHP too.

Last edited by ZhaoLin1457; 03-02-2021 at 04:30 AM.
 
Old 03-02-2021, 05:52 AM   #2
walecha
Member
 
Registered: Jan 2010
Location: Malang, +62
Distribution: slackware
Posts: 174

Rep: Reputation: 42
Nice. Will testing it.

Quote:
Originally Posted by ZhaoLin1457 View Post
But, I believe that the really nice thing of this design is that the usage of this "daemon" is not limited to PipeWire babysitting, but could be used for any other "user target" daemons designed to be run by systemd.
Yes. I'm also using daemon to start dnscrypt-proxy on user login (and stop it on logout) so that user can run and using it's own dns service instead ISP dns.
 
Old 03-02-2021, 06:32 AM   #3
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,500

Rep: Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308
Quote:
Originally Posted by walecha View Post
Yes. I'm also using daemon to start dnscrypt-proxy on user login (and stop it on logout) so that user can run and using it's own dns service instead ISP dns.
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?

https://github.com/raforg/daemon/com...5c46c06056a176

You may want to say that you intend to use it for this scope, and that's OK, because I am quite sure that Zhao Lin struggled to convince this developer to add this elogind integration for our general interest, as Slackware users.

@ZhaoLin1457

It works! Congratulations for getting your design made!

This little daemon supervisor has an impressive features set, considering it ships in a spartan package which contains: a 239KB binary, a man page and a config file.

However, regarding the testing of this daemon supervisor, I propose the bellow XDG desktop file, which I think is more appropriate to the topics of discussion I seen you had with @raforg on that feature request.
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/bin/sh -c 'mkdir -p $HOME/.daemon; daemon -frB -P $HOME/.daemon -n pipewire /usr/bin/pipewire'
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
So, we set there: a unique instance of PipeWire per user, foreground execution of daemon supervisor, with automatic respawn of client program and binding to user session - quitting on logout.

Last edited by LuckyCyborg; 03-02-2021 at 06:53 AM.
 
1 members found this post helpful.
Old 03-02-2021, 06:53 AM   #4
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,057

Rep: Reputation: Disabled
Thanks for this ZhaoLin1457.

Just a question: why not put the .desktop file in ~/.config/autostart rather than /etc/xdg/autostart/, i.e. starting the daemon only when starting a graphical session for users who want it? That's what we do in Slint for the Orca screen reader as only blind users need it. In ~/.config/autostart/startorca.desktop we have this line:
Hidden=true
Just replacing it with:
Hidden=false
starts Orca for users who need it when opening a graphical session.

As an aside, we use PulseAudio (we are based on Slackware 14.2) but start it neither system wide nor when opening a graphical session, but only on demand by client applications, in the console as in graphical environments. Is something like that meaningful for pipewire?

PS and OT: When I was school boy I had a pal who was a daughter of 趙無極 and has been invited in his house in Paris.

Last edited by Didier Spaier; 03-02-2021 at 06:58 AM.
 
Old 03-02-2021, 06:58 AM   #5
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,500

Rep: Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308
Quote:
Originally Posted by Didier Spaier View Post
Thanks for this ZhaoLin.

Just a question: why not put the .desktop file in ~/.config/autostart rather than /etc/xdg/autostart/, i.e. starting the daemon only when starting a graphical session for users who want it? That's what we do in Slint for the Orca screen reader as only blind users need it. In ~/.config/autostart/startorca.desktop we have this line:
Hidden=true
Just replacing it with:
Hidden=false
starts Orca for users who need it when opening a graphical session.

As an aside, we use PulseAudio (we are based on Slackware 14.2) but start it neither system wide nor when opening a graphical session, but only on demand by client applications, in the console as in graphical environments. Is something like that meaningful for pipewire?
Well, on using /etc/xdg/autostart/ I believe that has the advantage of a single desktop file on the whole system, no mater how many users are setup. So, it can be shipped by the PipeWire package.

In other hand, I believe that that PipeWire makes no sense to be started in demand, and even that it wasn't designed for this.

After all, it is audio/video server, and it is a quite busy server, considering that it does various things.

For example it is used by Wayland/Plasma5 to show its taskbar tooltips or for remote desktop.

I for one, I use since long time the PipeWire daemon started via global XDG autostart and using elogind kill mode to stop it.

Now, looks like I have to reconfigure my boxes, as this daemon supervisor does a fine job of handling the PipeWire server.

Last edited by LuckyCyborg; 03-02-2021 at 07:03 AM.
 
Old 03-02-2021, 07:11 AM   #6
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,057

Rep: Reputation: Disabled
Quote:
Originally Posted by LuckyCyborg View Post
Well, on using /etc/xdg/autostart/ I believe that has the advantage of a single desktop file on the whole system, no mater how many users are setup. So, it can be shipped by the PipeWire package.
Still shipping it in the package it would possible to putting it in /etc/skel or in both dirs, then all users created after this package's installation could get it in their ~. That's /etc/skel's purpose.

Last edited by Didier Spaier; 03-02-2021 at 07:15 AM. Reason: Re worded.
 
Old 03-02-2021, 07:27 AM   #7
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,500

Rep: Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308
Quote:
Originally Posted by Didier Spaier View Post
Still shipping it in the package it would possible to putting it in /etc/skel or in both dirs, then all users created after this package's installation could get it in their ~. That's /etc/skel's purpose.
Again, I do not believe that PipeWire is supposed, expected and/or designed to be "optional" and started on demand like PulseAudio.

So, what sense makes to setup the PipeWire startup on user side?

From what I understand, it is supposed that a Pipewire daemon instance (or several if we add also the audio compat-support for PA and JACK) to run unconditionally since user logins until user logouts.

At least, this way it is used on the systemd-based distributions for what PipeWire was designed.

So, the future has no place for pure-ALSAcians and your ORCA should learn to talk with PipeWire.

Anyway, the topic of this thread looks being the testing of a general purpose daemon supervisor with systemd-logind/elogind integration and NOT the fine art of PipeWire and its ethical issues.

So, let's test this daemon supervisor and to report back!

Last edited by LuckyCyborg; 03-02-2021 at 07:52 AM.
 
Old 03-02-2021, 08:08 AM   #8
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,057

Rep: Reputation: Disabled
Quote:
Originally Posted by LuckyCyborg View Post
So, the future has no place for pure-ALSAcians.
Slint is not pure ALSA. But users can set and use their system as they see fit, and this includes which applications to run

Quote:
Your ORCA should learn to talk with PipeWire.
Orcas doesn't talk to any audio application. It sends text to be spoken and meta data to speech-dispatcher, which sends that to a synthesizer then sends the audio files output of the synthesizer to an application to choose from alsa, oss, pulse, oss, nas or libao. If libao has been chosen it can be set to use aisa, esd, pulse or oss as audio driver.

If you contribute an audio plugin for pipewire to speech-dispatcher, I am pretty sure that Samuel will be happy to include it in speech-dispatcher alongside the existing ones after having reviewd it.

Last edited by Didier Spaier; 03-02-2021 at 09:35 AM.
 
Old 03-02-2021, 09:43 AM   #9
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,022

Original Poster
Rep: Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208
Quote:
Originally Posted by LuckyCyborg View Post
However, regarding the testing of this daemon supervisor, I propose the bellow XDG desktop file, which I think is more appropriate to the topics of discussion I seen you had with @raforg on that feature request.
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/bin/sh -c 'mkdir -p $HOME/.daemon; daemon -frB -P $HOME/.daemon -n pipewire /usr/bin/pipewire'
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
So, we set there: a unique instance of PipeWire per user, foreground execution of daemon supervisor, with automatic respawn of client program and binding to user session - quitting on logout.
I have an even better idea which works similarly with yours and along with what I discussed with the daemon's developer, if we update the code to latest git commits:
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
And a config file /etc/daemon.conf.d/pipewire.conf

with the following content:
Code:
pipewire bind,respawn,pidfiles=~/.daemon
Here I should make the note that for moment we need a patch, otherwise the new tilde expansion (for the user home directory) would not work for root unless will be enabled the "idiot" mode.

Our friendly developer is still a Debianite who does no imagine that there's such thing like a root account.
Code:
diff -urN daemon-20210303_92768de.orig/daemon.c daemon-20210303_92768de/daemon.c
--- daemon-20210303_92768de.orig/daemon.c	2021-03-02 16:41:47.000000000 +0200
+++ daemon-20210303_92768de/daemon.c	2021-03-02 17:01:40.022784620 +0200
@@ -1312,6 +1312,51 @@
 	expanding = mem_strdup(input);
 	len = strlen(expanding);
 
+	/* Replace home directory notation: ~ or ~username */
+
+	for (i = 0; i < len; ++i)
+	{
+		if (expanding[i] == '~' && (i == 0 || is_space(expanding[i - 1]) || expanding[i - 1] == ':' || expanding[i - 1] == '='))
+		{
+			size_t usernamelen = strcspn(expanding + i + 1, ":/ \t");
+			struct passwd *pwd;
+			
+			if (usernamelen)
+			{
+				char *username = null;
+
+				if (asprintf(&username, "%.*s", (int)usernamelen, expanding + i + 1) == -1)
+					fatalsys("failed to expand");
+
+				pwd = getpwnam(username);
+				free(username);
+			}
+			else
+			{
+				uid_t uid = g.uid ? g.uid : getuid();
+
+				pwd = getpwuid(uid);
+			}
+
+			if (pwd)
+			{
+				size_t homedirlen;
+
+				if (asprintf(&expanded, "%.*s%s%s", i, expanding, pwd->pw_dir, expanding + i + 1 + usernamelen) == -1)
+					fatalsys("failed to expand");
+
+				free(expanding);
+				expanding = expanded;
+				expanded = null;
+
+				homedirlen = strlen(pwd->pw_dir);
+				len -= 1 + usernamelen;
+				len += homedirlen;
+				i += homedirlen -  1;
+			}
+		}
+	}
+
 	/* But not for root, unless --idiot */
 
 	if (!g.idiot && (getuid() == 0 || geteuid() == 0))
@@ -1359,51 +1404,6 @@
 		}
 	}
 
-	/* Replace home directory notation: ~ or ~username */
-
-	for (i = 0; i < len; ++i)
-	{
-		if (expanding[i] == '~' && (i == 0 || is_space(expanding[i - 1]) || expanding[i - 1] == ':' || expanding[i - 1] == '='))
-		{
-			size_t usernamelen = strcspn(expanding + i + 1, ":/ \t");
-			struct passwd *pwd;
-			
-			if (usernamelen)
-			{
-				char *username = null;
-
-				if (asprintf(&username, "%.*s", (int)usernamelen, expanding + i + 1) == -1)
-					fatalsys("failed to expand");
-
-				pwd = getpwnam(username);
-				free(username);
-			}
-			else
-			{
-				uid_t uid = g.uid ? g.uid : getuid();
-
-				pwd = getpwuid(uid);
-			}
-
-			if (pwd)
-			{
-				size_t homedirlen;
-
-				if (asprintf(&expanded, "%.*s%s%s", i, expanding, pwd->pw_dir, expanding + i + 1 + usernamelen) == -1)
-					fatalsys("failed to expand");
-
-				free(expanding);
-				expanding = expanded;
-				expanded = null;
-
-				homedirlen = strlen(pwd->pw_dir);
-				len -= 1 + usernamelen;
-				len += homedirlen;
-				i += homedirlen -  1;
-			}
-		}
-	}
-
 	return expanding;
 }
@Didier Spaier, @LuckyCyborg

please let's do not derail this thread to PipeWire itself and the philosophy behind it.

Right now we struggle to make it to work properly, after all...

But I believe that this daemon is of general interest for any "user target" daemons we will want to run.

Last edited by ZhaoLin1457; 03-02-2021 at 10:35 AM.
 
2 members found this post helpful.
Old 03-02-2021, 10:52 AM   #10
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,500

Rep: Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308
@ZhaoLin1457

I have rebuilt this daemon supervisor with the latest GIT commits and applying also your patch.

I can confirm you that the duet daemon/pipewire works fine with the configuration you given.

BTW, this custom daemon configuration file is a nice thing, as it could be included in the interested package, e.g. PipeWire.

So? It is almost ready, right?

Looking at your discussion with @raforg, the requested feature(s) was accomplished.

Last edited by LuckyCyborg; 03-02-2021 at 10:55 AM.
 
Old 03-02-2021, 11:57 AM   #11
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,022

Original Poster
Rep: Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208Reputation: 1208
Quote:
Originally Posted by LuckyCyborg View Post
@ZhaoLin1457

I have rebuilt this daemon supervisor with the latest GIT commits and applying also your patch.

I can confirm you that the duet daemon/pipewire works fine with the configuration you given.
Thanks for testing! So far so god.

Quote:
Originally Posted by LuckyCyborg View Post
BTW, this custom daemon configuration file is a nice thing, as it could be included in the interested package, e.g. PipeWire.
Yes. It's a cool thing, which was already present on this small but powerful daemon supervisor.

Quote:
Originally Posted by LuckyCyborg View Post
So? It is almost ready, right?

Looking at your discussion with @raforg, the requested feature(s) was accomplished.
Well, looks like the both the main feature (elogind integration) and the secondary one (a small variables expansion) was implemented. However, I have no idea what other things wants the developer to add for the next release of daemon.

So, there is a probably better (temporary?) patch for our build, which is much more appropriate by @raforg original idea, as it permit for root to expand only the single tilde character, which encode its own home.

After all, I am not a daemon supervisors developer to claim what's safe and what not. But for this single tilde expansion, the code just look on the shadow library to find its own home by UID. So, I believe it is quite safe.

I hope that this change will be accepted on the daemon.
Code:
diff -urN daemon-20210303_92768de.orig/daemon.c daemon-20210303_92768de/daemon.c
--- daemon-20210303_92768de.orig/daemon.c	2021-03-02 17:16:43.000000000 +0200
+++ daemon-20210303_92768de/daemon.c	2021-03-02 19:30:59.481215928 +0200
@@ -1300,23 +1300,72 @@
 {
 	char *expanding = null;
 	char *expanded = null;
-	int i, len;
+	int i, len, minimal;
 
 	/* Check arguments */
 
 	if (!input)
 		return set_errnull(EINVAL);
 
-	/* Replace simple environment variables: $VARNAME or ${VARNAME} */
+	/* Prepare the variables. */
 
 	expanding = mem_strdup(input);
 	len = strlen(expanding);
 
-	/* But not for root, unless --idiot */
+	/* The root is allowed only for a minimal variables expansion. */
+
+	minimal = !g.idiot && (getuid() == 0 || geteuid() == 0);
+    
+	/* Replace home directory notation: ~ or ~username */
+
+	for (i = 0; i < len; ++i)
+	{
+		if (expanding[i] == '~' && (i == 0 || is_space(expanding[i - 1]) || expanding[i - 1] == ':' || expanding[i - 1] == '='))
+		{
+			size_t usernamelen = strcspn(expanding + i + 1, ":/ \t");
+			struct passwd *pwd;
+			
+			if (usernamelen == 0)
+			{   
+				uid_t uid = g.uid ? g.uid : getuid();
+
+				pwd = getpwuid(uid);
+			}
+			else if (! minimal)
+			{
+				char *username = null;
+
+				if (asprintf(&username, "%.*s", (int)usernamelen, expanding + i + 1) == -1)
+					fatalsys("failed to expand");
+
+				pwd = getpwnam(username);
+				free(username);
+			}
+
+			if (pwd)
+			{
+				size_t homedirlen;
+
+				if (asprintf(&expanded, "%.*s%s%s", i, expanding, pwd->pw_dir, expanding + i + 1 + usernamelen) == -1)
+					fatalsys("failed to expand");
+
+				free(expanding);
+				expanding = expanded;
+				expanded = null;
+
+				homedirlen = strlen(pwd->pw_dir);
+				len -= 1 + usernamelen;
+				len += homedirlen;
+				i += homedirlen -  1;
+			}
+		}
+	}
 
-	if (!g.idiot && (getuid() == 0 || geteuid() == 0))
+	if (minimal)
 		return expanding;
 
+	/* Replace simple environment variables: $VARNAME or ${VARNAME} */
+
 	for (i = 0; i < len; ++i)
 	{
 		if (expanding[i] == '$')
@@ -1359,51 +1408,6 @@
 		}
 	}
 
-	/* Replace home directory notation: ~ or ~username */
-
-	for (i = 0; i < len; ++i)
-	{
-		if (expanding[i] == '~' && (i == 0 || is_space(expanding[i - 1]) || expanding[i - 1] == ':' || expanding[i - 1] == '='))
-		{
-			size_t usernamelen = strcspn(expanding + i + 1, ":/ \t");
-			struct passwd *pwd;
-			
-			if (usernamelen)
-			{
-				char *username = null;
-
-				if (asprintf(&username, "%.*s", (int)usernamelen, expanding + i + 1) == -1)
-					fatalsys("failed to expand");
-
-				pwd = getpwnam(username);
-				free(username);
-			}
-			else
-			{
-				uid_t uid = g.uid ? g.uid : getuid();
-
-				pwd = getpwuid(uid);
-			}
-
-			if (pwd)
-			{
-				size_t homedirlen;
-
-				if (asprintf(&expanded, "%.*s%s%s", i, expanding, pwd->pw_dir, expanding + i + 1 + usernamelen) == -1)
-					fatalsys("failed to expand");
-
-				free(expanding);
-				expanding = expanded;
-				expanded = null;
-
-				homedirlen = strlen(pwd->pw_dir);
-				len -= 1 + usernamelen;
-				len += homedirlen;
-				i += homedirlen -  1;
-			}
-		}
-	}
-
 	return expanding;
 }
Apparently this single tilde, or own home expansion, looks being the main thing which we need to setup where the daemon supervisor puts its PID files per user.

Last edited by ZhaoLin1457; 03-02-2021 at 12:02 PM.
 
1 members found this post helpful.
Old 03-02-2021, 01:50 PM   #12
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,500

Rep: Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308
@ZhaoLin1457

I have maybe a stupid question: why did you preffer to setup the "foreground" option on that XDG autostart file, instead to add it also on the configuration file /etc/daemon.conf.d/pipewire.conf ?

LATER

I will respond myself to my own stupid question.

Because the foreground execution is probably appropriate only for XDG autostart.

You can start also on a console login the supervised PipeWire daemon or other "user target" daemons, with a command like bellow added on ~/.profile
Code:
/usr/bin/daemon -n pipewire /usr/bin/pipewire
This will start a single instance of PipeWire in a true daemon mode in background, no matter how many consoles you open for your user, and will stop it when you logout from the last one.

Now, I am not sure that if the PipeWire will be capable to run directly, from a console, without other configuration, as I read that it needs a DBUS session to be setup first.

Last edited by LuckyCyborg; 03-02-2021 at 02:48 PM.
 
Old 03-02-2021, 04:21 PM   #13
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,792

Rep: Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656Reputation: 6656
This may be considered derailing the thread, however, it seems discussion on how exactly pipewire should fit into the eventual 15.0 release makes sense to be discussed here. This will allow proposals for inclusion to hopefully cover what's best for Slackware and its users.

Quote:
Originally Posted by LuckyCyborg View Post
Again, I do not believe that PipeWire is supposed, expected and/or designed to be "optional" and started on demand like PulseAudio.

So, what sense makes to setup the PipeWire startup on user side?

From what I understand, it is supposed that a Pipewire daemon instance (or several if we add also the audio compat-support for PA and JACK) to run unconditionally since user logins until user logouts.
AFAIK, pipewire is not completely taking over *yet* and is not required to start and stop on user login/logout for *all* situations for the eventual 15.0 release. So, I don't know if pipewire should be forced to run on all users just yet (yes, this is good for testing, but I don't think it is good for proposing mandatory startup by using /etc/xdg/autostart/ with 15.0 unless it is required to be run for all situations).

It does seem like /etc/skel would be a good place for it or maybe tying startup to something like an /etc/rc.d/rc.pipewire script that can be made executable if users desire full/proper pipewire support, but can be left unexecutable for as long as pipewire usage is not mandatory.
 
Old 03-02-2021, 05:40 PM   #14
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,500

Rep: Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308Reputation: 3308
Quote:
Originally Posted by bassmadrigal View Post
This may be considered derailing the thread, however, it seems discussion on how exactly pipewire should fit into the eventual 15.0 release makes sense to be discussed here. This will allow proposals for inclusion to hopefully cover what's best for Slackware and its users.
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.

Quote:
Originally Posted by bassmadrigal View Post
AFAIK, pipewire is not completely taking over *yet* and is not required to start and stop on user login/logout for *all* situations for the eventual 15.0 release. So, I don't know if pipewire should be forced to run on all users just yet (yes, this is good for testing, but I don't think it is good for proposing mandatory startup by using /etc/xdg/autostart/ with 15.0 unless it is required to be run for all situations).

It does seem like /etc/skel would be a good place for it or maybe tying startup to something like an /etc/rc.d/rc.pipewire script that can be made executable if users desire full/proper pipewire support, but can be left unexecutable for as long as pipewire usage is not mandatory.
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.

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.

Long story short, if you ask me the best way to handle this PipeWire startup, probably is to have a sample file on /etc/xdg/autostart/pipewire.desktop-sample to make its startup "optional" more or less.

Now let's return back to this daemon supervisor and let's see for what's worth. It is capable to supervise the "user target" daemons like a boss, or not? That's the question!

Last edited by LuckyCyborg; 03-02-2021 at 06:01 PM.
 
Old 03-02-2021, 06:10 PM   #15
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-15.0
Posts: 11,057

Rep: Reputation: Disabled
Quote:
Originally Posted by LuckyCyborg View Post
Long story short, if you ask me the best way to handle this PipeWire startup, probably is to have a sample file on /etc/xdg/autostart/pipewire.desktop-sample to make its startup "optional" more or less.
No need for that. Just include in /etc/xdg/autostart/pipewire.desktop a Hidden key with either Hidden=true of Hidden=false as mentioned in the Desktop Entry Specification.

Last edited by Didier Spaier; 03-03-2021 at 01:46 AM.
 
1 members found this post helpful.
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Plasma 5.20 Beta? It is rock solid, excluding the taskbar thumbnails on Wayland - or rather because Pipewire needs "per user" init scripts LuckyCyborg Slackware 3 09-21-2020 02:50 PM
policykit-1 : Depends: default-logind or logind djk44883 Debian 8 05-03-2020 08:13 AM
LXer: Improved multimedia support with Pipewire in Fedora 27 LXer Syndicated Linux News 0 09-20-2017 02:54 PM
Keeping daemon running (Daemontools, Supervisor, Upstart, Runit, Systemd, Circus, God, etc ) NotionCommotion Linux - Newbie 4 06-09-2017 12:16 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 03:39 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration