Apparently i’m a trusted users now :). So i copy/paste my previous bpaste file
Hi there,
Creator of Obarun and 66 here.
First at all, thanks for your interest in 66.
I saw a lot of mistakes and misunderstood about the use of 66. So, i decide to register and help you a little bit if you are agree with that.
I saw a lot of 66 parse invocation. 99.9% of the time you don’t need to call this command. Let’s take a concrete example with the fresh creation or installation of the spice-vdagentd.
I need first to provide the frontend file of the service. This frontend file can be provide at two different places. The first one is /usr/share/66/service (default can be fixed at compilation time by the --with-system-service flag) . This directory is used by upstream (meaning packager of the distribution) to install and provide services for the system. This directory is not expected to be manipulated by sysadmin/user because every changes will be overwritten at update by the packager.
The second place is /etc/66/service (can be fixed at compilation time by the --with-sysadmin-service flag). This directory is expected to be handled by sysadmin/user. This is the place to use to define your personal frontend file. 66 do not touch this directory, and the packager should not touch it.
So, in short, i install my spice-vdagentd at /etc/66/service/spice-vdagentd with this following contents
[main]
@type=classic
@description="spice-vdagentd daemon"
@version=0.0.1
@user=(root)
@notify=3
[start]
@execute=(
foreground = { mkdir -p /run/spice-vdagentd }
foreground = { chmod 0755 /run/spice-vdagentd }
/usr/sbin/spice-vdagentd -x -d
)
Let’s detail a little bit this frontend file. I saw a lot of error when you tried to run sshd. The main reason of your first fail is due of the declaration of the @notify key. When you @notify you tell at 66 to use the notification readiness feature of s6. That means that 66 will block the service until the daemon write something at the file descriptor 3 (@notify=3) in our example. As the spice-vdagentd never send something to this fd, the process hang and you need to press Ctrl + c to fail out of the hanged process.
A perfect example for that is Dbus. Dbus daemon provide the option --print-pid which tell dbus to send a character to the fd describe with the --print-pid option when its ready. So, if you do --print-pid=3 and you set @notify=3, 66 will wait for the notification of the dbus daemon at fd 3. When something is written at this fd by the dbus daemon, 66 consider dbus as ready to serve and continue to start other services depending on it if any.
So, here, you should not use the @notify field. However, you can avoid the hang process using the @timeout-kill key. For instance, using @timeout-kill=3000 tell 66 to wait for the service to be up and exit with crash exit code if the service is not up after 3 seconds (3000 milliseconds). In that way, even if you use @notify field and the service never write something to the fd, 66 will stop the process after 3000 milliseconds (meaning 3 seconds).
Well, for now our service become
[main]
@type=classic
@description="spice-vdagentd daemon"
@version=0.0.1
@user=(root)
[start]
@execute=(
foreground = { mkdir -p /run/spice-vdagentd }
foreground = { chmod 0755 /run/spice-vdagentd }
/usr/sbin/spice-vdagentd -x -d
)
I also seen mistake about @depends field syntax. I saw something like @depends=boot@system. This is will not be going to work, it should be @depends=(boot@system). Please refer to the documentation of the frontend file syntax for each field. Howerver, to clarify a little bit this specific example, you don’t need (and you should avoid it) to make a dependency to any services of the boot tree. As the boot tree is automatically started at each boot, you have the guarantee that services associated with this tree is up when you reached the runtime level.
Coming back to our example. The execline syntax of the @execute field is not correct. You don’t have any = character between foreground and {} pair. So, the frontend should be
[main]
@type=classic
@description="spice-vdagentd daemon"
@version=0.0.1
@user=(root)
[start]
@execute=(
foreground { mkdir -p /run/spice-vdagentd }
foreground { chmod 0755 /run/spice-vdagentd }
/usr/sbin/spice-vdagentd -x -d
)
It should start now. But we can improve a little bit our scripts using a tool coming from the 66-tools package (note 66 do not depends on the 66-tools package). Tools coming from 66-tools package are not mandatory, they are just tools to simplify the write of execline script and you can obviously choose to not using it. However, using execl-toc simplify the creation of the directory (it can make much more). This command allow us to be short to test and create (toc → test or create) directory in our example. With this tool the @execute field become
[main]
@type=classic
@description="spice-vdagentd daemon"
@version=0.0.1
@user=(root)
[start]
@execute=(
execl-toc -d /run/spice-vdagentd -m 0755
/usr/sbin/spice-vdagentd -x -d
)
The result will be exactly the same, execl-toc will determine if the /run/spice-vdagentd directory exist or not and create it if it doesn’t exist yet, change its mode to 0755 then execute the /usr/sbin/spice-vdagentd.
So, here we have our frontend file to be ready to be used but, what i need to do to start the service?
# 66 start spice-vdagentd
You don’t need to invocate the 66 parse command. 66 is sufficiently smart to know if the service was already parsed or not. If the service was never parsed, the call of the start command will parse it first before trying to start it.
This is also valuable for the 66 enable command. Even if the service was never parsed, you can invocate directly the 66 enable command and 66 will do what it need to do.
Now, what the difference between start and enable. The start command start the service, nothing fancy here. The enable command tell to 66 to start the service at every boot. So, you can start a service without enabling it and you can enable a service without starting it, but if you want the service to be started at every boot you must enable it.
Ok, cool but i want now to change my frontend file a little bit to use the [environment] feature which allow us to define some good environment variables for the service which can be changed latter without the need to touch the frontend file again. Let’s do it
[main]
@type=classic
@description="spice-vdagentd daemon"
@version=0.0.1
@user=(root)
[start]
@execute=(
execl-toc -d /run/spice-vdagentd -m 0755
/usr/sbin/spice-vdagentd ${Args}
)
[environment]
Args=-x -d
66 will automatically replace the ${Args} variable definition with the content of the [environment] section for the same key at start time replacing the ${Args} by -x -d.
Ok, now i want to apply the changes, how i do that? Simply use the reconfigure command like this
# 66 reconfigure spice-vdagentd
That’s all. 66 will stop (if its running) the service and free it (meaning free all ressources used by the service), parse again the service and finally start it again. As you can see you don’t need to use the 66 parse. You also don’t need to remove it first, simply reconfigure it. This command works for any kind of service.
So, we have added the [environment] section, but what’s the advantage? Let’s say you want to add some spice-vdagentd command options. If you don’t use the [environment] section you are forced to edit the frontend file and make the change. Using the [environment] section you can use the 66 configure command. Invocating this command allow us to modify the Args=-x -d opening your preferred editor. So,
# 66 configure spice-vdagentd
will open your preferred editor with the contents of the /etc/66/conf/spice-vdagentd/version/dbus file. When i’m done with the edition, i simply reload the service to tell it to reload its configuration file
# 66 reload spice-vdagentd
and voila, you have changed the command line used by the service without touching its frontend file. Note that the reload send a SIGHUP to the service process which is the traditional signal on *NIX to reload its configuration file. Some daemon do not respect that, in this case ask to restart the service like this
# 66 restart spice-vdagentd
This command will stop the service and start it again.
Well, i saw some interesting question :
How do trees differ from bundles?
Bundles are declarative file containing service to handle in one pass. When you do s6-rc -u changes <bundle> you tell to s6-rc to start any services declared onto that bundle but you don’t have the guarantee that service depending of the bundle will only started when all service declared by the bundle are correctly started. Also you cannot declare a dependency of a bundle, e.g. BundleA cannot depends on ServiceA.
Trees are also set of any kind of services, but trees guarantee you that all services declared onto the tree are started before trying to start any other trees. Also, trees can depends/requiredby on another trees. let’s say, i have treeA containing ServiceA1 and ServiceA2 and i have treeB containing ServiceB1 and ServiceB2, and TreeB depends on TreeA. When i do
# 66 tree start TreeB
ServiceA1 AND ServiceA2 will be started first then ServiceB1 AND ServiceB2 will be started.
Can a service be in more than one tree?
No, you cannot have a same service define at different tree.
Does parse modify the database? I assume there is a database?
Yes, 66 use CDB database. This file contents all the informations needed by 66 to handle the service. You can see what it contain with the resolve command
# 66 resolve spice-vdagentd
S6 is all written in C, and therefore will compile with musl or glibc
66 will also compile with musl. Proof was made on Void (thanks to mobinmob for that).
A service can be in more than one tree, but only one tree can be up.
incorrect, a same service cannot exist on different trees.
A tree is very similar to a runlevel.
correct
That statement, from the Obarun tree page, is either wrong or ambiguous. We started sshd without enabling it.
Let’s take an example. I have in the tree called e.g. security containing the sshd service and the nfs service. Well, i want the sshd service started at every boot, but i don’t want the nfs service started automatically.
To do so, i need to enable the tree security AND enable the service sshd inside the tree security. The nfs service is marked disabled. What happens at boot time? As the security tree is marked enabled, 66 will try to start every service associated to it but it ONLY deal with service marked enabled. So, in your case the sshd will be started but not the nfs service as it was not marked enabled.
In short, enabling a tree tell to 66 to start all services associated to that tree to be started but ONLY if the service itself is MARKED ENABLED. Service not enabled will be ignored by 66 at start of the trees.
why did the directory /run/sshd disappear after a reboot?
The /run directory is a TMPFS directory, this directory is expected to be empty at every boot. So, if your service need a specific directory on /run you must define it at the frontend file. Each start of the service will create the corresponding necessary directory at /run. Volatile directory are handled by tmpfiles.d on Sytemd system, but at the base the daemon should take care by itself of all compoments that its need to properly be started.
Do I really have to do enable before start ???
Absolutely not, you can start a service without enabling it and like i said before the contrary it also true, you can enable a service without start it first.
Now lets recap…
If , before it is parsed I change /etc/66/service/sshd ( the ‘frontend’) I need
66 parse sshd
66 start sshd
No, you just need to start it directly
# 66 start sshd
and 66 will parse it before starting it.
If, when sshd has already been parsed I change /etc/66/service/sshd
I need
66 remove sshd
66 parse sshd
66 start sshd
no, simply do :
# 66 reconfigure sshd
A word about the remove command. When you call this command all compoments of the services (meaning configuration file, log files, resolve file and so on) are removed from your system except the frontend file.
and if I reboot I need
66 start sshd
correct if it’s was not enabled.
If I want it to start auotomatically I need
66 enable sshd
Correct, you can make it twice this will not change anything i mean the command will not crash if it was previously enable.
Maybe the whole thing needs to be hidden or protected?
66 make assumptions about files that its handle. Manually changing file will crash your 66 eco-system. 66 command should provide all you need to repair your system without manual intervention.
how would I get out of that without a reinstall?
You should never need to reintall the things, at worse destroying service or trees and remake your service structure by 66 command. As @ProwlerGr said, you have tty12 always available as sound as the scandir is running (meaning PID 1). This should works even on virt-manager.
A came here a little late, so it’s difficult for me to answer on every questions posted. I certainly missed to answer to important question. Please do not hesitate to ask me any question regarding 66 :).
Hope this post help a little bit to understand how 66 works.
You’ve just scratched the surface of the possibilities of 66, for example we have not talked about service launched as simple user, or instantiated service…
Eric.
