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-01-2008, 06:24 PM
Joey Hess
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen wrote:
> 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

Why is this extension not available in our update-rc.d? As a bonus it
could stop at sequence number 80 too so we could transition to a better
order for runlevel 1.

> And while you work on your init.d scripts, please make sure to update
> the LSB-style header Should-Stop to reflect that the script do not
> need to stop in runlevels 0 and 6. See
> <URL: http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot > for
> more info on this feature.

I don't see documentation about Should-Stop there.

--
see shy jo
 
Old 01-01-2008, 06:29 PM
Joey Hess
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen wrote:
>
> [Andreas Metzler]
> > Is this acceptable according to policy? This will simply discard all
> > local customzations like disabling he service in a special runlevel.
>
> As far as I know, this is the official and supported way. There is no
> 'move' option in the update-rc.d API, so I am not aware of any other
> way to do it.

I was also worried about this when reading your mail. There's no better
way to do it, but is the data loss small enough that it's not a bug if a
package does it? I know a lot of people re-order xdm to run earlier in
boot. If I were the xdm maintainer, I'd fear the storm of bugs if I did
this and lost their settings[1].

The alternative would be changing the default for new installs, but leaving
existing installs as-is.

--
see shy jo

[1] Really it probably makes sense to explicitly stop xdm during shutdown
anyway, since that more cleanly shuts down X.
 
Old 01-02-2008, 01:02 AM
Steve Langasek
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Wed, Jan 02, 2008 at 12:17:54AM +0100, Petter Reinholdtsen wrote:

> [Joey Hess]
> > The alternative would be changing the default for new installs, but leaving
> > existing installs as-is.

> Yes. That might be an acceptable alternative.

> > [1] Really it probably makes sense to explicitly stop xdm during shutdown
> > anyway, since that more cleanly shuts down X.

> How does it more cleanly shut down X? That seem to be the logic
> behind providing all the stop scripts in runlevel 0 and 6, just to
> kill a process. There is nothing magic about sending a signal.

If there's an active X session, surely we would want to give an opportunity
for the session to be saved? I'm not sure that the current behavior
actually ensures this in any case (it's probably racey in nature), but I
think it's worth bearing in mind.

--
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-02-2008, 01:04 AM
Steve Langasek
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Wed, Jan 02, 2008 at 01:46:14AM +0100, Petter Reinholdtsen wrote:

> [Colin Watson]
> > Some packages actually do need to shut down cleanly; in the case of
> > a database, for example, such a change could cause data loss. Thus I
> > wouldn't recommend changing the default, but perhaps providing a
> > more convenient single option to do that common task would be good.

> I believe it might make sense to change the default, if it only take
> effect for a new debhelper compat value. Every maintainer is supposed
> to check the effects of upgrading the compat value, and we could thus
> expect them to check if their init.d script need to run in runlevel 0
> and 6. If they need to stop in runlevel 0 and 6, they can always use
> 'start 20 2 3 4 5 . stop 80 0 1 6.'.

> A new keyword might be a good option too. multiuser is already taken
> and I guess it is expected to mean 'start 20 2 3 4 5 . stop 20 1 .',
> so we would want to come up with another one. Perhaps 'normal', as in
> 'update-rc.d scriptname normal', to mean 'start 20 2 3 4 5 . stop 80 1
> .'?

Changing the behavior of debhelper on a new compat level would be
reasonable, but changing the meaning of "update-rc.d defaults" would not,
given that this would imply maintainers must actively change their packages
in order to preserve data integrity.

--
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-02-2008, 01:42 AM
Joey Hess
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen wrote:
> How does it more cleanly shut down X? That seem to be the logic
> behind providing all the stop scripts in runlevel 0 and 6, just to
> kill a process. There is nothing magic about sending a signal.

xdm's init scripts stops it by sending a TERM, waiting up to 5 seconds
for it to go away, and following with a second TERM. That's different
than sendsigs, which sends a TERM, waits up to 5 seconds and then sends a
KILL. I don't know if this difference is actually significant.

But in the case of xdm, it is significant that it happens as the very
first thing, so you can then watch the rest of the shutdown at the
console (or whatever).

I agree with you about the general case -- most daemons can just be
killed by the general process killer.

--
see shy jo
 
Old 01-02-2008, 02:01 AM
Joey Hess
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen wrote:
> What about changing the default values for dh_installinit for a future
> debhelper compatibility layer, to use 'start 20 2 3 4 5 . stop 80 1 .'
> instead of 'default' when calling update-rc.d?

Then you'd have to use 'dh_installinit -- defaults' to get the
non-default behavior of running the stop script. That's counterintuitive.

The issue of whether to remove the old stop links remains, and if we
decide to remove them, debhelper can't really handle that and
maintainers would have to manually insert the code into their init
scripts when changing debhelper compatability levels.

--
see shy jo
 
Old 01-02-2008, 09:47 AM
Robert Collins
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Wed, 2008-01-02 at 00:29 +0000, Colin Watson wrote:
> On Wed, Jan 02, 2008 at 12:13:13AM +0100, Petter Reinholdtsen wrote:
> > What about changing the default values for dh_installinit for a future
> > debhelper compatibility layer, to use 'start 20 2 3 4 5 . stop 80 1 .'
> > instead of 'default' when calling update-rc.d?
>
> Some packages actually do need to shut down cleanly; in the case of a
> database, for example, such a change could cause data loss.

Surely no more than a hard power failure(*), which databases (even such
lightweight ones as sqlite) are designed to handle.

(*) To any component

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
 
Old 01-02-2008, 11:01 AM
Guus Sliepen
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Wed, Jan 02, 2008 at 09:47:20PM +1100, Robert Collins wrote:

> On Wed, 2008-01-02 at 00:29 +0000, Colin Watson wrote:
>
> > Some packages actually do need to shut down cleanly; in the case of a
> > database, for example, such a change could cause data loss.
>
> Surely no more than a hard power failure(*), which databases (even such
> lightweight ones as sqlite) are designed to handle.

Databases guarantee consistency in case of a power failure, they cannot
prevent data loss.

--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@debian.org>
 
Old 01-02-2008, 05:11 PM
Michael Tautschnig
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

> Robert Collins <robertc@robertcollins.net> writes:
> > On Wed, 2008-01-02 at 00:29 +0000, Colin Watson wrote:
>
> >> Some packages actually do need to shut down cleanly; in the case of a
> >> database, for example, such a change could cause data loss.
>
> > Surely no more than a hard power failure(*), which databases (even such
> > lightweight ones as sqlite) are designed to handle.
>
> You can still lose data transactions that weren't complete, and you may
> have to go through an extended consistency check when the system comes
> back up.
>

Definitely. And databases are likely to store some critical data, just consider
LDAP as yet another database (which, for performance reasons, won't write
changes to disk all the time).

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.

Best,
Michael
 
Old 01-02-2008, 05:18 PM
Michael Banck
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

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.


Michael


--
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 11:33 PM.

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