Not entirely sure if this actually is a bug, but my dwmblocks service often doesn't seem to use my PATH.

Dwmblocks is actually a script of scripts, its sole purpose is to manage which scripts are displayed in the status bar, how often they should be updated, etc. So it relies on the scripts being in the PATH.

However, despite the directory I've placed them in being in my PATH*, the dwmblocks-log believes it isn't, spitting errors about the commands not being found (the same output as would occur if you entered a random string into the terminal).

I initially thought it could have been a case of the service being started before PATH was fully defined, but I define PATH in ~/.66/conf/svscan@ magicalsenpai/svscan@ path meaning it's defined earlier than the services being started, due to Obarun's .xinitrc

Btw, I say "often" in the first sentence, since I was actually able to find a work around not too long ago. Though I've forgotten what exactly it was I did, so I'm not able to repeat that.


* echo $PATH 
/usr/bin::/bin::/usr/local/bin::/opt/::/usr/share/man::/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/home/magicalsenpai/.local/bin:/share/cargo/bin:/home/magicalsenpai/.local/bin/statusbar:/home/magicalsenpai/.local/share/cargo/bin
The section of interest above is .local/bin/statusbar, fyi
Maybe move it to a user tree that is not set as Enabled and use .zlogin 66-all -t treename up to start the service after the path has been exported.
I am thinking now that the path can somehow be set in the environment of the service, but how exactly I don't know. The other thing is setting the path for the user session can be a one-shot service where your service depends on before it starts.

Then, this may create the need for an additional tool in 66-enable -td (time delay) or use 66-tree -S to start one tree after the other.
Sorry for getting backing earlier.
Also, I misspoke originally in the title, it's not an issue with the tree itself (I believe).
fungal_net wroteMaybe move it to a user tree that is not set as Enabled and use .zlogin 66-all -t treename up to start the service after the path has been exported.
But isn't this mostly already done in ~/.xinitrc?
See here: 
# !/usr/bin/bash

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

list=( $(ls -1 /home/magicalsenpai/.66/conf/svscan@ magicalsenpai) )
for i in ${list[@ ]};do
    var=$(</home/magicalsenpai/.66/conf/svscan@ magicalsenpai/${i})
    for j in ${var[@ ]}; do
                export ${j}
    done
done

66-all up

# # Try consolekit
if 66-which -q ck-launch-session; then
        cmd="exec ck-launch-session $@ "
else
        cmd="exec $@ "
fi

# # Select the session to start
export $(dbus-launch)
/home/magicalsenpai/.config/feh/fehbg &
${cmd} dwm
All services are brought up after the path is set in the 2nd for loop.

Regardless, I manually tried the suggestion.
First I disabled the dwmblocks service 
$ 66-disable -t graphics -S dwmblocks
Created a new tree without enabling it 
$ 66-tree -n dwmblocks_test
And enabled the dwmblocks service in the tree 
$ 66-enable -t dwmblocks_test -S dwmblocks
$ 66-all -t dwmblocks_test up   # only ran this to be sure
But it still seems unable to start.

Your other reply about creating a oneshot program did get me thinking though. Perhaps part of the issue is the service starting before X is started. So I'm making a oneshot service at the moment to start dwm and replace the last parts of the .xinitrc file, setting the dwm oneshot service as a dependency of the dwmblocks service could help it work.
something is missing on my .xinitrc default definition, modify it by 
list=( $(ls -1 /home/magicalsenpai/.66/conf/svscan@ magicalsenpai | sort) )
The sort pipe will be ensure you to load the file in the alphabetical order. Now create a new file at ~/.66/conf/svscan@ magicalsenpai/zzz_my_path (you can name it as you want as long as the name appear after svscan@ magicalsenpai) and define your path inside with 
PATH=<my_awesome_path>
now all service started will inherit of this path. If your service do not find it try to implement the importas command on the @ execute field of your service like this 
@ execute=(
   importas PATH PATH
  <my_program_to_start>
)
this above importas command should not be mandatory.
Also, you should start your fehbg daemon with a user service ;).
I don't know why you start dbus-launch but if you have the dbus-session@ <user> running, it should be not necessary.

Thanks for point me out this issue.
I tried both suggestions and neither seem to have worked, I get the same error messages in my log. Quite strange.
you should start your fehbg daemon with a user service
I did have it as a oneshot service, which works fine the first login, but subsequent logins leave me without a wallpaper since it wasn't run again :(
I don't know why you start dbus-launch but if you have the dbus-session@ <user> running, it should be not necessary.
Since dwm doesn't have a native notification server, I have to have that in my xinitrc to have them. I even rebuilt dbus with X11 support like some say to do, but that didn't seem to work.
can please you share your logs?
the log for the dwmblocks service is just this repeated 
sh: line 1: clock: command not found
sh: line 1: nettraf: command not found
Those two scripts are in my path though, so it's not a case of them not being there 
% ls .local/bin/statusbar
clock*  cpubars*  forecast*  internet*  memory*  mpdup*  music*  nettraf*  pacpackages*  torrent*  volume*
what's your frontend file declaration for your dwmblocks service?
Sorry, not sure what you mean by frontend file declaration.
But the service file is this: 
[main]
@ type = classic
@ description = "statusbar modules for dwm"
@ version = 0.0.2
@ user = ( @ I )
@ options = ( log )

[start]
@ execute=(
        importas PATH PATH
        execl-cmdline -s { dwmblocks }
)

[stop]
@ execute = ( execl-cmdline -s { pkill dwmblocks } )
Its tree is also here: 
Name         : graphics
Initialized  : yes
Enabled      : yes
Starts after : None
Current      : no
Allowed      : magicalsenpai
Symlinks     : svc->backup db->source
Contents     : /
               ├─(30147,Enabled,classic) picom-log
               ├─(30148,Enabled,classic) picom
               ├─(29766,Enabled,classic) unclutter-log
               ├─(1667,Enabled,classic) dwmblocks-log
               ├─(29793,Enabled,classic) dwmblocks
               └─(29767,Enabled,classic) unclutter
So the service is running, it just doesn't seem to like my path.
ok, we need to diagnose here.

First, we want to know if the PATH variable is correctly set on the environment.
Second, we want to know if the dwmblocks have this variable define on it own environment.

So, create a oneshot service at ~./66/service/test_env 
[main]
@ type = oneshot
@ version = 0.0.1
@ description ="environment test"
@ user = ( user )
@ options =  ( log )

[start]
@ execute = ( printenv )
enable it and start as regular user and look at its log 
% 66-inservice -o logfile test_env
PATH is correctly define?

Now, let's see if a script receive its variable. Create a simple script at ~/tmp/test_env.sh and make it executable 
# !/usr/bin/bash

echo "-----------------------------"
echo "new log"
echo "----------------------------"
printenv
Modify the @ execute field of your test_env service 
@ execute = ( /home/magicalsenpai/tmp/test_env.sh )
enable it again and see its log 
% 66-enable -f test_env
% 66-start -R test_env
% 66-inservice -o logfile test_env
and tell us.
Tried both and the path is incorrectly defined in both.

The first: 
Log file              :
USER=magicalsenpai
IPFS_PATH=/home/magicalsenpai/.config/ipfs
CCACHE_DIR=/home/magicalsenpai/.cache/ccache
WEECHAT_HOME=/home/magicalsenpai/.config/weechat
RUSTUP_HOME=/home/magicalsenpai/.local/share/rustup
CARGO_HOME=/home/magicalsenpai/.local/share/cargo
GNUPGHOME=/home/magicalsenpai/.config/gnupg
HOME=/home/magicalsenpai
LOGNAME=magicalsenpai
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin
SHELL=/usr/bin/zsh
DISPLAY=:0
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XDG_CACHE_HOME=/home/magicalsenpai/.cache
XDG_CONFIG_HOME=/home/magicalsenpai/.config
XDG_DATA_HOME=/home/magicalsenpai/.local/share
XDG_DATA_DIRS=/home/magicalsenpai/.local/share:/usr/local/share:/usr/share
XDG_SESSION_CLASS=user
The latter: 
Log file              :
GNUPGHOME=/home/magicalsenpai/.config/gnupg
PWD=/run/66/tree/1000/tests:s6-rc-update:1FoZwz/servicedirs/s6rc-oneshot-runner
LOGNAME=magicalsenpai
CCACHE_DIR=/home/magicalsenpai/.cache/ccache
HOME=/home/magicalsenpai
CARGO_HOME=/home/magicalsenpai/.local/share/cargo
XDG_CACHE_HOME=/home/magicalsenpai/.cache
XDG_SESSION_CLASS=user
IPFS_PATH=/home/magicalsenpai/.config/ipfs
RUSTUP_HOME=/home/magicalsenpai/.local/share/rustup
USER=magicalsenpai
DISPLAY=:0
SHLVL=1
XDG_RUNTIME_DIR=/run/user/1000
XDG_DATA_DIRS=/home/magicalsenpai/.local/share:/usr/local/share:/usr/share
WEECHAT_HOME=/home/magicalsenpai/.config/weechat
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
_=/usr/bin/printenv
For completeness sake, this is the output when run manually: 
SHELL=/usr/bin/zsh
FILEMANAGER=xfe
VDPAU_DRIVER=nvidia
XDG_DATA_HOME=/home/magicalsenpai/.local/share
STEAM_RUNTIME=0
XDG_CONFIG_HOME=/home/magicalsenpai/.config
LIBVA_DRIVER_NAME=vdpau
GNUPGHOME=/home/magicalsenpai/.config/gnupg
GTK_MODULES=canberra-gtk-module:xapp-gtk3-module
PWD=/home/magicalsenpai
LOGNAME=magicalsenpai
CCACHE_DIR=/home/magicalsenpai/.cache/ccache
XAUTHORITY=/home/magicalsenpai/.Xauthority
WINDOWPATH=1
MOTD_SHOWN=pam
HOME=/home/magicalsenpai
LANG=en_AU.UTF-8
CARGO_HOME=/home/magicalsenpai/.local/share/cargo
XDG_CACHE_HOME=/home/magicalsenpai/.cache
JACK_NO_AUDIO_RESERVATION=1
XDG_SESSION_CLASS=user
TERM=st-256color
IPFS_PATH=/home/magicalsenpai/.config/ipfs
RUSTUP_HOME=/home/magicalsenpai/.local/share/rustup
USER=magicalsenpai
CUDA_PATH=/opt/cuda
DISPLAY=:0
SHLVL=2
DBUS_SESSION_BUS_PID=3814
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_RUNTIME_DIR=/run/user/1000
MKLROOT=/opt/intel/mkl
QT_AUTO_SCREEN_SCALE_FACTOR=0
LC_COLLATE=C
WEECHAT_HOME=/home/magicalsenpai/.config/weechat
XDG_DATA_DIRS=/home/magicalsenpai/.local/share:/usr/local/share:/usr/share
BROWSER=brave-nightly
PATH=/usr/bin::/bin::/usr/local/bin::/opt/::/usr/share/man::/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/home/magicalsenpai/.local/bin:/share/cargo/bin:/home/magicalsenpai/.local/bin/statusbar:/home/magicalsenpai/.local/share/cargo/bin
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-RHAiHCUbYk,guid=7065742bc4b603a8c76804cc5fe15159
MAIL=/var/spool/mail/magicalsenpai
DBUS_SESSION_BUS_WINDOWID=8388609
OLDPWD=/home/magicalsenpai
XDG_SESSION_COOKIE=cyberia-1608601945.280540-844068180
WINDOWID=16777222
ZSH=/home/magicalsenpai/.config/oh-my-zsh
PAGER=less
LESS=-R
LSCOLORS=Gxfxcxdxbxegedabagacad
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
VIRTUAL_ENV_DISABLE_PROMPT=1
EDITOR=nvim
_=/usr/bin/printenv
arf, i found the trouble, my bad.
Please, let me the time to fix the things.
Please sync and update and tell us.
It should be good now.
The error is still occurring. Retried the environment tests too after rebooting and they still return the same results.
hum, look
$ cat ~/.66/service/test_path 
[main]
@ type = oneshot
@ description = "Path environment test"
@ version = 0.0.1
@ user = ( user )
@ options = ( log )

[start]
@ execute = ( 
    if { printenv }
    print_env.sh
)

% ls -la /home/test/.66/conf/svscan@ test/
svscan@ test  zzz_path     

[test@ S6 obarun]$ ls -la /home/test/.66/conf/svscan@ test/
total 16
drwxr-xr-x 2 test users 4096 Dec 23 11:32 .
drwxr-xr-x 3 test users 4096 Jun 18  2020 ..
-rw-r--r-- 1 test users  396 Dec 23 11:41 svscan@ test
-rw-r--r-- 1 test users   35 Dec 23 11:32 zzz_path
[test@ S6 obarun]$ cat /home/test/.66/conf/svscan@ test/svscan@ test 
HOME=/home/test
LOGNAME=test
USER=test
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin
SHELL=/bin/bash
DISPLAY=:0
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus
XDG_RUNTIME_DIR=/run/user/1002
XDG_CACHE_HOME=/home/test/.cache
XDG_CONFIG_HOME=/home/test/.config
XDG_DATA_HOME=/home/test/.local/share
XDG_DATA_DIRS=/home/test/.local/share:/usr/local/share:/usr/share
XDG_SESSION_CLASS=user
[test@ S6 obarun]$ cat /home/test/.66/conf/svscan@ test/zzz_path 
PATH=/home/test/.local/bin:/usr/bin

$ ls -la /home/test/.local/bin
total 12
drwxr-xr-x 2 test users 4096 Dec 23 11:37 .
drwxr-xr-x 4 test input 4096 Dec 23 11:32 ..
-rwxr-xr-x 1 test users  207 Dec 23 11:37 print_env.sh

$ cat /home/test/.local/bin/print_env.sh 
# !/bin/bash

echo "---------------------------------------------------------"
echo "environment from the script script_env.sh"
echo
printenv
echo "----------------------------------------------------------"

$ 66-intree
Name         : test
Initialized  : yes
Enabled      : no
Starts after : None
Current      : yes
Allowed      : test
Symlinks     : svc->source db->source
Contents     : test_path

[test@ S6 ~]$ sudo 66-intree -g test
Name         : test
Initialized  : yes
Enabled      : no
Starts after : None
Current      : yes
Allowed      : root
Symlinks     : svc->backup db->source
Contents     : /
               ├─(up,Enabled,oneshot) setenv@ test
               ├─(9203,Enabled,longrun) svscan@ test-log
               ├─(9224,Enabled,longrun) svscan@ test
               └─(up,Enabled,module) scandir@ test

$ 66-inservice -o logfile -p 50 test_path
Log file              : 
USER=test
HOME=/home/test
LOGNAME=test
XDG_SESSION_CLASS=user
SHELL=/bin/bash
DISPLAY=:0
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus
XDG_RUNTIME_DIR=/run/user/1002
XDG_CACHE_HOME=/home/test/.cache
XDG_CONFIG_HOME=/home/test/.config
XDG_DATA_HOME=/home/test/.local/share
XDG_DATA_DIRS=/home/test/.local/share:/usr/local/share:/usr/share
PATH=/home/test/.local/bin:/usr/bin
---------------------------------------------------------
environment from the script script_env.sh

SHELL=/bin/bash
XDG_DATA_HOME=/home/test/.local/share
XDG_CONFIG_HOME=/home/test/.config
PWD=/run/66/tree/1002/test:s6-rc-init:iPdkMb/servicedirs/s6rc-oneshot-runner
LOGNAME=test
HOME=/home/test
XDG_CACHE_HOME=/home/test/.cache
XDG_SESSION_CLASS=user
USER=test
DISPLAY=:0
SHLVL=1
XDG_RUNTIME_DIR=/run/user/1002
XDG_DATA_DIRS=/home/test/.local/share:/usr/local/share:/usr/share
PATH=/home/test/.local/bin:/usr/bin
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus
_=/usr/bin/printenv
----------------------------------------------------------
Seems to work perfectly. The trouble do not come anymore from 66. So, we need to diagnose your way to apply it.
Had a play around to try to solve the issue. It seems like (my) services use the PATH as defined in /etc/66/init.conf; changing the default PATH as defined there allows my dwmblocks service to work. Although a few of the blocks aren't being shown and the logfile was filled with a large amount of unrelated material. After editing the service file by changing 
@ execute = ( dwmblocks )
to 
@ execute = ( execl-cmdline { dwmblocks } )
and clearing the log with 
$ echo > .66/log/dwmblocks/current
It seems nothing is being written to the log now
66-boot imports the variables found at /etc/66/init.conf to the environment before launching the svscan responsible of the PID1. So, every processes(daemon/service) running below this svscan will inherit of the environment variables define at its launch time.
Now, when you start the svscan responsible of the boot-user supervision and you import the variables on its environment before launching it(this is what do the svscan@ service), each processes(daemon/service) inherit of that variables.

This is not specific of s6/66, this is how linux work with environment variables.

Powered by Obarun