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
