> 1. Write a stage-1 init script in standard Linux Bash shell
> scripting. Because Bash is the stereotypical universal Linux shell
> on most distributions, we felt that it's usage in the scripting
> process would aid and ease s6 into the system faster and cleaner.
> However, we are not above utilizing scripting using execline if
> necessary as a learning tool, but our goal is to use standard Bash.
My point is that there are a few shells out there, and people may
want to use something else than bash. (ash, dash, zsh, you name it,
someone swears by it.) So please use /bin/sh and avoid bashisms to
remain portable (if that means anything for a stage 1 init).
The only place where you will need a bit more oomph than /bin/sh
provides is to open a fifo for writing when there's no reader yet.
(To redirect /sbin/init's stdout and stderr to the fifo that will be
read by the catch-all logger, but the logger isn't up yet since it
will be started by s6-svscan.)
That shouldn't be a problem though: you have execline installed
and you can use redirfd in a shell script. You will just have to
write something like "exec redirfd -wnb 1 fifo sh -c 'rest of script'".
Chain loading works with the shell too, it's just cumbersome (and
a bit slower) when you need to execute into another shell.
> 2. As far as service scripts are concerned, we may use either
> execline or bash scripting depending on which moved things along
> faster.
/bin/sh is perfectly fine as long as you remember to exec the
long-running process in the end to avoid keeping a dangling shell
and sending signals to the wrong process.
The main reason I use execline for run scripts is that execline is
best suited for pure chain loading, and run scripts mostly involve
process state changes (fd redirections, environment setting, resource
limits setting, etc.) followed by an exec, and those are best
performed by chain loading: both runit and s6 provide process state
change programs for such use.
Chain loading also makes it easy, for instance, to insert a
"strace -vf" at any point in your run script for debugging purposes.
--
Laurent
Received on Wed Jun 25 2014 - 22:33:19 UTC