Comment 4 for bug 75058

Revision history for this message
In , Shaul Karl (shaulk) wrote : Re: Bug#235196: A delay of 60 seconds in the stop target of one of non nut init.d script?

On Wed, Mar 03, 2004 at 09:39:01AM +0100, Andreas Barth wrote:
> * Shaul Karl (<email address hidden>) [040303 02:10]:
> > By doing this he prevent faxes from being sent twice while still
> > fulfilling the stop duties in a timely manner.
> >
> > I think that:
> > 1. The delay of 60 seconds in case there are queued faxes is not
> > acceptable when the ups is in LOBATT state.
> > 2. This is a sufficient reason to reject the maintainer way of doing
> > things.
> >
> > As an aside, I believe that with a 14,400 bps, 60 seconds will suffice
> > for faxing at most 1 document.
>
> Please read again your original bug report. You complained that the
> init.d-script sends a wrong signal for stop. I changed that.
>
> Now you come up with a totally different reason, that was not part of
> your original request.
>
>
> So: Please consider what you want, and send me the reasons for that.
> And don't add additional requirements later.
>
>
> Furthermore, if you disagree with my decisions, you might
> - say that to me in private or via the Debian BTS
> - raise the issue on <email address hidden>
> - take that issue to the technical committee
>
> You can of course discuss any issue wherever you like, but words like
> "we can't accept" are not too helpful for changing my mind.
>

  I believe I might have sound impolite or harsh because English is not
my native language. I had no intention to write impolitely or in a harsh
manner. Do try and read everything that I write with that in mind.
Overcoming cultural differences is not an easy matter, in particular
when one doesn't speak natively the language in which he writes.

  The original bug report was about sending USR2 signal in the stop
target of the init.d script. I believe this is wrong because, according
to the way I read faxrunqd man page, USR2 will not stop the process. Am
I right? If I am right then another signal has to be sent. I proposed
TERM, which will stop the mgetty-fax process immediately.
  You want to let it die gracefully because you don't want to interrupt
faxes that are possibly being sent at the time of the signal. In
addition, not interrupting those fax transmissions will avoid duplicate
faxes to be sent. This indeed solves the problem of the wrong signal
that I have raised in my original report. However thinking about your
solution, I believe it has a basic flaw. In fact, I believe it is
something we usually don't pay attention to, although we should. The
flaw that I am referring to is concerned with emergency shutdowns due to
power failures. In fact, I strongly believe that there is a need to
insert a paragraph in debian-policy that delaying the stop action of an
init.d script should be discussed in debian-devel before
carrying it out.
  Yet having a strong opinion about some matter usually worth discussing
about it with others. There fore I raised the issue with the
Uninterrupted Power Supply (UPS) people on <email address hidden>. These
people are using the nut software, which is responsible for shutting
down the machine as cleanly as possible in case of power events. I
merely wanted their opinion about me being right that stop targets
should avoid delays, or not.

  Did I convinced you, Andreas Barth, that I do have a point even though
I was raising it only after seeing your solution to my original report?

--
"If you have an apple and I have an apple and we exchange apples then
you and I will still each have one apple. But if you have an idea and I
have an idea and we exchange these ideas, then each of us will have two
ideas." -- George Bernard Shaw (sent by shaulk @ actcom . net . il)