(Sorry if this shows up twice, but I sent this last night to the list 
and haven't seen it come thru yet)

I have a bit of an issue with runit and it could be that I'm doing 
something wrong or it could be that maybe this possibility hasn't been 
considered before.

I have an SATA drive in my machine with a reiserfs partition in it.  
For some reason, sata_promise isn't loaded so reiserfs freaks out if it 
can't mount this partition that's noted in fstab.  As a result, it 
prompts me to reboot or drop to an admin shell to fix my stuff.  That's 
all fine, but when I hit exit to reboot the system, runit tries to 
signal itself by touching /etc/runit/reboot.  The problem is, the f/s 
is read-only so it can't touch the file.  It then carries on as normal, 
performing a normal boot, but the filesystem is still readonly which 
causes some services to freak out, etc.  Once I get to stage 2, I can 
tell it to reboot, but it's still complaining about not being able to 
touch the /etc/runit/* files.

This makes me wonder if relying on files as a way to signal intentions 
to runit is really the best idea.  But I'm not sure what would be 
better.  I don't know what signals runit listens for right now, but 
maybe it would be better if signals were used to tell runit we want to 
reboot/halt rather than files?

The other issue I have is that runit-init (which I've renamed to init) 
always wants to shut down.  If I do "init 6", I expect it to reboot, 
but it halts the system.  I don't think runit should care that 
runit-init is now called init, but I don't know.  I did write little 
wrapper scripts to replace the SysVinit reboot/halt scripts (so that 
you can set a time and it sends out a wall message), but the last thing 
called is "init 0" for halt and "init 6" for reboot but in all cases it 
shuts down.  I don't know why though.  Any ideas on this?

Beyond those two issues, using runit rocks.  I can deal with the r/o 
filesystem issue by adding some documentation noting the fact that this 
is a problem and that there is no real damage to anything (because it's 
all mounted r/o), it's just ugly and not very well handled (with 
SysVinit, this has never been a problem).  And it won't actually affect 
me again because now I mount those drives from rc.local *after* I 
manually modprobe sata_promise.

The lack of a reboot issue is big though because it makes doing remote 
administration (ie. a reboot due to a kernel upgrade) extremely 
problematic.

-- 
Annvix - Secure Linux Server: http://annvix.org/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FEE30AD4 : 7F6C A60C 06C2 4811 FA1C  A2BC 2EBC 5E32 FEE3 0AD4}