init signals and touching files

init signals and touching files

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]

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}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: init signals and touching files

[Gerrit Pape]

Hi Vincent,

On Sun, Feb 27, 2005 at 08:59:34PM -0700, Vincent Danen wrote:
> 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 

in stage 1 (and 3) runit discards signals, they only work in stage 2.
Can you show your stage 1 script?

> 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.

You can have stage 1 exit with return code 100 in this case.  This
causes runit (version 1.2.1) to skip stage 2 and go to stage 3
immediately.

Another option is to do the system reboot from the stage 1 script itself
(using reboot(2)) in case of an error, this also eliminates the need to
change the /etc/runit/reboot file.  I posted a tiny program than does
this some time ago.

> 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?

See the runit man page for the signals runit supports, but it always
additionally checks for a magic file in /etc/runit/ on signals.  I
designed the runit system to work fine with a read-only root filesystem,
you can make any magic file or directory (etc/runit/stopit,
/etc/runit/reboot, service/supervise, ...) a symlink, even a dangling
symlink, pointing to a ramdisk or similar.  But this might not be
necessary in your case: you don't need to rely on the runit program to
tell the system to reboot or halt at the end of stage 3.  Reboot or halt
can be caused by the stage 1 or 3 script itself (using reboot(2)).

> 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 

This shouldn't happen, what's the permissions of /etc/runit/reboot in
this case?  If you run `init 6` it should be 0100, and the runit
program, after stage 3 finished, checks for that to decide whether to
reboot or halt.

Regards, Gerrit.

init signals and touching files

[Vincent Danen]

[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]

(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}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: init signals and touching files

[Kevin]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]


> 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?

I'm wondering somewhat with your stage 3 script looks like.  I've only
ever had the shutdown troubles you describe on a FreeBSD box that was
using the port, which had some somewhat goofy stage scripts.  I took the
useful bits from my Debian GNU/Linux stage 3 scripts to fix it up, and
it now shutsdown and reboots like it is supposed to.

> 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.

This sounds like you either need to place the driver within the kernel,
or place sata_promise in /etc/modules...  I'm guessing you're able to
boot this drive at all due to an initrd or similar..

> 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.

Check out your stage 3 script.  Something is wrong there, I'm thinking.
Did you install via a distribution package, or from the slashpackage?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]