From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/734 Path: main.gmane.org!not-for-mail From: Gerrit Pape Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: init signals and touching files Date: Fri, 4 Mar 2005 15:56:15 +0000 Message-ID: <20050304155619.2914.qmail@c95b2c6a3c7111.315fe32.mid.smarden.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1110096022 29917 80.91.229.2 (6 Mar 2005 08:00:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 6 Mar 2005 08:00:22 +0000 (UTC) Original-X-From: supervision-return-973-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Mar 06 09:00:22 2005 Original-Received: from antah.skarnet.org ([212.85.147.14] ident=qmailr) by ciao.gmane.org with smtp (Exim 4.43) id 1D7qgT-0008Bt-VK for gcsg-supervision@gmane.org; Sun, 06 Mar 2005 09:00:18 +0100 Original-Received: (qmail 14933 invoked by uid 76); 6 Mar 2005 08:06:02 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 9377 invoked from network); 6 Mar 2005 08:03:01 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: X-MailScanner-To: gcsg-supervision@gmane.org Xref: main.gmane.org gmane.comp.sysutils.supervision.general:734 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:734 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.