From: Vincent Danen <vdanen@annvix.org>
Subject: init signals and touching files
Date: Sun, 27 Feb 2005 20:59:34 -0700 [thread overview]
Message-ID: <d7e68b1437defb3e875dcb6575c8db41@annvix.org> (raw)
[-- 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 --]
next reply other threads:[~2005-02-28 3:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-28 3:59 Vincent Danen [this message]
2005-03-04 15:56 ` Gerrit Pape
2005-02-28 15:46 Vincent Danen
2005-03-01 14:29 ` Kevin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d7e68b1437defb3e875dcb6575c8db41@annvix.org \
--to=vdanen@annvix.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).