[crux-devel] rc-ng scripts

Jose V Beneyto sepen at crux-arm.nu
Wed Feb 29 18:28:50 UTC 2012

Hey all,

Michael, thanks a lot, your work is too appreciated.

This mail, due to my poor English and little time nowadays, probably not 
cover everything I think, but I've long wanted to send it and should not 
delay it anymore, so sorry if there is anything that is not well 
explained or incomplete.
I'll try to argue my POV with advantages/disadvantages as better as 
possible, and if necessary bringing new ideas and proposals.

The first thing that comes to my mind is the complexity of the new 
solution for system initialization files that you have proposed.
I think that it's much more complicated than our current one, but I'm 
always open to new ideas and improvements.
I supposse that you worked in this stuff due to solve/optimize issues 
you found, maybe with lvm/mdadm, but I'm not 100% sure that I got the 
whole idea, so please correct me if I'm wrong somewhere. Also I noted 
that ArchLinux has a similar implementation (1) that could be reviewed.

*** (about hooks) ***

Basically I like user configurable hooks as alternative to rc.local (or 
complement), and not as an imposition (some hooks are empty files).
I'd like to have a minimal rc port, and let people to use as hooks as 
need it. This would make for rc* init scripts to load only the hooks 
that were selected by users to use.
Personally, I have years managing CRUX systems and I've never needed 
anything extra apart from a couple of lines in rc.local, as is the case 
with rc.local/rc.local.conf in OpenBSD systems.
Accordingly, I think we might have enough to accommodate all the hooks 
in a single directory, I like: /etc/rc.conf.d/hooks.

Another disadvantage (IMHO) with rc-hooks could be inherited and overlap 
the config that has established the user. Which brings us back to run 
rejmerge for all rc-hooks (around 20 hooks maybe?) after each update rc 
port. That reinforces the idea of ​​having a small rc port.

In addition I'd like to review the naming convention. I prefer the one 
used by ArchLinux (2) which could be housed in the same directory (maybe 
/etc/rc.conf.d/hooks/) and not lose its meaning:

your schema => my proposal
multi/early => multi_start
sysinit/early => sysinit_start
sysinit/late => sysinit_end
sysinit/udev-runner1 => sysinit_udev-runner1
sysinit/udev-runner2 => sysinit_udev-runner2

Also I found that there are 2 hooks (sysinit/early and 
sysinit/pre-trigger1) where the second hook is executed immediately 
after the first one which is meaningless, so in this case both hooks 
could be merged into one:

--- /etc/rc.sysinit ---
rc_hook sysinit/early
rc_hook sysinit/pre-trigger1
--- endof /etc/rc.sysinit ---

*** (about functions) ***

I like most functions you added and/or implemented, new tools from 
util-linux-ng (like findmnt, etc.) and also new bash syntax and 
features. Good work!!
But why not have all functions in only one file? (maybe 
/etc/rc.conf.d/functions) So there are about only 30 functions.
$ grep 'function .*()' /etc/rc.engine/* | wc -l

IMHO code refactoring makes sense when the same function is used from 
multiple places. If, for example, rc.engine/multi functions are only 
used from rc.multi script the it makes no sense to separate it into a 
single file, so the effect would be the same like include only those 
functions in rc.multi script since no more rc scripts required them.

Also I would like to adopt and/or discuss a more consistent naming 
convention for functions.

your schema
rc.engine/all:function __rc_spawner() {
rc.engine/all:function rc_srv_start() {
rc.engine/lib:function start_kmsg_log() {
rc.engine/sysinit:function __si_console() {
rc.engine/sysinit:function __si_seed() {
rc.engine/sysinit:function si_std() {

my proposal
rc_spawner(), rc_srv_start(), kmsg_log_start(), sysinit_console(), 
sysinit_seed(), sysinit_std(), ...

In addition it would be fine to have some functions like 
start_service(), stop_service() that could be used by services/daemons 
in /etc/rc.d/* like sshd or others.
For example, stop_service() basically could do:

stop_service() {
local SUCCESS=0
local SERVICE=$1
local PIDFILE=/var/run/$SERVICE.pid
#[ $VERBOSE -eq 1 ] && echo -n "Stopping $SERVICE:\t"
if [ -f /var/run/$SERVICE.pid ]; then
kill $(< /var/run/$SERVICE.pid)
if [ $? -ne 0 ]; then
rm -f /var/run/$SERVICE.pid
killall -q /usr/sbin/$SERVICE # we could use another argument like 
$BINFILE instead of $SERVICE
[ $? -ne 0 ] && SUCCESS=1
#if [ $VERBOSE -eq 1 ]; then
# if [ $SUCCESS -eq 1 ]; then
# echo "[OK]"
# else
# echo "[FAILED]"
# fi
-- note that this is only an idea and of course it could be written 
better, have global vars like $VERBOSE, etc.

*** (lvm/mdadm) ***

For what I see, /etc/rc.hooks/sysinit/udev-runner1 is the place where 
lvm/mdadm lives.
Can't be possible to move this stuff to their respective daemons in 
/etc/rc.d/lvm and /etc/rc.d/mdadm? It could be a clean way and better 
for boxes where no lvm/mdadm config is required and/or used.

*** (miscelaneous) ***

Why you added -8 --noclear to inittab?
-- c1:2:respawn:/sbin/agetty 38400 tty1 linux
++ c1:2:respawn:/sbin/agetty 38400 -8 --noclear tty1 linux
IMHO, I would leave it as is and give users freedom to change or not.

Why not move rc.engine/tlkd to functions as tlkd(), or even to 
/etc/rc.d/tlkd as a complete daemon service?

I'm sure I missed something but at least I hope I have expressed my 
ideas and opinions.

Best regards,

(2) https://wiki.archlinux.org/index.php/Arch_Boot_Process#Custom_hooks

Jose V Beneyto | http://sepen.it.cx/

More information about the crux-devel mailing list