FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-03-2008, 10:22 PM
Kurt Roeckx
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Fri, Jan 04, 2008 at 12:16:28AM +0100, Kurt Roeckx wrote:
> On Fri, Jan 04, 2008 at 12:01:17AM +0100, Petter Reinholdtsen wrote:
> >
> > # use SIGCONT/signal 18 to check if there are
> > # processes left. No need to check the exit code
> > # value, because either killall5 work and it make
> > # sense to wait for processes to die, or it fail and
> > # there is nothing to wait for.
> > - killall5 -18 $OMITPIDS || break
> > +
> > + if killall5 -18 $OMITPIDS ; then
>
> Why is it using -18? Please change that to SIGCONT, it depends on the
> arch what the value should be. See signal(7), which even mentions that
> that is different for ppc/i386.

Which killall5 obviously doesn't support.


Kurt


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 04:10 AM
Steve Langasek
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Thu, Jan 03, 2008 at 10:48:01PM +0100, Gabor Gombas wrote:
> On Thu, Jan 03, 2008 at 10:40:32AM -0800, Steve Langasek wrote:

> > It's also, as commented already in the init script, recognized as a bug in
> > the associated daemon. Fixing that bug would drop the need for the sleep,
> > though if there's a possibility of SIGKILL coming before the daemon is done
> > shutting down then you still don't have a guaranteed cleanup, and there's no
> > good "wait for process termination" facility that we can use from init
> > scripts.

> Yep, "waiting for an unrelated process to exit" is surprisingly hard to
> do correctly. I wonder if the processor connector support in recent
> kernels could be used to create a "kill_and_wait" utility:

> - start listening on netlink for process-related events
> - send the signal to the process
> - wait until we receive a notification that the process has died (or a
> timeout has occured).
> - from time to time do a kill(pid, 0) just to be sure we did not loose
> netlink messages

In that case, why would we not just migrate toward upstart as an init with
service supervisor capabilities?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 07:44 AM
Gabor Gombas
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Thu, Jan 03, 2008 at 09:10:10PM -0800, Steve Langasek wrote:

> In that case, why would we not just migrate toward upstart as an init with
> service supervisor capabilities?

In the long run that may be desirable, but IMHO it won't happen in the
near future. Or do you already know something about lenny+1? :-)

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 02:18 PM
Wouter Verhelst
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Wed, Jan 02, 2008 at 07:18:53PM +0100, Michael Banck wrote:
> On Wed, Jan 02, 2008 at 07:11:01PM +0100, Michael Tautschnig wrote:
> > Once we are at it: If we don't do clean shutdowns of the services anymore, why
> > don't you just turn off power instead of taking the pain to kill the processes?
> > I guess I missed the point.
>
> Well, not sure whether I'm playing devil's advocate here, but:
>
> init sends a TERM signal to the processes, and only 5(?) seconds later
> the KILL signal. So databases or other services can catch the TERM
> signal and have five seconds to properly shutdown, which might or might
> not be enough.

I really think you ought to be a little bit more sure than "which might
or might not be enough" before starting to play with other people's
data.

Sure, there are many cases where it will do no harm to have the general
process killer kill a process, rather than that process' specific
initscript do so. Perhaps Ubuntu does this; FreeBSD has done so for ages
as well (they literally shut down in seconds). That doesn't mean it's a
good idea to do in *all* cases.

--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 04:36 PM
Simon Richter
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Hi,

Wouter Verhelst wrote:


I really think you ought to be a little bit more sure than "which might
or might not be enough" before starting to play with other people's
data.


Erm, if a daemon loses data if it is given five seconds advance warning,
then it would also lose data on power loss, which is a bug and should be
fixed, not worked around.


The only reason to wait longer for a daemon on shutdown is to allow it
to bring its data into a state which is consistent enough to immediately
start up from without having to rebuild indices etc. However, we only
have very few daemons which that applies to.


Simon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-04-2008, 05:15 PM
Josselin Mouette
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Le mardi 01 janvier 2008 Ă* 15:24 +0100, Petter Reinholdtsen a Ă©crit :
> Ubuntu discovered this a while back, and introduced a method to avoid
> calling stop scripts in runlevel 0 and 6. It is the "multiuser"
> extension to update-rc.d, and in Ubuntu packages are changed to calls
> dh_installinit with '-- multiuser' as an argument to enable it. This
> add the "multiuser" argument (instead of to the "default" argument) to
> update-rc.d, which go on and set up the boot sequence without
> references to the script in runlevel 0 and 6. This can be done
> without such extention, and how is the topic of the rest of my email.

Frankly I couldn’t imagine a worse idea to fix this problem.

Many daemons will corrupt their state if they aren’t killed cleanly.
Leaving them a grace time is actually worse than simply cutting the
power, because you can be sure the daemon is actually writing some data
at the moment you kill it.

The most funny thing comes from daemons which depend on each other. You
will easily hit cases where a daemon will not shut down properly because
it cannot find the one that depends on it, and in the end increase the
shutdown time instead of shortening it.

Let’s just switch to a parallel init system, and the Ubuntu wannabees
will win their precious few seconds without risking to introduce data
corruption bugs on production systems.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 01-04-2008, 09:26 PM
Josselin Mouette
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On ven, 2008-01-04 at 21:58 +0100, Petter Reinholdtsen wrote:
> I am unable to understand your argument. You seem to claim that
> because some daemons need a shutdown script, those that do _not_ need
> a shutdown script but would work fine by just being killed should keep
> their shutdown scripts, and that do not make sense to me. Daemons
> without the need to update state on disk during shutdown (like for
> example gpsd and xfs), do not need more than a signal to die. There
> is no need to give them a grace period.

I do hope there are better examples than a confidential application and
a useless daemon that has been deprecated for years, to justify messing
with dh_installinit and update-rc.d as you are proposing.

--
.'`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
 
Old 01-04-2008, 10:17 PM
Steve Greenland
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On 04-Jan-08, 11:36 (CST), Simon Richter <sjr@debian.org> wrote:
> Erm, if a daemon loses data if it is given five seconds advance warning,
> then it would also lose data on power loss, which is a bug and should be
> fixed, not worked around.

No, it's not a bug, it's simply a fact of life for certain kinds of
services: it can take more than 5 seconds to flush all the changes to
disk, especially when all the other services on the machine are shutting
down at the same time.

And yes, a power loss would cause a data loss. That's why such systems
are running from UPS's capable of initiating a shutdown several minutes
before power runs out.

Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-06-2008, 08:31 AM
Mike Hommey
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Sun, Jan 06, 2008 at 10:10:03AM +0100, Tollef Fog Heen wrote:
> * Gabor Gombas
>
> | On Thu, Jan 03, 2008 at 12:14:15PM -0500, Joey Hess wrote:
> |
> | > It's fairly common to add a sleep in restart to (try to) deal with
> | > issues such as reopening a socket.
> |
> | But if the listening socket is still open then some apache module may
> | still be doing disk I/O/database access/etc. as well, which means "stop"
> | should wait till apache really quits.
>
> Taking this argument a bit further, do you think that the sshd init
> script should wait until all users have saved their work and logged
> out before it gives control back to the init sequence?

Note this doesn't really work with sshd. The processes handling the
opened connections are still running after a sshd stop. [1]

Cheers

Mike

1. Except on Redhat systems, where the stop script has been doing a a
killall sshd for a quite long time (IIRC this has been fixed). Restart
doing a stop; start sequence, I let you imagine the nice side-effect
this has when doing a restart after a configuration change.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-07-2008, 11:39 AM
Gabor Gombas
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Sun, Jan 06, 2008 at 10:10:03AM +0100, Tollef Fog Heen wrote:

> Taking this argument a bit further, do you think that the sshd init
> script should wait until all users have saved their work and logged
> out before it gives control back to the init sequence?

On a multi-user system that would be a trivial DoS so no. Just think
what happens if someone opens a file in an editor, leaves it open and
then goes on vacation...

It's the responsibility of the sysadmin to use the '-t' option of
shutdown properly and to check that users have really logged out.

Gabor

--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 12:20 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org