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-02-2008, 06:54 AM
Petter Reinholdtsen
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

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

Well. As 'update-rc.d scriptname default' will have to keep its old
behavoiur, to avoid breaking a lot of functioning packages, I see no
other sensible way to change the default for most packages.

> 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.

Yes.

Happy hacking,
--
Petter Reinholdtsen


--
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, 04:50 PM
Russ Allbery
 
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.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
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, 07:38 PM
Colin Watson
 
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.

The point is that, if all you're going to do by way of a "clean
shutdown" is send SIGTERM to the process and not wait for it to complete
(which is the case for quite a number of init scripts; Scott did a
survey of those that were part of a stock Ubuntu desktop installation at
http://wiki.ubuntu.com/Teardown), then you might as well just let
sendsigs do that since it's going to do so anyway.

This isn't "not doing clean shutdowns" - it's just rationalising away
multiple init scripts called on shutdown that are duplicating work done
by a core script.

Cheers,

--
Colin Watson [cjwatson@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, 07:39 PM
Colin Watson
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Thu, Jan 03, 2008 at 06:29:09AM +1100, Robert Collins wrote:
> On Wed, 2008-01-02 at 09:50 -0800, Russ Allbery wrote:
> > 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.
>
> Meh, two answers to my point that equate 'data loss' with 'incomplete
> transactions are not committed'.

This is true, but it's still a change in the behaviour of the system
that may or may not be desirable. The purpose of the change Petter is
proposing (at least the purpose of the same change when it was done in
Ubuntu) is a trivial transformation of init scripts that does not
produce any meaningful change in behaviour.

--
Colin Watson [cjwatson@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, 07:47 PM
Russ Allbery
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Colin Watson <cjwatson@debian.org> writes:

> The point is that, if all you're going to do by way of a "clean
> shutdown" is send SIGTERM to the process and not wait for it to complete
> (which is the case for quite a number of init scripts; Scott did a
> survey of those that were part of a stock Ubuntu desktop installation at
> http://wiki.ubuntu.com/Teardown), then you might as well just let
> sendsigs do that since it's going to do so anyway.
>
> This isn't "not doing clean shutdowns" - it's just rationalising away
> multiple init scripts called on shutdown that are duplicating work done
> by a core script.

Right. The only case where a shutdown script makes sense to me is if it's
doing something other than sending signals or if it's waiting
(intelligently, not just blindly for five seconds) for the process to shut
down cleanly.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
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, 09:08 PM
Felipe Sateler
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Petter Reinholdtsen wrote:

>
> Did you ever curse that Debian took so long to shut down, waiting for
> all the shutdown scripts to complete before the machine was ready to
> move? Here is a simple recipe to help making sure your package do not
> slow down the shutdown.
>
> Most of the init.d scripts are simple scripts that during shutdown
> kill the process they started during boot. But the default halt (0)
> and reboot (6) shutdown sequences will kill all processes on their own
> (in the sendsigs script), so there is normally no need for individual
> packages and init.d scripts to run at shutdown if all they need to do
> is to kill a daemon. There might be exceptions, for example if the
> daemons need to stop in a given order, but that do not seem to be the
> case for most packages.

Are the five seconds that sendsigs waits between TERM and KILL enough to cleanly
shutdown *all* running services at the same time?

--

Felipe Sateler


--
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, 09:31 PM
Roger Leigh
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

Felipe Sateler <fsateler@gmail.com> writes:

> Petter Reinholdtsen wrote:
>
>>
>> Did you ever curse that Debian took so long to shut down, waiting for
>> all the shutdown scripts to complete before the machine was ready to
>> move? Here is a simple recipe to help making sure your package do not
>> slow down the shutdown.
>>
>> Most of the init.d scripts are simple scripts that during shutdown
>> kill the process they started during boot. But the default halt
>> (0) and reboot (6) shutdown sequences will kill all processes on
>> their own (in the sendsigs script), so there is normally no need
>> for individual packages and init.d scripts to run at shutdown if
>> all they need to do is to kill a daemon. There might be
>> exceptions, for example if the daemons need to stop in a given
>> order, but that do not seem to be the case for most packages.
>
> Are the five seconds that sendsigs waits between TERM and KILL
> enough to cleanly shutdown *all* running services at the same time?

On a heavily loaded or slow system, I suspect it would be highly
likely some would get SIGKILL before they could shut down properly.
I can't say I'm a big fan of the proposal for this reason.

With a better init, like upstart, or a dependency-based init, there's
no reason why scripts can't be run in parallel. But, simply sending
everything a TERM and KILL doesn't seem do be very clean in my
understanding.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
 
Old 01-03-2008, 01:45 AM
Colin Watson
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Wed, Jan 02, 2008 at 10:31:33PM +0000, Roger Leigh wrote:
> Felipe Sateler <fsateler@gmail.com> writes:
> > Are the five seconds that sendsigs waits between TERM and KILL
> > enough to cleanly shutdown *all* running services at the same time?
>
> On a heavily loaded or slow system, I suspect it would be highly
> likely some would get SIGKILL before they could shut down properly.
> I can't say I'm a big fan of the proposal for this reason.

If this is a real problem for a given service, surely its init script
should actually wait for the process to shut down cleanly? If so, it
wouldn't be a candidate for this refactoring.

--
Colin Watson [cjwatson@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-03-2008, 07:24 PM
Petter Reinholdtsen
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Roger Leigh]
> On a heavily loaded or slow system, I suspect it would be highly
> likely some would get SIGKILL before they could shut down properly.
> I can't say I'm a big fan of the proposal for this reason.

I do not understand this objection. The only way I can get it to make
sense is by assuming that you believe my proposal is to remove most
packages init.d scripts from the shutdown runlevels, even the ones
that need special care when taking the service down. And that is not
what I am proposing. I am claiming that there are daemons around that
_do not_ need any special care when the service is taken down, and
that these daemons do not need a script in runlevel 0 and 6 to take
them down as it is faster to let the sendsigs script kill them.

Btw, if the 5 second wait isn't long enough for sendsigs, we can
extend it. There is code there to make sure sendsigs terminates as
soon as the last process it tries to kill is dead, so we could
increase the timeout without affecting the normal shutdown times. It
will wait from 0 to 5 seconds at the moment, depending on how long it
take for the processes to die. It would not be a problem to let it
wait from say 0 to 10 seconds, or 0 to 30 seconds.

> With a better init, like upstart, or a dependency-based init,
> there's no reason why scripts can't be run in parallel. But, simply
> sending everything a TERM and KILL doesn't seem do be very clean in
> my understanding.

It is already possible to run the sysv-rc system in parallel when
using the dependency information provided in the LSB headers, using
the insserv package, so there is no need to replace sysvinit to get a
better init.

Unfortunately, there is still a few bugs in the dependency information
provided in init.d scripts in the debian packages, so at least for a
few corner cases the generated sequence is wrong. See
<URL:http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot> for
information on the progress. Packages are fixed every day, and I hope
the provided information will be correct enough for normal desktop
installs any day now. When that is in place, I will focus on another
goal, the Debian Edu tasks, to make sure Debian Edu can switch to
dependency based boot sequencing for Lenny. I would love Debian to
switch to dependency based boot sequencing for Lenny to, and with luck
and a lot of work, it will happen. Could use some help here, though,
to get LSB headers with dependency information into the 33% of scripts
that are still lacking them, and more testers to discover and fix the
headers with bugs in their dependency information.

I got a report the other day from someone claiming to have used the
dependency based boot sequencing for a long time, and not had any
problems with it, so I guess it is approaching stable. But as I
said, there are still some issues with it, and I report bugs about it
as soon as I find them.

Happy hacking,
--
Petter Reinholdtsen


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

"Petter Reinholdtsen" <pere@hungry.com> wrote in message
news:2flwsqqzmg4.fsf@klodrik.uio.no...


[Roger Leigh]

On a heavily loaded or slow system, I suspect it would be highly
likely some would get SIGKILL before they could shut down properly.
I can't say I'm a big fan of the proposal for this reason.


I do not understand this objection. The only way I can get it to make
sense is by assuming that you believe my proposal is to remove most
packages init.d scripts from the shutdown runlevels, even the ones
that need special care when taking the service down. And that is not
what I am proposing. I am claiming that there are daemons around that
_do not_ need any special care when the service is taken down, and
that these daemons do not need a script in runlevel 0 and 6 to take
them down as it is faster to let the sendsigs script kill them.


Indeed it seems redundant for the initscripts to send signals that will be
sent by a later script anyway.


Obviously removing those scripts should have no impact on the other
initscripts.


However, I think the concern is that more processes would end up getting
SIGKILL'ed, as
an initscript that more or less what sendsigs does (SIGTERM, 5 seconds,
SIGKILL) would be more likely to result in the program shutting down
cleanly. Why? Well odds are that there are plenty of idle cycles, so the
program basically has the full 5 seconds to shutdown. However, if that
process has to share those 5 seconds with several other processes being
SIGTERM'ed it is somewhat less likely to reach the end of the clean shutdown
cycle than if it were the only process being shutdown. We are of course
discussing processes where being SIGKILL'ed is not a really big deal, but it
is still preferable to have as few SIGKILL'd processes as reasonably
feasible during shutdown.



Btw, if the 5 second wait isn't long enough for sendsigs, we can
extend it. There is code there to make sure sendsigs terminates as
soon as the last process it tries to kill is dead, so we could
increase the timeout without affecting the normal shutdown times. It
will wait from 0 to 5 seconds at the moment, depending on how long it
take for the processes to die. It would not be a problem to let it
wait from say 0 to 10 seconds, or 0 to 30 seconds.


That does sound like a reasonable solution to the concern.

How feasible would it be to make the pause time a function of the number of
processes sendsig must reclaim? That seems to make some sense to me.
Obviously there should be a sane upper and lower bound (5 seconds and 30
seconds sound fine to me).




--
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:54 AM.

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