HylaFAX The world's
most advanced open source fax server
Re: [hylafax-users] fax completely stuck
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
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.
____________________ 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*