faxrunqd hangs on /etc/init.d/mgetty-fax stop

[Christian Brandt]

Binary package hint: mgetty-fax

faxrunqd hangs on "/etc/init.d/mgetty-fax stop" until the 60 second timeout is reached, most likely the line "--retry -HUP/60/-TERM" is the culprit.

Most likely this is due a change in the handling of SIGHUP (see changes.debian.gz), this signal now does a graceful restart.

By changing the line to "--retry -INT/5/-TERM" faxrunqd shuts down much nicer - obviously faxrunqd already has special handling to SIGINT so this is isn't as brutish as it looks on first sight. Also I lowered the timeout because the fax will get resend after next start of faxrunqd anyway.

I did some guesses about behaviour of faxrunqd because it is a bit late and the fix seems smart enough. Hopefully they are educated guesses, please doublecheck.

[Andreas Barth (aba)]

tags 235196 +pending
thanks

* Shaul Karl (<email address hidden>) [040227 22:25]:
> SIGINT
> SIGTERM
> remove lock file, remove pid file, terminate immediately.
> SIGHUP
> finish all fax jobs that are currently being sent, then termi-
> nate (this is used to signal faxrunqd "I want you to terminate"
> without disturbing the normal flow of operation - SIGINT/TERM
> etc. can lead to some faxes being sent twice).

> echo -n "Stopping $DESC: $NAME."
> [ -f /var/run/mgetty-fax/$NAME.pid ] && echo || echo " (not running)"
> start-stop-daemon --stop --quiet --pidfile /var/run/mgetty-fax/$NAME.pid \
> - --oknodo --name $NAME --signal USR2
> + --oknodo --name $NAME --signal TERM

I did a HUP here, as a graceful stopping is always better, and I added
a --retry -HUP/60/-TERM, so that after 60 seconds, faxrund is stopped
the hard way.

I commited this change to cvs, so it'll be included in the next
upload.

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Shaul Karl (shaulk)]

  The following doesn't concern the nut directly. I do post it here
because it is about the general way of shutting down a machine.

  The Debian maintainer of the mgetty-fax package propose the following
method to stop the mgetty-fax process in the stop target of the init.d
script[1]:

    1. Let the process send the queued faxes, provided it will not take
       more then 60 seconds.
    2. If the process still has not terminated after 60 seconds, kill it
       brutally.

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.

  Any comments?

In addition, should we recommend the Debian people to put a warning for
their start-stop-daemon program so that maintainers will use the ability
to delay the stop target of their init.d scripts sparingly?

[1] http://bugs.debian.org/235196

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

[Andreas Barth (aba)]

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

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Shaul Karl (shaulk)]

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

[Andreas Barth (aba)]

Hi,

* Shaul Karl (<email address hidden>) [040303 12:10]:
> 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.

I discussed that change before in #debian-devel on IRC, and all others
said that delaying is the proper solution. However, as I see your
points as valid, it might be really the best to discuss that issue in
general on debian-devel to find the proper way to solve that, not only
for mgetty-fax, but also for similar applications.

Cheers,
Andi
--
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C

[Shaul Karl (shaulk)]

On Wed, Mar 03, 2004 at 12:59:56PM +0100, Andreas Barth wrote:
>
> I discussed that change before in #debian-devel on IRC, and all others
> said that delaying is the proper solution. However, as I see your
> points as valid, it might be really the best to discuss that issue in
> general on debian-devel to find the proper way to solve that, not only
> for mgetty-fax, but also for similar applications.
>

  For future reference, the thread in debian-devel is
http://lists.debian.org/debian-devel/2004/debian-devel-200403/threads.html#00331

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

[Andreas Barth (aba)]

Source: mgetty
Source-Version: 1.1.30-9

We believe that the bug you reported is fixed in the latest version of
mgetty, which is due to be installed in the Debian FTP archive:

mgetty-docs_1.1.30-9_all.deb
  to pool/main/m/mgetty/mgetty-docs_1.1.30-9_all.deb
mgetty-fax_1.1.30-9_i386.deb
  to pool/main/m/mgetty/mgetty-fax_1.1.30-9_i386.deb
mgetty-pvftools_1.1.30-9_i386.deb
  to pool/main/m/mgetty/mgetty-pvftools_1.1.30-9_i386.deb
mgetty-viewfax_1.1.30-9_i386.deb
  to pool/main/m/mgetty/mgetty-viewfax_1.1.30-9_i386.deb
mgetty-voice_1.1.30-9_i386.deb
  to pool/main/m/mgetty/mgetty-voice_1.1.30-9_i386.deb
mgetty_1.1.30-9.diff.gz
  to pool/main/m/mgetty/mgetty_1.1.30-9.diff.gz
mgetty_1.1.30-9.dsc
  to pool/main/m/mgetty/mgetty_1.1.30-9.dsc
mgetty_1.1.30-9_i386.deb
  to pool/main/m/mgetty/mgetty_1.1.30-9_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andreas Barth <email address hidden> (supplier of updated mgetty package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 9 Apr 2004 20:28:26 +0200
Source: mgetty
Binary: mgetty-voice mgetty-docs mgetty-fax mgetty-pvftools mgetty-viewfax mgetty
Architecture: source i386 all
Version: 1.1.30-9
Distribution: unstable
Urgency: low
Maintainer: Andreas Barth <email address hidden>
Changed-By: Andreas Barth <email address hidden>
Description:
 mgetty - Smart Modem getty replacement
 mgetty-docs - Documentation Package for mgetty
 mgetty-fax - Faxing tools for mgetty
 mgetty-pvftools - Programs for listening and manipulating pvf and rmd files
 mgetty-viewfax - Program for displaying Group-3 Fax files under X
 mgetty-voice - Voicemail handler for mgetty
Closes: 200418 235196 235813
Changes:
 mgetty (1.1.30-9) unstable; urgency=low
 .
   * use appropriate sigs in /etc/init.d; this could also mean a delay
     at shutdown of the system. Closes: #235196
   * Using gettext-based debconf templates in the woody-compatible way.
     Closes: #235813
   * provide man pages for vm and newslock (and move newslock to -fax).
     Closes: #200418
   * use dpatch instead of classic patch files
   * bump version to 3.6.1.0 (no changes needed)
Files:
 68e209c52892fcb1cd084e482107d235 759 comm extra mgetty_1.1.30-9.dsc
 accee5f9b8ac77553f2a6ee0ac8319ed 67605 comm extra mgetty_1.1.30-9.diff.gz
 bcf48783382fee6b22603f6eee7da4cb 500558 comm extra mgetty-docs_1.1.30-9_all.deb
 02aed835fcdea9e0c64fd7de474f8f2b 166680 comm extra mgetty_1.1.30-9_i386.deb
 b588d88131ecf69e6e47c987eae4747f 57796 comm extra mgetty-viewfax_1.1.30-9_i386.deb
 f8519e87626df9b661be47f94bdbd942 172120 comm extra mgetty-voice_1.1.30-9_i386.deb
 277dee7441737e14a871f26a6e155abb 223572 comm extra mgetty-pvftools_1.1.30-9_i386.deb
 689ca92edcce850b35417a840d4b3a78 131784 ...

[Christian Brandt (brandtc)]

Binary package hint: mgetty-fax

faxrunqd hangs on "/etc/init.d/mgetty-fax stop" until the 60 second timeout is reached, most likely the line "--retry -HUP/60/-TERM" is the culprit.

Most likely this is due a change in the handling of SIGHUP (see changes.debian.gz), this signal now does a graceful restart.

By changing the line to "--retry -INT/5/-TERM" faxrunqd shuts down much nicer - obviously faxrunqd already has special handling to SIGINT so this is isn't as brutish as it looks on first sight. Also I lowered the timeout because the fax will get resend after next start of faxrunqd anyway.

I did some guesses about behaviour of faxrunqd because it is a bit late and the fix seems smart enough. Hopefully they are educated guesses, please doublecheck.