@ eric I posted here because really, when I wrote this offline, I realized while writing/investigating that this was not going to be a discussion at all. Hence I just wanted to emphasize the typo.

Here's a bug for you though:
You have another typo in the nginx service frontend file which makes it error out: 
--- /etc/66/service/nginx        2020-01-09 03:44:42.000000000 +0100
+++ /etc/66/service/nginx.fix    2020-01-24 13:11:11.426414855 +0100
@ @ -12,7 +12,7 @ @
     if -nt { s6-test -d ${dir_run} }
     s6-mkdir -p -m0755 ${dir_run}
 }
-execl-cmdline -s { nginx ${cms_args} -c ${conf_dir}/${conf_file} } )
+execl-cmdline -s { nginx ${cmd_args} -c ${conf_dir}/${conf_file} } )
 
 [stop]
 @ build = auto
And why was this installed in /etc/66/service rather than in /lib/66/service btw? Shouldn't there be only my own administrated custom services here?

Edit 1:
This goes further. I corrected the typo but your -g flag seems to be wrong. I personally never have used directives with nginx. The flag itself seems to be correct so I guess the whitespace is most probably not escaped well.
(The types_hash_max_size is to be ignored) 
@ 400000005e2ae1523797dc42 2020/01/24 13:21:01 [warn] 3413# 3413: could not build optimal types_hash, you should increase either types_hash_max_size: 1024 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
@ 400000005e2ae15237a0f456 2020/01/24 13:21:01 [notice] 3413# 3413: signal process started
@ 400000005e2ae15237a0f79f 2020/01/24 13:21:01 [error] 3413# 3413: open() "/run/nginx.pid" failed (2: No such file or directory)
@ 400000005e2ae15336b8ac5e nginx: invalid option: "off;""
Edit 2:
Also during further testing when I just remove the -g option from the frontend command the log file will not show the error anymore (as expected) but localhost will not be reachable. Manually starting nginx from the command line works as expected, also with -g "daemon off;". The [notice] signal process started looks wrong to me. There's no signal sent in the [start] command in the frontend file so why this notice?

Edit 3:
If I remove env from @ options and the whole env section and hard code the service like this it somehow works (despite the fact that the -g option is still not parsed right [as it still appears in log even though the service runs like this, the option is ignored]): 
[main]
@ type = classic
@ description = "nginx daemon"
@ user = ( root )
@ options = ( log )

[start]
@ build = auto
@ execute = (
foreground
{
    if -nt { s6-test -d /run/nginx }
    s6-mkdir -p -m0755 /run/nginx
}
nginx -g "daemon off;" -c /etc/nginx/nginx.conf )

[stop]
@ build = auto
@ execute = (
execl-cmdline -s { nginx -s stop } )
Edit 4:
In contrast this does NOT work (!): 
@ execute = (
...
execl-cmdline -s { nginx -g "daemon off;" -c /etc/nginx/nginx.conf } )
Edit 5:
I can personally get it to work with bash like this:
(Meaning I can enable and start the service, reach the server and have no errors shown in log) 
[start]
@ build = custom
@ shebang = "/bin/bash"
@ execute = (
  if [ ! -d "/run/nginx" ]
  then
    mkdir -p -m0755 /run/nginx
  fi
  nginx -g "daemon off;" -c /etc/nginx/nginx.conf
)

[stop]
@ build = custom
@ shebang = "/bin/bash"
@ execute = (
  nginx -s stop
)
Although I wonder why when issuing "66-disable -S ..." the [stop] command won't get forwarded. Because when I do "66-stop" it does. This means that when I 66-disable the server is still reachable.
Also the -g "daemon off;" flag makes this an active foreground process. How is it then that when omitting this option in the frontend command the programm will constantly get called? (I can see this tapping like crazy on F5 while navigating to localhost) Shouldn't it just be fired once and then sent to background as it does from the command line?
Has this to do with the classic type? As in: classic will try to be constantly up and after firing the command without the -g "daemon off;" option the program closes and needs to be brought up again? Is that it?
Funnily though if I want to make it a oneshot service then I get all sorts of error messages about how my command is a missing directory...(please take note that I debug this by always re-enabling the service with 66-enable -FSC)
marianarlt wroteAnd why was this installed in /etc/66/service rather than in /lib/66/service btw? Shouldn't there be only my own administrated custom services here?
You must be the only one using it and must have been forgotten from the early 66 days where services were kept at /etc/66...
Yeah probably :/
Fun fact though: Obarun is in its entirety (web+repos) hosted on a nginx server and high traffic sites often use nginx instead of apache. It is also the second most used web server right behind apache not lacking behind too much. To be honest: I had never heard of it before getting somewhat involved here (even working mostly on web dev...)
More fun: The Arch servers I just probed also mostly (like 13 of 15 I checked) run on nginx
I just checked all -66serv packages, nginx is the only one that is outdated, it would still work apart from the typo you found in the etc/66 since it is picked up as a user/admin defined service.
@ marianarlt
Good catch, you found one! Many thanks to found it and report it!

So, nginx-66serv was updated and please update 66-tools will should solve the trouble about the parse of double-quote string("daemon off;"). That's why your bash version works and not the execline one. Execl-cmdline didn't parsed the string correctly.
Try the 66-disable -S nginx and worked for me. But maybe another user can test and report if they have the same issue.
To be honest i cannot help much about nginx, never used. Maybe jm can be more helpful.
But try with the updated version and tell us if the behavior are correct or not.
Thanks for the prompt fix. I'll sure do as soon as possible. Probably not before Monday though. Have a nice weekend everyone!
4 months later
Quite the delay here, but I'm now setting up LEMP again and the nginx service seems to work fine but now I have some comments on mysqld-66serv
marian@ obarun ~ % sudo 66-inservice mysqld
Name                  : mysqld
Version               : @ VERSION@
In tree               : nginx
Status                : enabled, down (exitcode 100) 0 seconds, normally up, want up, ready 0 seconds
There's nothing written to /var/log/66/mysqld/current and the service is definitely not running. There's neither a socket nor a pid file in /run/mysqld

On a quick glimpse I can not see why it would bail. You got a lot of s6 commands in the start script which I'm unfamiliar with.
I think you over complicate things, why all the directory options when they're set to default anyways? I suppose you're wanting to provide this all written out so somebody might just copy/paste when overwriting the service to change the options? I think it makes for bloat. But that's not the point really. The service doesn't work.

Another nit pick is this:
https://mariadb.com/kb/en/running-mysqld-as-root/ wrote MariaDB should never normally be run as the system's root user (this is unrelated to the MariaDB root user). If it is, any user with the FILE privilege can create or modify any files on the server as root.
[...]
Better practice, and the default in most situations, is to use a separate user, exclusively used for MariaDB. In most distributions, this user is called mysql.
Although this is from MariaDB it sure translates simply to MySQL. (You're frontend file DESCRIPTION field even says "mariadb server daemon", which is funny)
So I suppose a @ runas = mysql field might be a good choice here.

Also note that:
https://mariadb.com/kb/en/mysqld_safe/ wrote The mysqld_safe startup script is in MariaDB distributions on Linux and Unix. It is a wrapper that starts mysqld with some extra safety features. For example, if mysqld_safe notices that mysqld has crashed, then mysqld_safe will automatically restart mysqld.

mysqld_safe is the recommended way to start mysqld on Linux and Unix distributions that do not support systemd.
If I launch a shell on the mysql user and manually start the daemon with 'mariadbd-safe' (or 'mysqld_safe') from there, the socket gets created at the default location and the database seems to be accessible as expected (although without a pid file being created).
And an another bugged one!

So, synchronize and enable again your service but do not forget to use the -C option because some variable name was changed, so: 
# 66-enable -t nginx -F -C mysqld
Now, some explanation is apparently needed.

First, i suspect that you copied the frontend file directly from the framagit repo. This is absolutely abnormal 
Version               : @ VERSION@
it should be something like this 
Version               : 0.2.0
This is not so important with the current version of 66 but it will be with the next release. The package make the necessary at installation phase (it replace @ VERSION@ by the version found at pkgver provided from the mysqld-66serv PKGBUILD). So be careful in the future about that.

Well, i will explain what it's done by the @ execute field (see the comment of each line) 
if {
		execl-toc -t -E ${data_dir} # check if the data_dir=/var/lib/mysql is empty or not. If it's empty then execute the next line of the script
		execl-cmdline -s { mysql_install_db --user=${cmd_args} --datadir=${data_dir} } # run mysql_install_db to create a db at /var/lib/mysql
	}
	execl-subuidgid -o mysql # ask to replace every UID GID term found in this script (after this line) by the corresponding UID and GID of mysql user
	execl-toc -d ${socket_dir} -u ${UID} -g ${GID} # check if the directory socket_dir=/run/mysqld exist. if not create it and chown it with UID:GID
	umask 007 # umask think here to be safe
	s6-setuidgid mysql # ask to execute the next line with the mysql user permissions.
	execl-cmdline -s { mysqld --datadir=${data_dir} --pid-file=${pid_file} --socket=${socket_dir}/${socket_file} } # finally execute the daemon
I suppose you're wanting to provide this all written out so somebody might just copy/paste when overwriting the service to change the options
66 works on every distro. The default for you doesn't mean the same default for every distro. So, the service give the possibility to be flexible for every case :) without the need to rewrite the frontend file itself.
66 works on mechanisms not on policies :)

Also a little trick. When you didn't found nothing at the service logger, take a look at the uncaught-logs /run/66/log/0/current. This log is not only the boot log but catch all message sended at the main scandir(PID1). If you run a service without it own logger, the uncaught-logs will catch its log. So, when a service doesn't run and its associated logger too, you may found information on the uncaught-logs.
Oh so you're already running it as mysql user then? That's one of the funny lines I completely didn't understand. Isn't that what @ runas is designed for specifically? What's the advantage here?
eric wrote [...]i suspect that you copied the frontend file directly from the framagit repo[...]
I'm sorry to tell you that I just did 'sudo pacman -S mysqld-66serv' on a completely fresh clean minimal install with the latest ISO :s
Shows the version fine now after the update though (0.2.1), I wouldn't worry too much about it.

Service is confirmed to work from my side with v0.2.1-1

I totally get the defaults now, you're apparently right about distro compatibility. We Obarun peons don't care about compatibility usually I guess :P that's really what makes it even more superior. Good job.
And thanks for the hint to uncaught-logs!
If you set @ runas=mysql, the complete @ execute field will be launch with mysql user. So,at socket directory creation time, you will get an issue because the user mysql do not have sufficient permissions to create it. In this case we cannot use the @ runas field and we are forced to pass to mysql user at some point of the script execution.
3 years later
eric unstickied the discussion .

Powered by Obarun