LinuxQuestions.org
Review your favorite Linux distribution.
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-03-2021, 06:47 PM   #46
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

Quote:
Originally Posted by LuckyCyborg View Post
You put equal between PipeWire and this daemon.
Wow, oh wow. You reached a TON!!!

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.
 
Old 03-04-2021, 07:51 AM   #47
walecha
Member
 
Registered: Jan 2010
Location: Malang, +62
Distribution: slackware
Posts: 174

Rep: Reputation: 42
Quote:
Originally Posted by LuckyCyborg View Post
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.
 
3 members found this post helpful.
Old 03-04-2021, 08:18 AM   #48
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 781

Rep: Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895
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.
 
3 members found this post helpful.
Old 03-04-2021, 08:31 AM   #49
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,032

Original Poster
Rep: Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238
Hi,

an update for the daemon.SlackBuild here:
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) 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.
 
2 members found this post helpful.
Old 03-04-2021, 11:05 AM   #50
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,032

Original Poster
Rep: Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238Reputation: 1238
And there is the latest stable release, with (e)logind integration:

https://github.com/raforg/daemon/releases/tag/v0.8

https://github.com/raforg/daemon/rel...mon-0.8.tar.gz

Last edited by ZhaoLin1457; 03-04-2021 at 11:10 AM.
 
2 members found this post helpful.
Old 03-04-2021, 04:25 PM   #51
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by ZhaoLin1457 View Post
And there is the latest stable release, with (e)logind integration:

https://github.com/raforg/daemon/releases/tag/v0.8

https://github.com/raforg/daemon/rel...mon-0.8.tar.gz
Nice!

So, we have now a daemon supervisor with this unique feature of elogind integration...

Let's hope that now we will learn to use it with maximum efficiency.

BTW, I built and installed this final stable release and works without issues.
 
Old 03-04-2021, 04:59 PM   #52
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by bassmadrigal View Post
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 View Post
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 View Post
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 View Post
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.
 
Old 03-04-2021, 05:48 PM   #53
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
Quote:
Originally Posted by LuckyCyborg View Post
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 View Post
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 View Post
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 View Post
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 View Post
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 View Post
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 View Post
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...
 
Old 03-05-2021, 12:55 AM   #54
mumahendras3
Member
 
Registered: Feb 2018
Location: Indonesia
Distribution: Slackware-current + s6 + s6-rc + s6-linux-init (github.com/mumahendras3/sl6ckware)
Posts: 126

Rep: Reputation: Disabled
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.
 
2 members found this post helpful.
Old 03-05-2021, 01:45 AM   #55
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by mumahendras3 View Post
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.
 
Old 03-05-2021, 12:56 PM   #56
phenixia2003
Senior Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 1,052

Rep: Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008
Hello,

Quote:
Originally Posted by LuckyCyborg View Post
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

--
SeB
 
1 members found this post helpful.
Old 03-05-2021, 01:04 PM   #57
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by phenixia2003 View Post
Hello,



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:

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

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.
 
Old 03-06-2021, 03:10 AM   #58
phenixia2003
Senior Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 1,052

Rep: Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008Reputation: 1008
Hello,

Quote:
Originally Posted by LuckyCyborg View Post
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:

https://github.com/raforg/daemon/iss...ment-757298126
it's simply wrong.

--
SeB
 
Old 03-06-2021, 11:16 AM   #59
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by phenixia2003 View Post
Hello,

it's simply wrong.

--
SeB
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.
 
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 01:56 AM.

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