As I said, once I get this done right I'll want to write a little How-To guide (possibly editing this very thread). My observations:
  1. obarun-install creates a root user with a password prompted by the script and in the last step a custom named super user with root privileges with a password prompted by the script.
  2. The root user will be assigned an ID of 0 whereas the resulting super user will be assigned an ID of 1000.
  3. The root user will be assigned two 66 trees by default, one for booting the system, one for its own services; the super user will not be assigned any tree
  4. The root user will have a working scandir by default the super user will not
Because of the behavior of # 3 one will have to create a tree for any new user created manually or even the super user created by the obarun-install script. This is an easy process and can be done from the corresponding user itself (let it be "spiderman" for this example): 
spiderman@ obarun ~ % 66-tree -ncE AwesomeTreeForSpecificDE
where -n wants to say "new tree", -c makes it the "current" tree and -E "enables" it. This is a no brainer and works flawlessly.
After this is done a service can be enabled on the created tree by issuing (taking dbus for an example): 
spiderman@ obarun ~ % 66-enable -S dbus-user
where -S will "start" that service in the same run.


OBSERVATION
When enabling a service on my new user tree the following will happen: 
66-enable: info: Enabled successfully: dbus-user
66-enable: fatal: scandir: /run/66/scandir/1000 is not running: No such file or directory
This is easy enough to understand but I'm not sure what to do now. The most intuitive thing was me trying to create the scandir for that user: 
spiderman@ obarun ~ % 66-scandir -c
This indeed created /run/66/scandir/1000/* but it will not be started anyways. When i start the scandir with the -u option, it is a foreground process and will render the console inaccessible. Also after a reboot the scandir will be destroyed and I need to create it again.


QUESTION
  1. What is the correct way to handle this?
  2. Are there more necessary steps to create a user from ground up other than creating the users tree and getting its scandir up and running?
Did you try to enable dbus-user after the creation of the directory? Maybe if it is empty it is removed, if it has dbus-user service in it it will automatically be enabled.
I don't use any user services, so I am shooting in the dark ...
Oh now that's interesting for a change. Is that with JWM?
The idea was well thought but it seems it doesn't matter if the directories exist or not, scandir is not running, so you will get notified about it: 
spiderman@ obarun ~ % 66-scandir -c
spiderman@ obarun ~ % 66-enable dbus-user
66-enable: info: Enabled successfully: dbus-user
66-enable: fatal: scandir: /run/66/scandir/1000 is not running: No such file or directory
The message is somewhat misleading because there actually is such file or directory, but it is not running indeed.
You can run the scandir with '66-scandir -u' but as mentioned, this is a foreground process.
I don't even know if scandir is really necessary or not for a user, even after correcting the docs word by word haha.
But I suppose to enable a user service it is, or otherwise the output would be different.
well, good question.
what's a scandir?
A scandir is a directory where s6-svscan program monitors services. In your system the main scandir is /run/66/scandir/0.
Try this, open htop and look for the pid 1. you will see this: 
s6-svscan -st 0 -- /run/66/scandir/0
when you start your machine the init file is launched, prepared some stuff and run the s6-svscan program at the end of file. From that point the s6-svscan program should NEVER die.

So, now when you do a 66-scandir -c command your create a scandir, that's mean that the directory itself is created more some files (take a look at /run/66/scandir/0/.s6-svscan directory). Well now the scandir is ready to accept a s6-svscan program running into it. to do so you need to start the scandir by the 66-scandir -u command. i will comes later on this command

Now when you do a 66-enable dbus-user you enable the dbus-user service on the current tree (previously created by a 66-tree command). Enabling a service doesn't mean running a service, so in this case you don't need to have an already running scandir.

if you do 66-scandir -c as normal user you will see a new directory on your system at /run/66/scandir/<uid> where uid is the uid of the user e.g /run/66/scandir/1000.
if you do the same command with an another user you will see /run/66/scandir/1001 on your system etc etc.

So, a service cannot be started (meaning supervised) without a running scandir. To start the scandir you do 66-scandir -u (meaning start the s6-svscan program and monitors the directory /run/66/scandir/1000 in your example). As said before at this point the s6-svscan should never die. So yes the s6-svscan take the control of the terminal and this is the expected behaviour. "Ok wait that's mean that i need to have constantly the terminal opened?". Depends of your needs :p. Kinding you a little.

to detach the scandir from the terminal 
$ (66-scandir -u &)&
now the scandir is running and detached from the terminal. look at the /etc/skel of the JWM templates you will see a file named .scandir containing this 
# !/usr/bin/execlineb -P
# emptyenv -p
s6-setsid -qb --
umask 022

66-scandir -v3 -cu

this little script create and run a scandir, now take a look at the .xinitrc file 
# !/usr/bin/sh

exec 1>$HOME/xinit.log
exec 2>&1

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
(.scandir &) &
sleep 01
66-all -v3 up
exec ck-launch-session jwm
When you do "startx" the .xinitrc file it's executed and so the scandir is created and started then all tree enabled will be launched.

This is one of the manner to start a scandir for an user, but you can make something like this:
create a service named /etc/66/sysadmin/service/scandir@ containing this 
[main]
@ type = longrun
@ name = @ I-scandir
@ description = "prepare and start a scandir for @ I"
@ user = ( user )

[start]
@ build = auto
@ runas = @ I
@ execute = ( 66-scandir -cu @ I)
now as root user do 66-enable scandir@ <myuser>. At this point if your tree where you add this service is enabled, everytime that your machine boot the scandir for the given user will be started.
Now you have a generic service to create a scandir for any user, simply do 66-enable scandir@ <my_another_user> etc etc

Do you see the possiblilities? i let you the time to studdy :p
What is the correct way to handle this?

Are there more necessary steps to create a user from ground up other than creating the users tree and getting its scandir up and running?
# 1 i think the above explanation answer you
# 2 nope, a tree and a scandir nothing more.
All commands and behaviour expected for root are the same for an user, no differences
Awesome Eric, thanks for the details! Wouldn't it be practical to have such a root service available in [66] for download? I could include it in my guide :)
@ Wouldn't it be practical to have such a root service available in [66] for download < yeah sure, this will comes...
I created that service file as described as I really liked the idea. After receiving an error saying that the service file was invalid I thought I'd have a refresh on the docs. By the way http://repo.obarun.org/66/ is dead. Returns 404.
From 66 docs frontend.html:
(!) Be aware that root is not automatically added. If you don't declare root in this field, you will not be able to use the service even with root privileges.
So it has to be @ user = ( root user ) or just ( root ) as user probably won't use this service anyways.

So this was easy enough to do and works as expected. Awesome! Talk about minimal configuration.
From here I can see that after booting and logging into console with that user its scandir is indeed up and running: 
spiderman@ 66 ~ % ls /run/66/scandir/1000
scandir-log/
So I want a tree for that user (obviously) and I like the concept of all of this init stuff, so I make a specific tree for a specific user group for a specific DE (because I can! hahaha): 
spiderman@ 66 ~ % 66-tree -ncE jwmsuperuser
66-tree: info: Created successfully tree: jwmsuperuser
66-tree: info: Enabled successfully tree: jwmsuperuser
66-tree: info: Set successfully jwmsuperuser as default



STILL ISSUES
Now when I want to enable any service for the corresponding user this is what happens (again dbus as an example): 
spiderman@ 66 ~ % 66-enable -S dbus-user
66-enable: info: Enabled successfully: dbus-user
s6-rc-init: fatal: unable to create live directory: No such file or directory
66-enable: warning: unable to init db of tree: jwmsuperuser
66-enable: fatal: unable to sanitize atomic services list
Wow! That came unexpected...From 66 docs enable.html:
This tool expects to find a corresponding frontend service file, a directory name (see below) or a service instance (see below), by default at /etc/66/sysadmin/service or /etc/66/service in this order of precedence for root user and $HOME/.66/service or /etc/66/service in this order of precedence for a normal user. [...] It will run a parser on the frontend service file and write the result to the directory of the given tree—see 66-tree. The service will then be available in the given tree for the next boot depending on the state of the tree.
So until I specified the -l option this should have a well working default behavior which just failed on me.
Is this a bug or should I study more?
@ So it has to be @ user = ( root user ) or just ( root ) as user probably won't use this service anyways.
sorry, my fault, i written this service quickly to answer you, but yes only root should be sufficient.

@ Still issues
Yeah, this is clearly not expected and not your fault,something wrong here. Please use -v3 on your 66-enable command and post the output

@ doc
http://web.obarun.org/software/
or on your system at /usr/share/doc/66
It's actually the start command that bails out. When just using 66-enable service the service will enable fine but apparently not get started: 
66-enable: info: Read service file of : dbus-user at: /etc/66/service/
66-enable: info: Parsing dbus-user service...
66-enable: info: service: dbus-user haven't dependencies
66-enable: info: Service parsed successfully: dbus-user
66-enable: tracing: Write service dbus-user ...
66-enable: info: write resolve file of: dbus-user
66-enable: info: Service written successfully: dbus-user
s6-rc-compile: info: parsing /tmp/jwmsuperuser:snrTo3/db/source/Master
s6-rc-compile: info: Master has type bundle
s6-rc-compile: info: parsing /tmp/jwmsuperuser:snrTo3/db/source/dbus-user
s6-rc-compile: info: dbus-user has type longrun
s6-rc-compile: info: dbus-user is a producer for dbus-user-log
s6-rc-compile: info: parsing /tmp/jwmsuperuser:snrTo3/db/source/dbus-user-log
s6-rc-compile: info: dbus-user-log has type longrun
s6-rc-compile: info: dbus-user-log is a consumer for dbus-user
s6-rc-compile: info: making bundles for pipelines
s6-rc-compile: info: resolving bundle names
s6-rc-compile: info: converting bundle array
s6-rc-compile: info: resolving service names
s6-rc-compile: info: converting service dependency array
s6-rc-compile: info: checking database correctness
s6-rc-compile: info: writing compiled information to /tmp/jwmsuperuser:snrTo3/db/jwmsuperuser
s6-rc-compile: info: writing /tmp/jwmsuperuser:snrTo3/db/jwmsuperuser/n
s6-rc-compile: info: writing /tmp/jwmsuperuser:snrTo3/db/jwmsuperuser/resolve.cdb
s6-rc-compile: info: writing /tmp/jwmsuperuser:snrTo3/db/jwmsuperuser/db
s6-rc-compile: info: writing /tmp/jwmsuperuser:snrTo3/db/jwmsuperuser/servicedirs
66-enable: info: create directory: /run/66/state/1000/jwmsuperuser/.resolve
66-enable: info: Enabled successfully: dbus-user
When issuing 66-enable -S service the errors occurs: 
...
All of the above
...
66-enable: info: sanitize atomic services list...
66-enable: info: initiate db of tree: jwmsuperuser ...
s6-rc-init: fatal: unable to create live directory: No such file or directory
66-enable: warning: unable to init db of tree: jwmsuperuser
66-enable: fatal: unable to sanitize atomic services list
this is bother me because i cannot reproduce your issue
please give me the output of the following command

ls -la /run/66
ls -la /run/66/scandir/
ls -la /run/66/scandir/0
ls -la /run/66/scandir/<uid_of_user>
ls -la /run/66/tree/0
ls -la /run/66/tree/<uid_of_user>
ls -la /run/66/state/0
ls -la /run/66/state/<uid_of_user>
Maybe this could have been caused because this was a dev tree install?
I could try again with the latest ISOs published by Jean Michel.
For debugging purposes a complete ls -laR of /run/66/** can be found here.



Update:
I downloaded Obarun_x86_64-2019-03.iso and the same happened.

Hopefully this break down may help to reproduce the behavior:
Every step I took:
  • UEFI boot the minimal ISO from USB
  • Establish a network connection
  • Update and start obarun-install
  • Go to expert options, packages lists and comment wireless_tools and wpa_supplicant and add iw (Arch flags wireless_tools as deprecated; I wouldn't believe this to affect 66, but still, that's what I did, so I'll include it)
  • Install the minimal environment to a partition scheme prepared as described in the Wiki
  • Choose not to install syslinux
  • After successful install go to expert options and launch a shell on the new installation
  • Install the intel microcode package
  • Adjust /etc/mkinitcpio.conf to reflect this blog post
  • Rebuild the initram
  • Exit out of the chroot environment and also out of the install script
  • Make a UEFI boot entry for EFISTUB boot with efibootmgr as described in the Arch wiki (Use PARTUUID for root and also add resume with PARTUUID, mount with ro instead of rw and add the intel microcode image before initramfs)
  • Reboot into the new install (Use your motherboards UEFI boot menu at startup if a different default is chosen even after creating the entry)
  • Log in as root and create the scandir service file as described in [post=3237]post # 4[/post]
  • Enable the service and log out and in to the user created by the install script
  • Create a tree for the user and enable it/make it current
  • Enable a service for the user on that tree
  • Start the service


Update:
I do one install after another, are you fiddling with this in repos?
I now experience different behavior, I cannot even enable the service anymore: 
marian@ obarun ~ % 66-enable dbus-user
66-enable: warning: unable to open : /home/marian/.66/service/: No such file or directory
66-enable: fatal: unable to parse source directory: /home/marian/.66/service/: No such file or directory
And indeed that directory does not exist and if I manually create it, enable will still fail.
root services: here
-v 3 output when enabling scandir@ marian: here
complete output of ls -laR ~/.66/: here
complete output of ls -laR /run/66: here

This also happened just like this even when not changing any options in the installer, not even host or username.
Steps are about the same:
  • Boot minimal ISO from UEFI on USB
  • get network running then run obarun-install and update it, choose minimal as desktop
  • don't change anything just install with default options and names
  • don't install bootloader
  • create the UEFI boot entry as above, reboot and log in as root to create and enable/start the scandir servce (see attached log)
  • change to user, create a tree and try to enable a service (see above)
definitely something go wrong, i'm on it, this will take a little time to solve, be patient please, you can try to pass trought your .xinitrc to create a scandir for an user,
My fault for not even trying the .xinitrc version yet. Will do so next. I understand that this takes time to debug.
ok found the trouble, the fix will be available on the next release, i'm currently pushing the change on the dev branch, the release should follow quickly.
Anyway if you do : 
$ 66-init -t <tree_name> both
you should be able to start the service even passing through the scandir service. this command should be done after the creation of the scandir and before the start of the service

for example your xinitrc can be (using your scandir service) 
# !/usr/bin/sh

exec 1>$HOME/xinit.log
exec 2>&1

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
66-init -t <tree_name> both
66-all -v3 up
exec ck-launch-session jwm
so the scandir service create the necessaries directory, the 66-init command init service from the given tree into the scandir and finally the 66-all command start all service from all enabled tree.

the next release should fix this and the 66-init phase should be not necessary as expected

Many thanks to point me out this bugs
I don't use a DM, but let's say someone does, and not using xinit, where would the same thing go? On the login shell rc, .zshrc, .bashrc ? Or in whatever autostart, but that would be specific to a DE used if multiple DEs.
@ fungalnet
with many way
you can use the same way as s6opts did with consolekit
you can start the scandir using a the down flags to prepare the scandir without running it, then you start it appending your start command in autostart field of your desktop
you can create a dbus service
you can create a special tree marked disabled (well do not enable it) containing the service to start the scandir then ask to start it through your .zshrc 66-all command
......
it's up to you, 66 was build with flexibility in mind, i believe...
Yesterday after installing lxqt, kde, jwm AND sddm I asked myself the same question and thought, there probably is a way to have a tree for each DE and enable it only when logging into that DE :D
I think from here it's all about experimenting with this kind of setups and DOCUMENTING it for others! :)
Emphasis on documentation! Because what's the point if nobody knows about it? ;)
After the service directories fix I might try some configurations with this and post back.

Thanks for the fix Eric, could you announce when it's in [obcore]?
Eric are you sure? I now tried to create the scandir by
  1. Creating a root service as described
  2. Creating a file .scandir file in /etc/skel and linking it from .xinitrc as described
  3. Running 66-scandir -cu with the user in question from another tty and let it run in foreground
All of these work equally (where # 2 is not useful if not working from X) but produce the following: 
marian@ obarun ~ % 66-tree -ncE plasma
marian@ obarun ~ % 66-init -t plasma both
66-init: info: Initialization aborted -- no classic services in[color=red]to[/color] tree: plasma
66-init: info: Initialization aborted -- no atomic services in[color=red]to[/color] tree: plasma
marian@ obarun ~ % 66-enable dbus-user                             # Note the absence of -S
66-enable: fatal: unable to parse source directory: /home/marian/.66/service/: No such file or directory
marian@ obarun ~ % 66-start dbus-user
66-start: fatal: dbus-user is not enabled
you have something wrong on your system $HOME/.66/service should exist on your system.
So build again the things from zero in this order please 
$ rm -rf $HOME/.66
$ 66-tree -cnE plasma
$ 66-enable dbus-user
$ 66-init -t plasma both
$ 66-start dbus-user
obviously your scandir need to be in up state for the init and start command

Powered by Obarun