supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: John Nielsen <knoglen@tele2.fr>
Subject: Re: /etc/runit/3 not executing correctly...
Date: Wed, 28 Jul 2004 19:03:13 +0200	[thread overview]
Message-ID: <200407281903.13077.knoglen@tele2.fr> (raw)
In-Reply-To: <20040728082531.25730.qmail@3e6d1c7b6981a8.315fe32.mid.smarden.org>

On Wednesday 28 July 2004 10:25, Gerrit Pape wrote:
> On Tue, Jul 27, 2004 at 08:26:35PM +0200, John Nielsen wrote:
> > On Tuesday 27 July 2004 18:55, John Nielsen wrote:
> > > > > That message is not from runit, did you post your complete stage
> > > > > 3 script, or only a top part of it?
> > > >
> > > > Yes, I posted all of the script. I had cut it down as much as
> > > > possible to troubleshoot.
>
> You should extend it.  Stage 3 is meant to do all tasks necessary to
> prepare the system for shutdown, this includes stopping services and
> unmounting (mounting read-only) filesystems.  

Yes, I know. I used to have a lot more in it. I just cut it down in order to 
better troubleshoot it. I have allready cut and pasted most of my old script 
into stage 3. Im going to clean it up later.

> After stage 3 has finished, runit tells the kernel to shutdown or reboot 
(depending on the
> permissions of /etc/runit/reboot).

Aah, so thats how it tells the different between a halt and a reboot. Thanks.

> > > > I really dont know where that message somes from then? That
> > > > textstring "Unmounting any remaining filesystems" doesnt exist in
> > > > any of the existing boot scripts. I just doublechecked, and it
> > > > isnt there. Where else could it come from? The kernel itself?
> > >
> > > I found out where the message comes from. It is generated by the
> > > util-linux version of shutdown I am using. Its last action before it
> > > halts the computer is to umount everything that is left.
> > >
> > > So all of this seems to be caused by util-linux shutdown not wanting
> > > to play nice with runit.
>
> Yes, util-linux's shutdown does things stage 3 actually should do, from
> the man page:
>
>  When the shutdown time arrives, shutdown notifies all users, tells
>  init(8) not to spawn more getty(8)'s, writes the shutdown time into the
>  /var/log/wtmp file, kills all other processes on the system, sync(2)'s,
>  unmounts all the disks, sync(2)'s again, waits  for a second, and then
>  either terminates or reboots the system.
> Additionally it seems to work with some fixed timeout.  The shutdown
> program killed your stage 3 script and rebooted the system while runit
> still was preparing the shutdown.

So thats what happened. I definetely dont want shutdown to go around killing 
processes. I want that honor myself. :o)

>
> > > I would really love to be abel to completely dump the sysvinit
> > > package. I guess my case is a special one since I am not using a
> > > standart distro.
>
> As Charlie already said, simply don't use a shutdown program, extend
> stage 3, and use `init 0` and `init 6` instead.
>
> > I noticed a strange problem however. Every time i shut down, the
> > getties dies except for the getties that are logged in. I have to
> > start the shutdown script and then log out on that console.
>
> That's normal, see Charlie's answer on this.
>
> > I know that I can specify a timeout on svwaitdown that kills the
> > service when the timeout has been reached, only this doesnt seem like
> > a very clean shutdown. Is it possible to shut down the session cleanly
> > without killing it?  Im talking about something along the lines of
> > what sysvinit does.
>
> What's sysvinit doing?  AFAICS it kills -9 your shell, but doesn't tell
> you about that.

I think i wasnt very clear in my description. Let me try and elaborate.

Sysvinit first asks everyone nicely to shut down. After a few seconds it uses 
the chainsaw on everything left before it continues. This gives well behaving 
programs a chance to exit gracefully and it gives badly written programs what 
they deserver. This lets the getty exit cleanly as far as I understand.

Runit on the other hand (I am new to this so please correct me if im wrong) 
asks all of the getties nicely to get out. This runs the finish script for 
each getty that shuts down cleanly and updates utmp. The getties that are 
logged in doesnt exit cleanly like this, gets seriously pummeled and doesnt 
get to run "finish" which doesnt update utmp. (right?)

My question is basicly if it is possible to nuke the console while leaving 
getty intact. This would allow getty to exit cleanly. If the only getties 
that updates utmp are the ones that are not logged in, then whats the point?

If im missing something obvious, please let me know.

Regards,

John





      reply	other threads:[~2004-07-28 17:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-26 16:10 John Nielsen
2004-07-26 16:18 ` Laurent Bercot
2004-07-26 18:06   ` John Nielsen
2004-07-27 10:43     ` Gerrit Pape
2004-07-27 16:23       ` John Nielsen
2004-07-27 16:55         ` John Nielsen
2004-07-27 18:26           ` John Nielsen
2004-07-27 18:42             ` Charlie Brady
2004-07-28  8:25             ` Gerrit Pape
2004-07-28 17:03               ` John Nielsen [this message]

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=200407281903.13077.knoglen@tele2.fr \
    --to=knoglen@tele2.fr \
    /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).