Re: [hylafax-users] fax completely stuck

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

On 2005.02.03 15:10 Christian Schnobrich wrote:

> Not recovering from a transfer error might justify a bug report.

Aye.  However, it's complicated due to the way that HylaFAX works.  
faxsend is stuck sending the fax.  And it's really stuck, waiting for a 
write() to return, which never will, because it's blocked.  So faxsend 
cannot recover from the problem itself, alone.

In a better-designed faxsend there would be two permanent faxsend 
processes.  The parent would do flow-control things and supervising of 
the child process, and it could monitor for when a write() or read() 
call gets blocked, and then kill the child when stuck.  We already fork 
to do flow-control things, but it's a temporary fork, and we certainly 
wouldn't want to fork before each and every write() or read().  So, 
until faxsend gets redesigned faxsend cannot recover from the problem 
alone.

Now, there's faxq, but faxq doesn't really know what's going on with 
faxsend; faxsend and faxq do not communicate except at the faxsend 
startup and the exit status.  In-between there's no communication.  I 
guess that faxq would have a pretty good idea that faxsend were stuck 
if faxsend were running for a long, long time.  The problem would be in 
defining "how long does it have to wait before it can say with 
certainty that faxsend is stuck".  I've seen some faxes go for nearly 
an hour, without an error.  So I'm reluctant to say that faxq has 
enough information to know what's going on.

Us humans, well, we see that it's not progressing, we look at the log, 
see that it's stuck, and then kill faxsend.  I guess that you could 
create a cron job that did this for you.

Lee.

____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*