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 b
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 s
* 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/databas
* Felipe Sateler
| If there are daemons which don't need to save state, or do useful work on
| shutdown (and thus don't need an init script)... why bother with TERMing them
| instead of directly KILLing them?
As an example, an ftpd or smtpd could then close the connection with
«service going dow
[Felipe Sateler]
> If there are daemons which don't need to save state, or do useful
> work on shutdown (and thus don't need an init script)... why bother
> with TERMing them instead of directly KILLing them?
Mostly to keep the complexity of sendsigs down. But I agree with your
logic, that eithe
Petter Reinholdtsen wrote:
> 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 i
[Jörg Sommer]
> Hallo Petter,
Hi.
> What about kill -l?
>
> % kill -l SIGCONT
> 18
Hm, interesting idea. I guess killall5 $(kill -l SIGCOUNT) would
work.
> IMO, yes. Printing the process names should not clutter the screen
> and might provide informations to detect problems. It's better to
>
Hallo Petter,
Petter Reinholdtsen <[EMAIL PROTECTED]> 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 t
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*
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,
On 04-Jan-08, 11:36 (CST), Simon Richter <[EMAIL PROTECTED]> 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 fo
[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
[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 shu
"Petter Reinholdtsen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[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 seq
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 w
Le vendredi 04 janvier 2008 à 18:36 +0100, Simon Richter a écrit :
> 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
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, wh
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
> >
[[ 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
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 a
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 i
[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 aft
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
> > # valu
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 t
[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 shu
On Thu, Jan 03, 2008 at 09:24:59PM +0100, Petter Reinholdtsen wrote:
> 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 with
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
>
Quoting Steve Langasek ([EMAIL PROTECTED]):
> 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,
^
[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
[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
On Thu, Jan 03, 2008 at 12:14:15PM -0500, Joey Hess wrote:
> If a package only shuts down cleanly because the rest of the shutdown
> process is slow, it is already buggy. Especially on systems where the
> shutdown is much faster, either due to their being fewer shutdown
> scripts than usual or the
"Petter Reinholdtsen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[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 d
[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 as
On Thu, Jan 03, 2008 at 01:11:57PM +0100, Gabor Gombas wrote:
> On Thu, Jan 03, 2008 at 02:45:40AM +, Colin Watson wrote:
> > 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 candida
Gabor Gombas wrote:
> IMHO there can be many init scripts that currently do not wait for the
> process to stop but they should if you want to do this refactoring. Some
> random checks:
If a package only shuts down cleanly because the rest of the shutdown
process is slow, it is already buggy. Espec
On Thu, Jan 03, 2008 at 02:45:40AM +, Colin Watson wrote:
> 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.
IMHO there can be many init scripts that cur
On Wed, Jan 02, 2008 at 10:31:33PM +, Roger Leigh wrote:
> Felipe Sateler <[EMAIL PROTECTED]> 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
On Wed, Jan 02, 2008 at 12:47:12PM -0800, Russ Allbery wrote:
> 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.
S
Felipe Sateler <[EMAIL PROTECTED]> 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
>
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 sc
Colin Watson <[EMAIL PROTECTED]> 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 Ubu
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 <[EMAIL PROTECTED]> writes:
> > > On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote:
> > >> Some packages actually do need to shut down cleanly; in the cas
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 g
On Wed, 2008-01-02 at 09:50 -0800, Russ Allbery wrote:
> Robert Collins <[EMAIL PROTECTED]> writes:
> > On Wed, 2008-01-02 at 00:29 +, 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 lo
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
> Robert Collins <[EMAIL PROTECTED]> writes:
> > On Wed, 2008-01-02 at 00:29 +, 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(*),
Robert Collins <[EMAIL PROTECTED]> writes:
> On Wed, 2008-01-02 at 00:29 +, 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 database
On Wed, Jan 02, 2008 at 09:47:20PM +1100, Robert Collins wrote:
> On Wed, 2008-01-02 at 00:29 +, 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 powe
On Wed, 2008-01-02 at 00:29 +, 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 'defaul
[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
othe
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 b
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 sec
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
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 st
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> 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 in
[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 be
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
[Joey Hess]
> 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.
I have not invested much time to implement that extension, as it would
have to be first specified in the update-rc.
[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
[Russ Allbery]
> Shouldn't we add a move option to update-rc.d first rather than
> telling people to do this? It seems like a generally useful thing
> to have, and I don't like the idea of throwing away people's init
> script order customizations.
Well, I am not quite sure how it should work, bu
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [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' opt
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 upda
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 to
[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 oth
Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
[...]
> To change the runlevel settings of an init.d script using the Debian
> API, one most first remove it in the postinst, and insert it again.
> To do this, add code like this in the postinst before the #DEBHELPER#
> block:
> if dpkg --compare-ve
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 shutd
66 matches
Mail list logo
