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

[Joe Smith]
> Obviously removing those scripts should have no impact on the other
> initscripts.

Exactly, (unless there is a dependency relation between two scripts
and one of them is removed from the shutdown sequence. .

> That does sound like a reasonable solution to the concern.

I extended it to 10 seconds. It will be in the next initscripts
upload, planned for when the current unstable package migrate to
testing.

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

Not very feasible with the current killall5. It is the only program
that know how many processes it is going to signal, and the sleep is
done by the script calling killall5.

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

[Gabor Gombas]
> I'm wondering if init could be modified to warn if it really has to kill
> something with SIGKILL but of course syslog is long dead by then so
> unless you've serial console you'll likely miss that warning.

Actually, it might be possible with the latest killall5 and the
sendsigs script (since sysvinit version 2.86.ds1-39). It is now
possible to list pids that should survive sendsigs in
/var/run/sendsigs.omit, and syslog might be listed there, and be
killed just before /var/ is umounted. Of course, that is not what the
current shutdwn sequence look like, so it does not work now.

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, 10:01 PM
Petter Reinholdtsen
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Gabor Gombas]
> That may be a good safety measure. I think it is really hard to hit
> the 5 second limit but when that happens it is very hard to diagnose
> later what went wrong. So if we can increase the max. timeout
> without imposing a real delay in the common case (i.e. when
> everything shuts down properly) that's good.

I increased it to 10 seconds in svn. Not sure how high it should be
set by default, but doubling it seem safe enough.

> Also, how about doing a sync before sending the signals? That way
> I/O generated by the services that _do_ have a proper shutdown
> script won't interfere with killing the "trivial" services. Sure,
> that sync can take time, but then the final sync will be that much
> shorter.

Good idea. Will commit.

Also, it is fairly trivial to detect and report if SIGKILL is needed.
Here is a patch to implement all of these changes. The SIGKILL
detection and reporting code is not tested. Please provide feedback.
If it work, I'll include it in the next initscripts upload. The boot
system is being discussed on
pkg-sysvinit-devel@lists.alioth.debian.org and on the #pkg-sysvinit
IRC channel on irc.debian.org, if you want to reach the maintainers
directly.

Index: debian/initscripts/etc/init.d/sendsigs
================================================== =================
--- debian/initscripts/etc/init.d/sendsigs (revision 1184)
+++ debian/initscripts/etc/init.d/sendsigs (working copy)
@@ -22,23 +22,38 @@
done
fi

+ # Flush the kernel I/O buffer before we start to kill
+ # processes, to make sure the IO of alrady stopped services to
+ # not slow down the remaining processes to a point where they
+ # are accidentily killed with SIGKILL because they did not
+ # manage to shut down in time.
+ sync
+
# Kill all processes.
log_action_begin_msg "Asking all remaining processes to terminate"
killall5 -15 $OMITPIDS # SIGTERM
log_action_end_msg 0
- for seq in 1 2 3 4 5 ; do
+ for seq in 1 2 3 4 5 6 7 8 9 10; do
# 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
+ :
+ else
+ alldead=1
+ break
+ fi

sleep 1
done
- log_action_begin_msg "Killing all remaining processes"
- killall5 -9 $OMITPIDS # SIGKILL
- log_action_end_msg 0
+ if [ -z "$alldead" ] ; then
+ log_action_begin_msg "Killing all remaining processes"
+ killall5 -9 $OMITPIDS # SIGKILL
+ log_action_end_msg 0
+ fi
}

splash_back() {

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, 10:37 PM
Petter Reinholdtsen
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Kurt Roeckx]
> 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.

Historical reasons and because that is what killall5 support, as I
noticed you discovered shortly after you sent this email.

> I think it would be nice that in case it needs to send KILL
> for debug purpuses it could:
> - output which processes are still running

Would need a change in the interface and behaviour of killall5, or
perhaps it is enough to do 'ps -ef' or similar? Not sure if it is
useful in non-debugging sessions, though.

> - have some sort of delay before it turns the box off/reboots.

Fairly easy to do, but I am not sure it is a good idea. I would need
to have some idea about how often the SIGKILL part is reached before
doing that. Do not want to slow down the shutdown only to make
debugging easier.

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-04-2008, 10:54 AM
"Ph. Marek"
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[[ Sorry for intruding in a thread read via http://lists.debian.org ... I hope
I get the reply-headers correct. ]]

> > 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).
>
> Not very feasible with the current killall5. It is the only program
> that know how many processes it is going to signal, and the sleep is
> done by the script calling killall5.
How about going a bit further, and comparing the run-time of processes?
If a process has had 5 seconds of CPU, and is still not finished, it gets
killed (endless loop). If it doesn't use the CPU (one of the allowed CPUs for
this process is idle), it gets killed (as it ignores the signal obviously).

Or, said in another way, the process gets some limited CPU time, and (possibly
limited) time it's in D state.
Of course, that couldn't be done by killall5 ... but some perl-script should
be sufficient for that.


How about that?


Regards,

Phil


--
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:27 PM
"Joe Smith"
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

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


[Joe Smith]

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


Exactly, (unless there is a dependency relation between two scripts
and one of them is removed from the shutdown sequence. .


Ok. Good catch. So it seems to me that any service that is not a shutdown
prerquisite of annother service (a.k.a must be shut down first) and which
can be cleanly shutdown with [SIGTERM; pause; SIGKILL] is a good candidate
for removing the shutdown init script.


Any service that is a shutdown prerequisite, or has a more complicated clean
shutdown procedure should remain using the initscript system for shutting
down.


Those could still benefit from a parallelized initsystem, but that is beyond
the scope of current discussion.




--
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:45 PM
Petter Reinholdtsen
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Joe Smith]
> Ok. Good catch. So it seems to me that any service that is not a
> shutdown prerquisite of annother service (a.k.a must be shut down
> first) and which can be cleanly shutdown with [SIGTERM; pause;
> SIGKILL] is a good candidate for removing the shutdown init script.

Actually, a shutdown dependency mean that a service need to shut down
_after_ a service with the dependency, not before it.

Also, services who need a shutdown script and that depend on scripts
that do not have a shutdown script, can depend on sendsigs instead, so
that is not a reason to keep a script. It is only a reason to be
careful when we move to a dependency based boot sequencing.

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-04-2008, 07:58 PM
Petter Reinholdtsen
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

[Josselin Mouette]
> 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.

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.

No-one has suggested as far as I can see to remove _all_ shutdown
scripts, while all arguments against removing some shutdown scripts
seem to base their argument on that premise. To repeat myself another
time:

Daemons that need a shutdown script should keep it. Daemons that do
not need a shutdown script can drop it, and leave it to sendsigs to
kill them.

The fact that there are some daemons that need their shutdown script
do not affect the fact that there are daemons that do not.

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

How will this be a problem with correct dependencies in the init.d
scripts? Scripts for daemons that need other daemons running should
stop before those daemons, and thus keep working even if the other
daemons happen to be killed by sendsigs and not by the other daemons
init.d script.

> Letʼs just switch to a parallel init system,

What do you mean here? Like sysv-rc with CONCURRENCY=shell or
CONCURRENCY=startpar, or something else?

> and the Ubuntu wannabees will win their precious few seconds without
> risking to introduce data corruption bugs on production systems.

As far as I can see, nothing I have proposed increases the risk of
data corruption, so I fail to understand your comment.

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-05-2008, 11:06 AM
Riku Voipio
 
Default Faster shutdown and the ubuntu "multiuser" update-rc.d extention

On Fri, Jan 04, 2008 at 11:26:21PM +0100, Josselin Mouette wrote:
> 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.

You don't need to *hope*. You could just review your own /etc/init.d
directory for scripts that do nothing nothing but
"start-stop-daemon --stop" or something equal.

looking at mine:

anacron, atd, atftpd, dirmngr, hal, ...


--
"rm -rf" only sounds scary if you don't have backups


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

Hallo Petter,

Petter Reinholdtsen <pere@hungry.com> wrote:
> [Kurt Roeckx]
>> 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.
>
> Historical reasons and because that is what killall5 support, as I
> noticed you discovered shortly after you sent this email.

What about kill -l?

% kill -l SIGCONT
18

>> I think it would be nice that in case it needs to send KILL
>> for debug purpuses it could:
>> - output which processes are still running
>
> Would need a change in the interface and behaviour of killall5, or
> perhaps it is enough to do 'ps -ef' or similar? Not sure if it is
> useful in non-debugging sessions, though.

IMO, yes. Printing the process names should not clutter the screen and
might provide informations to detect problems. It's better to have more
informations than less.

Bye, Jrg.
--
Dadurch, dass man einen anderen ins Irrenhaus sperrt,
beweist man noch nicht seinen eigenen Verstand.


--
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:48 PM.

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