this post coming from Fulganet is really interesting for me :
I am running 5 systems at the moment based on sysvinit, OpenRC, Runit, and S6.
I am still a student and sometimes a confused one. But S6 makes more sense than any other, in theory.
I'd like to see how they stand up in similar tasks and how manageable they are, from a user standpoint.
A sys-admin for a massive network may have different standards, and we have be trained to think what's best for sysadmins is best for us, and it does not translate well in practice. Lazy sysadmins with knowledge gaps "may" choose systemd. I doubt they use it at home.

I think if people go through Obarun and pass on the opportunity to really understand S6 they would easily jump to something else and not really know what they missed.
I'm currently working on a new version of s6opts which simplify the service supervision tree. This new version will have the advantage to earn some memory space too. worked yet on my personnal system, but i need to do some deeply test before provide it for user, you can see change on the github on dev branch if you are interested.
However, This will the last major change on s6opts because i'm working under a replacement of it written in C. It will provide a high-level UI to create a daemon (this UI will similate as PKGBUILD) and to simplify the managment of the files for a services (in other choosen).

So maybe people can tell what's is good or not good with S6? what's is the most difficult part to understand/using on S6 from the sys admin view or user view?
Well, if you have idea or request and so on, post here. Thanks
It's easy to dd / clone the full Obarun system to a new partition for testing (similar to Full system backup with dd. It will be necessary to change UUID of the cloned partition with gparted and add a new entry in a boot configuration file). Make a beta package for a new version of s6opts.

Personally, I'd like to see a system transparent as much as possible (ideally, with an option to boot the system with a pause after a service launched, so in tty2, it would be possible to check a brief description of the service, files created, and how to delete and start it manually if needed).
When cloning with dd the first thing to change would fstab.
Then the grub uuids.
Then after the first boot you may have to make new boot images (initramfs) based on the new uuid for every kernel as they retain the uuid address and it can confuse things. You have to be careful at this stage as you may not know what it is you are booting on.
For most users some gui panel listing services and daemons that they could activate and deactivate like systemd on debian, with warnings for the minimum essential and the optional ones.

My understanding is that the advantages of S6 is that it starts things up at the same level and those that check/supervise the rest are part of this process and not a following step. You can't really tell all these things in a process panel like htop or lxtask. You can't tell what has started in parallel, with a delay, what is monitored for continuous use so if for some reason it stops it would be restarted, etc.

In my experience with certain hw shutdown has been problematic. After S6 has shut everything down, it says the system will no be powered off/down and then it sticks there. In some other box I don't even get to see this message it is already off (so fast).
ray wroteIt's easy to dd / clone the full Obarun system to a new partition for testing (similar to Full system backup with dd. It will be necessary to change UUID of the cloned partition with gparted and add a new entry in a boot configuration file). Make a beta package for a new version of s6opts.

Personally, I'd like to see a system transparent as much as possible (ideally, with an option to boot the system with a pause after a service launched, so in tty2, it would be possible to check a brief description of the service, files created, and how to delete and start it manually if needed).
this sounds interesting , will test it because I am keeping Ghost image of my arch linux and Obarun made with Norton ghost on windows. My question is can I make an ISO of backup made with dd command and boot it as a live session from a USB?
@ saleem, if you make a dd-cloned partion it'll be exactly as the original one (it's just byte-by-byte copy, even UUID is the same so you have to obviously make a new UUID with gparted). It doesn't matter where a partition for the clone is made (a hard drive or USB), but its size should be equal or bigger comparing with the original. Re ISO, try it, there is no any risk playing with backup.
@ saleem,@ ray

Please, Please and again PLEASE,guys do not drift from the original theme of this topic. It will be more easier for people to found thing if we have one topics for one subject. This is why i insist under the fact to make a new topics if you question do not concern the original question.

This topic was opened to talk about S6 not Obarun in general, if you have some request/idea concerning Obarun, make a new topic with a new subject and it will be a pleasure to answer you . DO NOT MIX subject on the same topics, THANKS YOU VERY MUCH :).
Personally, I'd like to see a system transparent as much as possible (ideally, with an option to boot the system with a pause after a service launched, so in tty2, it would be possible to check a brief description of the service, files created, and how to delete and start it manually if needed).
it can be very complicated to stop the process at every service launched.
By the way you have a complete report of the boot process at /run/boot/uncaught-logs/current. Every service started at boot time make an output on this file with the name of the services. Example ( the output was made with this command cat /run/boot/uncaught-logs/current|s6-tai64nlocal)
2018-01-18 08:33:55.648616500 rofs-console started
2018-01-18 08:33:55.649825500 lvm-prepare desactived
2018-01-18 08:33:55.650139500 checkfs-dmraid desactived
2018-01-18 08:33:55.650244500 checkfs-brtfs desactived
2018-01-18 08:33:55.653642500 checkfs-fsckeck started
2018-01-18 08:33:55.855397500 /dev/sda3: clean, 824654/6406144 files, 14835686/25600000 blocks
2018-01-18 08:33:55.934077500 /dev/sda1: clean, 84/38456 files, 42329/153600 blocks
2018-01-18 08:33:55.996409500 rofs-console successfully started
for example rofs-console correspond at the file /etc/s6/rc/rofs-console. So if you want to know what the service do, simply look at the file /etc/s6/rc/rofs-console/up. When the service is started, it make the output "rofs-console started". When the service as complete his process is make the output "rofs-console successfully started". As you can see between this two output, some other service are started (or not), this is due of the paralelization.

Maybe i do not understand your request here, if it's the case, please explain deeper with some good example what you mean.
For most users some gui panel listing services and daemons that they could activate and deactivate like systemd on debian, with warnings for the minimum essential and the optional ones.
I do not see what you talking about?! 0_o. Have you a screenshot please to show me what you mean?
After S6 has shut everything down, it says the system will no be powered off/down and then it sticks there. In some other box I don't even get to see this message it is already off (so fast).
it will be very interesting for me to have a report of this :). Testing all hw is impossible for me, so if people have trouble with particular one, please tell me it.
S6 fast? you should confuse with something else :D!! Well, you can easily make a workaround about this, simply edit the file /etc/stage2.tini as it :
foreground {
	if { s6-test -x /usr/bin/mountstats }
	if -X { mountstats }
	if { s6-echo Umount NFS filesystem }
	umount -a -f -t nfs4 
}

# append this following line
foreground { sleep 10 }

if { s6-echo -- "***************************************************************************" }
if { s6-echo -- "** 
this will make a pause during ten second before shutting down the machine and let you the time to see what is written on the console.
Having the ability to make a pause at the shutdown process can be a good idea. I will see to implement a variable at s6.conf to allow pausing the process during X time.
@ eric, it's ok then with a complete report of the boot process at /run/boot/uncaught-logs/current.
eric wrote
For most users some gui panel listing services and daemons that they could activate and deactivate like systemd on debian, with warnings for the minimum essential and the optional ones.
I do not see what you talking about?! 0_o. Have you a screenshot please to show me what you mean?
This would mean I would have to boot to a debian system and screenshoot. I think I can do that.
humm, i didn't be aware about this kind of tricks. Yes really ugly and do not bring a real advantages appart a box :(. A gui can be a good idea but not on this way. I mean, you don't have e.g the description of the service, if the service is already actived you don't have the status, maybe the dependencies can be displayed, seeing the run file and editing it, and so on.
Concretly for the moment, my objectif is to implement s6 on obarun with the ability for an user to use it with a simple way (for example the creation of the service can be difficult for the moment). Operation will be split on different software like 66-enable, 66-create, 66-start, 66-status, 66-update etc (yeah 66 is the name of the s6opts replacement soft).
once it's software will be in place, it can be relatively easy to implement it with a gui. But the gui will be not my priority for the moment.

For example, the file to create a service can be something like that :
type=classic
description="foo service is used by foo soft"
name=foo
enabled=yes
log=yes
dependencies=( 'foobar' 'foostr' )
user=obarun
timeout-kill=2

run(){
# !/usr/bin/bash
/usr/bin/foo --nodaemon
}

finish(){
# !/usr/local/bin/execlineb -P
s6-rmrf /run/foo
}
like a PKGBUILD but for service , so SERVBUILD
you turn offtopic with this question, make a new post. this topics is opened to discuss about the implement of S6 on obarun, not for know how s6 works on obarun
12 days later
ok , i think i got a good base for the service creation file. This is understandable for user? simple to use and create? Any remarks, suggestion is welcomed.
--------------- File Syntax format with all available keys ------------

type = classic/bundle/longrun/oneshot
name = foo
description = "foo service"
contents = ( fooA fooB )
depends = ( fooA fooB fooD fooC )
options = ( logger nosetsid down data env )
notify = 3
user = ( root obarun )
pipeline = ( foo-pipe )
producer = ( logger foo )
consumer = ( foo fooA )


[run]
flags = ( auto line )
runas = root
timeout-finish = 10
timeout-kill = 10
timeout-up = 10
timoout-down = 10
exec = ( /usr/bin/foo -d )


[finish]
flags = ( auto line )
runas = root
timeout-finish = 10
timeout-kill = 10
timeout-up = 10
timoout-down = 10
exec = ( /usr/bin/foo -d )

[logger]
destination = /var/log/foo
flags = ( auto line )
timeout-finish = 10
timeout-kill = 10
runas = s6log
backup = 3
size = 1000000
timestamp = TAI64


-------------------- Explanation of each key ------------------------

key --- type ----
decription : Mandatory key. First key to find, if it's not the case the
process is stopped immediatly. This will allow to earn time to parse the file.
In function of the type some key are mandatories.
value : string format
classic -> classic servcie
bundle -> bundle service
longrun -> longrun service
oneshot -> oneshot service

key --- name ----
description : Mandatory key. Name of the service
value : string format

key --- description ----
description : Mandatory key. A short description of the service
value : string format

key --- contents ----
description : Mandatory key for bundle type. The declaration order
define the dependencies order.
value : must be found between (), space is the separator of each name

key --- depends ----
description : Optional key. The declaration order define the dependencies
order. Can be used for classic service too, it isn't so
difficult for the helper to verify the presence of an another classic/rc
service.
value : must be found between (), space is the separator of each name

key --- options ----
description : Optional key. Available options
value : must be found between (), space is the separator of each name
logger -> the helper will create automaticaly a logger for the service.
down -> creation of the empty file down
nosetsid -> creation of the empty file nosetsid
data -> verbatim copy of the data directory
env -> verbatim copy of the data directory

key --- notify ----
description : Optional key. Fd number. This will create the file notification-fd
value : int format

key --- user ----
description : Optional key. This indicate which user can handle the
service. We are not talking about process execution process here,
we talking about if the service can be started or not by the given user
If it not set only root can handle the service.If it set, root need to be
present as value, if not only the user define as value can handle the service
value : must be found between (), space is the separator of each name

key --- pipeline/consumer/producer ----
description : Optional key. Creation of the respective files
value : must be found between (), space is the separator of each name

[-------- section run -------- ]

Mandatory section


key --- flags ----
description : Mandatory key. The helper will create automaticaly the file
run or up (depending of the type of the service) or make a verbatim copy
of the value
value : must be found between (), only one of those can be set
auto -> automatic creation of the file run/up.
line -> verbatim copy of all the things found between ()

key --- timeout-{finish,kill,up,down} ----
description : Optional file. Creation of the respectives files. this will
also depends of the type e.g timeout-up doesn't exist on classic service.
value : int format

key --- runas ----
description : Optional key. Execute the program as user
value : string format or int (uid/gid)

key --- exec ----
description : Mandatory key. Which program to execute
value : must be found between ()
for auto flags : the resulting file run/up is :

# !/command/execlineb -P <--- trouble can be append here for the path
fdmove -c 2 1
fdmove 1 3 <---- only present if notify is set
s6-setuidgid user <---- only present if runas is set
exec -c
/usr/bin/foo -d <---- verbatim copy of the string found between ()

for line flags : verbatim copy of the string found between ()

[-------- section finish -------- ]

Optional section. if it set, this section is the same as the run section

[-------- section logger -------- ]

Optional section. If option logger is set the helper create the log
automaticaly. However, if the section is found, some key are mandatory.

key --- destination ----
description : Mandatory key. Destination directory
value : string format, must be an absolute path

key --- flags ----
description : Mandatory key. The helper will create automaticaly the file
run or make a verbatim copy of the value.
value : must be found between (), only one of those can be set
auto -> automatic creation of the file run/up.
line -> verbatim copy of all the things found between ()

key --- timeout-{finish,kill} ----
description : Optional file. Creation of the respectives files.
value : int format

key --- runas ----
description : Optional key. Execute the program as user
value : string format or int (uid/gid)

key --- backup ----
description : Optional key. number of the archived log files
value : int format

key --- size ----
description : Optional key. set the filesize for the log files.
value : int format

key --- timestamp ----
description : Optional key. line will be prepended with the value format.
value : string
TAI -> TAI64N timestamp format
ISO -> ISO 8601 timestamp format

key --- exec ----
description : Optional key if flags is set to auto. Mandatory key if flags
is set to line.
value : must be found between ()
for auto flags : the resulting file run is :

# !/command/execlineb -P <--- trouble can be append here for the path
fdmove -c 2 1
s6-setuidgid s6log <---- only present if runas is set
exec -c
s6-log n3 t s1000000 /var/log/foo

the n3 t and s1000000 will be replaced by the given value of the
respective key

for line flags : verbatim copy of the string found between ()


-------------------- Example ------------------------

<----------- Simple classic service ---------->

type=classic
name=foo
description="foo service"
options=( logger )

[run]
flags=( auto )
exec=( /usr/bin/foo -d )

<------- Complex classic service ------->

type=classic
name=foo
description="foo service with dependencies and personnal command"
options=( logger env )
depends=( fooA fooB )
user = ( obarun root )

[run]
flags=( line )
runas= 1000
exec=(
# !/bin/bash
exec 2>&1
source /etc/file.conf
/usr/bin/foo -d
)

[logger]
destination = /var/log/foo
flags=( auto )
runas=s6log
backup = 1

<---------- bundle service -------------->

type=bundle
name=foo
description="foo bundle service"
contents=( fooA fooB fooD fooC )


<--------- Simple longrun service ------------>

type=longrun
name=foo
description="foo longrun service"
options=( logger )

[run]
flags=( auto )
exec=( /usr/bin/foo -d )

<------- Complex longrun service ------------->

type=longrun
name=foo
description="foo longrun service with dependencies"
options=( logger )
depends=( fooA fooB )
producer=( logger fooA )
consumer=( fooB )
pipe=( foo-pipe )

[run]
flags=( auto )
exec=( /usr/bin/foo -d )

[finish]
flags=( line )
exec=(
# !/bin/bash
source /etc/script.file
/usr/bin/foo --finish
)

<---------- Oneshot service -------->

type=oneshot
name=foo
description="foo oneshot service"

[run]
flags=( auto )
exec=( /usr/bin/scripts.sh )
I think it is almost nice, because it is relatively simple. What is the difference to the former proposal? Isn't it primarily the syntax of the block separators, that is now ini-like instead of shell-like.

So now to my one to two points of critique:
  1. This is really a question: Can the 'exec' variable be multiline? This would be nice to support custom runscripts. The former format has the advantage that one could also utilise other interpreters <edit>and edit the whole structure of the file (skel file would need to be in skel service description)</edit>. On the other hand, run scripts should not contain too much logic.
  2. I think, lazy admins don't like long config files where they have to search for explanations. So, the latter should be at the location where you need them if they are really short. For the rest, what's wrong with a man page and a short hint to it in the file? Examples could also be supplied as separate files under, e.g., /usr/share/<something>/examples or something like that.
I think it is almost nice, because it is relatively simple. What is the difference to the former proposal? Isn't it primarily the syntax of the block separators, that is now ini-like instead of shell-like.
yes, much like ini. my first post was really just to start the discussion. Now i approach of my final file for the format and for the variable on it.well, i think it's a good base, a good starting point.
This is really a question: Can the 'exec' variable be multiline? This would be nice to support custom runscripts. The former format has the advantage that one could also utilise other interpreters <edit>and edit the whole structure of the file (skel file would need to be in skel service description)</edit>. On the other hand, run scripts should not contain too much logic.
yes, as you can see on the complex classic service the exec can be multiple lines. All the things found between the ( ) character will be a verbatim copy but the admin need to set the flags on auto if they want complex line.At this point, the shebang must be define by the admin. However, a script can be launched by this exec command, let see some other example :
----- with flags set to auto ----
valid examples :
exec=( /usr/bin/foo -d )
or 
exec=( /usr/bin/script_to_run args_of_the_scripts ) 

not valid :
exec=( /usr/bin/mkdir -p && /usr/bin/foo -d ) <----the final file will be on execlineb language, error
------- with flags set to line -----
valid examples :
exec=( # !/bin/bash
mkdir -p /run/foo
mkfifo /run/foo/fifofoo
/usr/bin/foo -d )
or
exec=( # !/usr/bin/env python
stuff in python )

not valid
exec=( mkdir -p /run/foo 
/usr/bin/foo ) <<<------- shebang not present, error
on auto mode the line with be applied on execlineb script. if the admin need to applied some code on other language, he must set the flags on line.
writting this answer give me the idea that the language environment could be define by a variable in the run section like :
[run]
flags=( auto )
shebang=( # !/bin/bash )
.....
this is can be more safely too about the path of the shebang prog... i will see.
I think, lazy admins don't like long config files where they have to search for explanations. So, the latter should be at the location where you need them if they are really short. For the rest, what's wrong with a man page and a short hint to it in the file? Examples could also be supplied as separate files under, e.g., /usr/share/<something>/examples or something like that.
sure, i had put all this thing on one file just for the forum :). the service file itself will be e.g
type=classic
name=foo
description="foo service"
options=( logger )

[run]
flags=( auto )
exec=( /usr/bin/foo -d )
very small :)
That's nice! Forgive me that I've been a lazy/busy (private) sysadmin, not reading all the explanations thoroughly. I would actually like also the [finish] and [logger] sections to be in the template. Then I'd only have to edit on configuring most services, not really create.
arff to be clear, this is the proto file for all services (like /usr/share/pacman/PKGBUILD.proto) but the final file can be more smaller depending of option you pick or not
type = 
name = 
description = ""
contents = ( )
depends = ( )
options = ( )
notify = 
user = ( )
pipeline = ( )
producer = ( )
consumer = ( )

[run]
flags = ( )
runas = 
shebang = ( )
timeout-finish = 
timeout-kill = 
timeout-up = 
timoout-down = 
exec = ( )

[finish]
flags = ( )
runas = 
shebang = ( )
timeout-finish = 
timeout-kill =
timeout-up = 
timoout-down = 
exec = ( )

[logger]
destination = 
flags = ( )
shebang = ( )
timeout-finish = 
timeout-kill = 
runas = 
backup = 
size = 
timestamp = 
if you set the variable options e.g to logger , the section logger can be not present. if you don't want finish file the finish section can be not present, and so on
a month later
I begin to share the works in C. For the moment it's only a part of the library that i create in C : https://github.com/Obarun/oblibs.
The parser for the UI service file is almost finished, i will share it as soon as it's completly free of bugs.
It can be a good idea (for people interested by the project) to folllow the build of the project from the start and it can be good for me to have criticism too :).
2 months later
The very first files for 66-* tools are pushed here : https://github.com/Obarun/66
Those files concern the parser for the service file frontend but some other is missing for the moment(not ready to share).

As usual critizism are welcomed (constructive critizism obviously)
eric wrote As usual critizism are welcomed (constructive critizism obviously)
Now that is bad!
Welcome to linux, where have you been all those centuries?
Devs on the average when you tell them this is not working they react like you are talking about their mother.
What is this new thing with constructive criticism?
Politics and linux have this in common. They both execute the messenger of constructive criticism, and still refuse to answer it.

Powered by Obarun