Re: [hylafax-users] Test for Stuck faxgetty

[Dmitry Bely <dbely@mail.ru>]

"Greg Kelley" <gkelley@londavia.com> writes:

> Is there any to test for a stuck faxgetty?
> 
> We are getting (at least once daily) faxes that hang the modems.  Incoming
> calls get a no answer and keep ringing.  faxstat shows both modems
> "Receiving From:".  I have to kill both faxgetty ttyS0 and faxgetty ttyS1
> processes, then run 'setserial /dev/ttyS0' and 'setserial /dev/ttyS1' then
> 'kill -HUP 1' to get both modems reset and answering again.  The second
> modem is getting hung because the originator is trying the second fax number
> because they get no answer on the first.  Looking at the log file for that
> session, during receiving data it gets trashed with garbage - looks like
> actual data that should be going to the tif file!

It would be great to see the logs itself.

*IMHO* it's OS level bug (either glibc or Linux kernel itself). alarm() does
not correctly terminate blocking read(), when the timeout condition
happens. The modem does not feed any data to DTE, (session failed wrong
way), and hylafax sits in the read() syscall forever.

It's also possible to rewrite timeout processing in Hylafax via select(),
not alarm(), but this requires significant amount of work...

Hope to hear from you soon,
Dmitry

P.S. Older Linux (kernel 2.0.38+glibc 2.0) does work for me -- timeouts are
handled properly and I have _never_ seen (except while debugging, when I
tried to implement nested timeouts) a stuck faxgetty in any fax class.




____________________ HylaFAX(tm) Users Mailing List _______________________
 To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null