Running script upon module activation SYSTEMD
Running script upon module activation SYSTEMD
Been reading this:
Re: Module Creation: Best Practices (Post by brokenman #45990) by @brokenman
viewtopic.php?f=48&t=4719&p=36659#p34124 by @Bogomips
The question is, would this feature work under a APORTEUS build of @neko?
I mean, I think neko builds, use systemd and normal PORTEUS use init. Is there any way to execute an script upon module activation in systemd?
Thanks!
P.S.: By the way, I've been doing many tests under Budgie Desktop, and I think it deserves a build. I fear that in the transition to Qt, some of its appeal will be lost. For example the font rendering is crisp. Nautilus is more responsive than in GNOME itself, allows a low profile, it's simple and productive...
It's a shame now that the GNOME journey in the desert had come to an end (...).
Re: Module Creation: Best Practices (Post by brokenman #45990) by @brokenman
viewtopic.php?f=48&t=4719&p=36659#p34124 by @Bogomips
The question is, would this feature work under a APORTEUS build of @neko?
I mean, I think neko builds, use systemd and normal PORTEUS use init. Is there any way to execute an script upon module activation in systemd?
Thanks!
P.S.: By the way, I've been doing many tests under Budgie Desktop, and I think it deserves a build. I fear that in the transition to Qt, some of its appeal will be lost. For example the font rendering is crisp. Nautilus is more responsive than in GNOME itself, allows a low profile, it's simple and productive...
It's a shame now that the GNOME journey in the desert had come to an end (...).
> Does not compute_
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
- ncmprhnsbl
- DEV Team
- Posts: 3936
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
Running script upon module activation SYSTEMD
presumably you have to make a unit file that runs(or is) the script and enable it..(and save that symlink? to your module)
whether it would start upon module activation, i don't know.. i guess.. an enabled service appearing in the service dir should run..
https://wiki.archlinux.org/index.php/Sy ... process.3F
https://wiki.archlinux.org/index.php/Sy ... unit_files
whether it would start upon module activation, i don't know.. i guess.. an enabled service appearing in the service dir should run..
https://wiki.archlinux.org/index.php/Sy ... process.3F
https://wiki.archlinux.org/index.php/Sy ... unit_files
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
Running script upon module activation SYSTEMD
Thank you ncmprhnsbl
I will investigate from your links, and taking examples of /usr/lib/systemd/system in my XFCE Manjaro install
I'm trying to set some gsettings and update caches whenever a module gets activated.
I will investigate from your links, and taking examples of /usr/lib/systemd/system in my XFCE Manjaro install
I'm trying to set some gsettings and update caches whenever a module gets activated.
> Does not compute_
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
- ncmprhnsbl
- DEV Team
- Posts: 3936
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
Running script upon module activation SYSTEMD
ah. well.. you may not need to use systemd for this at all..
i don't know what aporteus' activate script looks like, presumably it doesn't include the 'xactivate' elements..
standard porteus has a separate xactivate script (look in opt)
but this is from nemesis which includes the xactivate part (updating caches and whatnot):
Code: Select all
#!/bin/sh
# activate
# Insert porteus modules into aufs
# Author: brokenman
## Source useful functions
. /usr/share/porteus/porteus-functions
. /usr/share/porteus/gtkdialog-functions
. gettext.sh
## Get pretty colors
get_colors
## Variables
SCRIPT=${0##*/}
SCRIPTPATH="$( cd "$(dirname "$0")" ; pwd -P )"
SC=$SCRIPTPATH/$SCRIPT
cleanup(){
[ -e /tmp/.activated ] && rm /tmp/.activated
[ -e /tmp/.answ ] && rm /tmp/.answ
}
trap cleanup SIGHUP SIGINT SIGTERM
usage(){
gettext "Usage:"; echo
echo "$0 module.xzm"
echo "$0 module1.xzm module2.xzm module3.xzm"
echo "$0 /folder/with_modules"
echo
gettext "To disable recursive activation of folders run activate with '-o' (one level) flag:"; echo
echo "$0 -o /folder/with_modules"
exit
}
# Exit if no argument is provided:
[ -z $1 ] && usage
# Arch specific variables:
[ "$HOSTTYPE" = x86_64 ] && lib=lib64 || lib=lib
[ `echo "$*" | grep -o "quiet"` ] && quietmode=0
# Switch to root:
if [ `whoami` != root ]; then
# Enable 'one level' activation if requested:
if [ "$1" = "-o" ]; then
farg="-maxdepth 1"
MODULE=`echo "$*" | sed -e 's/ quiet//g' -e sed 's/-o\ //'`
else
MODULE=`echo $* | sed 's/ quiet//g'`
fi
# Get full paths to the modules (needed after switching to root):
for x in $MODULE; do
if [ -d $x ]; then
for y in `find $x $farg -name "*.xzm"`; do LIST="$LIST `readlink -f $y`"; done
else
LIST="$LIST `readlink -f $x`"
fi
done
# Re-execute this script with super user privileges:
if [ "$DISPLAY" ]; then
pkexec $SC $LIST
exit
else
gettext "Please enter root's password below"; echo
#su -c "$SC $LIST"
sudo '$SC $LIST'
exit
fi
fi
# See if only 000 and 001 modules are being used. We do not need to do some
# functions if we are only in text mode.
[ `ls /mnt/live/memory/images/|grep -c "^00[0-9]"` -lt 3 ] && TXTMODE=0
# Clear old cache files if exist:
CACHES=/mnt/live/tmp/caches
[ -d $CACHES ] && rm -r $CACHES
mkdir $CACHES
## Insert module(s) to /union.
# Enable 'one level' activation if requested:
if [ "$1" = "-o" ]; then
farg="-maxdepth 1"
MODULE=`echo "$*" | sed -e 's/ quiet//g' -e sed 's/-o\ //'`
else
MODULE=`echo $* | sed 's/ quiet//g'`
fi
xactivate(){
export BASE=`basename $1`
# If the module is already activated, suggest deactivation:
if cat /proc/mounts | cut -d" " -f2 | grep -q "/mnt/live/memory/images/$BASE"; then
gtk_yesno "`gettext "Module is already activated."`" "`gettext "Would you like to deactivate it?"`" | gtkdialog -s -c > /tmp/.answ
if [ `grep -o Yes /tmp/.answ` ]; then
actitle=Deactivation
/usr/local/bin/aufs-remove $BASE
err=$?
if [ $err -ne 0 ]; then
xreport+=( "FAILED: ${BASE##*/} Code:$err" )
else
xreport+=( "SUCCESS: ${BASE##*/}" )
fi
return 0
else
return 0
fi
else
actitle=Activation
fi
# 'Stale NFS' workaround:
cd /usr/share/applications
# Insert the module to live filesystem:
/usr/local/bin/aufs-insert $1
err=$?
## Collect the results into an array and show one final report at the end.
## Error codes
# 1 Perhaps module did not have .xzm suffix
# 2 Not in live mode
# 3 Not a valid module
# 4 Cannot read module data. Corrupt?
# 5 Can not insert module into union
if [ $err -ne 0 ]; then
xreport+=( "FAILED: ${BASE##*/} Code:$err" )
else
xreport+=( "SUCCESS: ${BASE##*/}" )
fi
}
# If we are in GUI then use 'xactivate' as a helper:
if [ "$DISPLAY" ] && [ `awk -F= '/^Popup/{print$NF}' /etc/porteus.d/modules` = "yes" ] && [ -z "$quietmode" ]; then
for x in $MODULE; do
if [ -d $x ]; then
for y in `find $x $farg -name "*.xzm"`; do xactivate `readlink -f $y`; done
else
xactivate `readlink -f $x`
fi
done
# Give final report
printf '%s\n' "${xreport[@]}" > /tmp/.activated
# Write error codes to report file
echo "" >> /tmp/.activated
cat >> /tmp/.activated << EOF
##### Error codes
1 Perhaps module did not have .xzm suffix
2 Not in live mode
3 Not a valid module
4 Cannot read module data. Corrupt?
5 Can not insert module into union
EOF
gtk_message_file "$actitle report." "/tmp/.activated" 450
rm /tmp/.activated
else
for x in $MODULE; do
if [ -d $x ]; then
for y in `find $x $farg -name "*.xzm"`; do $SCRIPTPATH/aufs-insert `readlink -f $y`; done
else
$SCRIPTPATH/aufs-insert `readlink -f $x`
fi
done
fi
# Rebuild the system configuration cache:
if [ -e $CACHES/ldconfig ]; then
#echo "Updating shared library links: /sbin/ldconfig"
/sbin/ldconfig
else
exit 0
fi
if [ -e $CACHES/mime ]; then
#echo "Updating MIME database: /usr/bin/update-mime-database /usr/share/mime"
/usr/bin/update-mime-database /usr/share/mime > /dev/null 2>&1
fi
# Only run these if we are NOT in txtmode
if [ -z $TXTMODE ]; then
for x in `cat $CACHES/icons 2>/dev/null`; do
echo "Updating icon-theme.cache: /usr/bin/gtk-update-icon-cache -t -f $x"
/usr/bin/gtk-update-icon-cache -t -f $x > /dev/null 2>&1
done
if [ -e $CACHES/fonts ]; then
echo "Updating X font indexes: /usr/bin/fc-cache -f"
/usr/bin/fc-cache -f
fi
if [ -e $CACHES/schemas ]; then
echo "Updating glib schemas: /usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas"
/usr/bin/glib-compile-schemas /usr/share/glib-2.0/schemas
fi
if [ -e $CACHES/gio ]; then
echo "Updating GIO cache: /usr/bin/gio-querymodules /usr/$lib/gio/modules"
/usr/bin/gio-querymodules /usr/$lib/gio/modules
fi
if [ -e $CACHES/immodules ]; then
echo "Updating GTK immodules: /usr/bin/update-gtk-immodules"
/usr/bin/update-gtk-immodules
fi
fi
if [ -e $CACHES/certs ]; then
#echo "Updating certificates in /etc/ssl/certs: /usr/sbin/update-ca-certificates --fresh"
/usr/sbin/update-ca-certificates --fresh >/dev/null 2>&1
fi
# Multilib support for x86_64 arch:
if [ -z $TXTMODE ]; then
if [ $lib = lib64 ]; then
if [ -e $CACHES/pixbuf ]; then
echo "Updating GDK pixbuf loaders: /usr/bin/update-gdk-pixbuf-loaders"
/usr/bin/update-gdk-pixbuf-loaders
fi
if [ -e $CACHES/pango ]; then
echo "Updating Pango querymodules: /usr/bin/update-pango-querymodules"
/usr/bin/update-pango-querymodules
fi
fi
fi
# Start services which may be provided by modules:
for SCRIPT in `cat /mnt/live/tmp/caches/services 2>/dev/null`; do $SCRIPT start; done
# Run any scripts required on activation of a module
for SCRIPT in $MODULE; do
MYMOD=${MODULE##*/}
if [ -x /etc/activate/$MYMOD ]; then
bold "Executing /etc/activate/$MYMOD"
sh /etc/activate/$MYMOD start
fi
done
# Update desktop menu:
if [ -z $TXTMODE ]; then
[ -e $CACHES/desktop-install ] && /usr/local/bin/update-menu install 2>/dev/null
[ -e $CACHES/desktop-uninstall ] && /usr/local/bin/update-menu uninstall 2>/dev/null # In case when we are deactivating through activation :)
fi
cleanup
sleep 1
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44
Running script upon module activation SYSTEMD
Much appreciated, ncmprhnsbl
Will try in the next days and report how it goes.
Will try in the next days and report how it goes.
> Does not compute_
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Running script upon module activation SYSTEMD
I added an element some time ago that executes scripts on activation. Just place your script in /etc/activate inside the module. It will automatically receive the start argument in case it is a service.
Code: Select all
# Run any scripts required on activation of a module
for SCRIPT in $MODULE; do
MYMOD=${MODULE##*/}
if [ -x /etc/activate/$MYMOD ]; then
bold "Executing /etc/activate/$MYMOD"
sh /etc/activate/$MYMOD start
fi
done
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
Running script upon module activation SYSTEMD
Thank you, brokenmanbrokenman wrote: ↑21 Oct 2017, 21:42I added an element some time ago that executes scripts on activation. Just place your script in /etc/activate inside the module. It will automatically receive the start argument in case it is a service.
Code: Select all
# Run any scripts required on activation of a module for SCRIPT in $MODULE; do MYMOD=${MODULE##*/} if [ -x /etc/activate/$MYMOD ]; then bold "Executing /etc/activate/$MYMOD" sh /etc/activate/$MYMOD start fi done
In addition to portability, PORTEUS is a rock-solid solution. This is mainly because the packages included in the 'base' system are very stable and are very well assembled, providing a very robust architecture in the form of overlayed filesystem. From there a hybrid system arises, in which it is possible to maintain an environment as predictable as is necessary, allowing the adition of new features by simply activating a new module.
However, when a new module gets activated, there is a danger of overlapping a layer, either obsolete with known vulnerabilities, or untested that introduces new ones ('promiscuous mode').
For example, yesterday I realized that the module I had created for Gnome-mpv included version 0.26 of mpv when the system already had 0.27.
This is the other reason why I am interested in the concept of executing a script at activation stage, to control that a series of essential packages (call it supermodules or superpackages) are not supplanted by incorrect versions. And I'm not talking about mpv, of course.
Now that similar modular packaging architectures (flatpack, snap, appimages, etc.) flourish, it might be tempting to offer the possibility of transforming these packages into the PORTEUS ecosystem, just as it does with rpm and deb, for example. In these cases, the package would already incorporate all its dependencies (with the advantages and disadvantages outlined above).
Has the DEV TEAM considered adopting any method to allow the use of these packages? If so, is there any way to do it in a 'controlled' way? I'm thinking of a script that controls a certain list of 'core' packages, until a stable version arrives, or incorporate some sandboxing, that would allow to preserve those superpackages, for example, if they were executed from the 'base' folder. Also, another solution would be asking the user at inserting time, which priority that package (not the whole module) should be given (maybe it's already done and I'm not aware).
I am not a programmer, but I have been using computers and operating systems for 35 years now, and I more or less understand the concept of UnionFS and this is one of the sites where I learn the more, and that's why I would like to know your opinion, or which would be the best practice to update porteus in its itinerant incarnation.
Sorry for transforming a simple question into a general discussion brainstorming... Feel free to move the post, or tell me where to put it.
Thank you very much for sharing your knowledge and keep up your great work.
> Does not compute_
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Running script upon module activation SYSTEMD
We have a similar concept with 'bundles'. They are simply modules that contain all dependencies for a given desktop environment. They still suffer the same disadvantages as above but the advantage is an app that works OOTB.Has the DEV TEAM considered adopting any method to allow the use of these packages?
Our package manager (USM) handles dependencies more readily. It will check if a running system needs a dependency or already has it installed. At the end it will create either a bundle or individual modules in the output directory that contain only the dependencies required for the given system.
Here we enter the point at which we must decide if we are creating a system for semi-advanced users or beginners. Most beginners would have no clue what package requires what priority. The package manager gives users the choice of which package they prefer for a required library and some users have reported even this is a little intimidating.Also, another solution would be asking the user at inserting time, which priority that package (not the whole module) should be given (maybe it's already done and I'm not aware).
After trying many options I decided to settle on the package manager that arranges dependencies for the system that it is on, along with the option of bundles for people that have no idea what to do. Hand in hand I think they offer a rounded solution.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
Running script upon module activation SYSTEMD
Going around this topic, so @François and I can get Arena Chess module properly assembled.
Because Arena Chess, uses his own fonts to render the pieces, and to use figurine notation, I need to update font cache (fc-cache -fv) before program launch.
This is bad:
This is how it should look:
I've tried the @ncmprhnsbl xactivate approach, but then...
(/usr/bin/xactivate: line 164: /usr/bin/aufs-insert: file or directory doesn't exists)
Any thoughts?
(I'd like to solve this both in NEMESIS -OpenRC- and PORTEUS -SysV-).
Thanks.
Because Arena Chess, uses his own fonts to render the pieces, and to use figurine notation, I need to update font cache (fc-cache -fv) before program launch.
This is bad:
This is how it should look:
I've tried the @ncmprhnsbl xactivate approach, but then...
Code: Select all
$ xactivate 014-arenalinux_full_64bit_11.xzm
/usr/bin/xactivate: línea 164: /usr/bin/aufs-insert: No existe el fichero o el directorio
Any thoughts?
(I'd like to solve this both in NEMESIS -OpenRC- and PORTEUS -SysV-).
Thanks.
> Does not compute_
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
https://forum.porteus.org/viewtopic.php?p=94310#p94310
https://forum.porteus.org/viewtopic.php?p=84002#p84002
https://forum.porteus.org/viewtopic.php?p=77174#p77174
https://forum.porteus.org/viewtopic.php?f=39&t=8584
- ncmprhnsbl
- DEV Team
- Posts: 3936
- Joined: 20 Mar 2012, 03:42
- Distribution: v5.0-64bit
- Location: australia
- Contact:
Running script upon module activation SYSTEMD
what about: (for porteus at least)
ie: script: <your module>/etc/activate/ufontcache.sh (chmod +x it)
Code: Select all
#!/bin/bash
/usr/bin/fc-cache -f
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44