Hi James,
> I have had a though, why not include symlinkable functionality for
> halt, poweroff, shutdown, and reboot directly in s6-svscanctl
s6-svscan can be used as a normal process, not only as process 1,
and there can be more than one scan directory on the system.
Calling s6-svscanctl "shutdown" would only be valid when applied
to the main scan directory: this implies embedding some policy
into the software. s6 is not the place to do that. However, the
s6-linux-init package I'm working on will provide "shutdown"
compatibility binaries.
> and move s6-pause into s6 itself to simplify the packages
s6-pause is a hack to have a live process that does nothing. I'm
using it as a test tool and as a placeholder for real run scripts.
But in a real installation, it should not be needed. If you need
s6-pause in a real configuration, you are probably using a
process supervision framework to implement supervision of services
that do not need a long-lived process, and this is ugly. I'm
working on finding a better design.
Think of s6-pause as a long "sleep" process. You wouldn't want
that in your scripts, would you ? And if you *really* need that
functionality, use "sleep 2147483647". I guarantee your system will
reboot before that sleep exits. :P
> Anyways, I'll be posting more frequently about getting
> init-stage-1/2/3 drafted correctly and in execline script language.
Don't let execline steal your focus. If you want to write scripts
and are more comfortable with sh, write in sh and get something
running. Converting scripts to execline is always possible later.
The only place where execline is important to have is the early
logging pipe in stage 1, and then again you only need redirfd.
I like writing in execline because it makes chain loading a lot
easier than sh does, it's more predictable, on embedded systems the
resource savings are not negligible, and most important, I've
grown accustomed to it and can now speak it as fluently as sh.
But for early development, if you are more familiar with sh, by
all means use what you are familiar with and focus on the job, not
on the tool.
--
Laurent
Received on Sat Jan 03 2015 - 09:04:09 UTC