Re: Hylafax+-5.5.9 & blocked queues of the same outbound fax number

On 07/21/2018 06:57 PM, Gregory P. Ennis wrote:
> After 'so many' faxes to the same number hylafax+ stops sending to that
> number.  Other outbound numbers work without a problem, but the fax
> queue with the blocked number remains full of the blocked number.  When
> this happens I have to restart hylafax and the fax queues of the
> blocked fax start again.
>
> It appeared to me that hylafax was recognizing a large queue of the
> same number and interpreted the presence of this large queue as a bad
> fax.  The receiving fax is a busy fax and does have some 'busy'
> problems.

So, to investigate this problem it will be necessary to know the=20
configuration, because various configuration items can have considerable=20
effect on what is going on in the queues - especially when dealing with=20
fax jobs to the same number.

Are you batching or not?=C2=A0 (What is your MaxBatchJobs setting in your=
=20
/var/spool/hylafax/etc/config file?)

What is your MaxConcurrentCalls setting?=C2=A0 (It is also in etc/config.=
)

What is your ShareCallFailures setting?=C2=A0 (Likewise in etc/config.)

Are you using ModemGroup at all, and if so, what is the ModemGroup=20
configuration, and what "modem" is being used in the job submission?

(So, maybe it's best if you just share your etc/config file.)

> I have changed the value of MaxConsecutiveBadCmds:=C2=A0=C2=A060 in
> /etc/hylafax/hfaxd.conf which was originally set to 10.  This appeared
> to help, but did not solve the problem.

Settings in hfaxd.conf affect the client-server communication and do not=20
usually have a role in the faxq operation or fax protocol operation.

In this case, MaxConsecutiveBadCmds influences how tolerant hfaxd is=20
with your client program.=C2=A0 Did you write your own client program or =
are=20
you using sendfax or faxmail as most users (in which case=20
MaxConsecutiveBadCmds will not likely do anything)?

> The number of consecutive
> faxes to the same number has been in the range of 40 to 45.
>
> The /var/messages entries appear to be :
>
> Jul 18 22:58:52 MaBa FaxQueuer[18820]: NOTIFY: bin/notify-smile
> 'sendq/q93617' 'blocked' ''
> Jul 18 22:58:52 MaBa FaxQueuer[18701]: NOTIFY: bin/notify-smile
> 'sendq/q93612' 'requeued' '' '23:03'
> Jul 18 22:58:52 MaBa FaxQueuer[18701]: NOTIFY: bin/notify-smile
> 'sendq/q93613' 'requeued' '' '23:03'
> Jul 18 22:58:52 MaBa FaxQueuer[18701]: NOTIFY: bin/notify-smile
> 'sendq/q93614' 'requeued' ''

This is normal.=C2=A0 What should happen, then, after some time is that i=
t=20
should reattempt those jobs.=C2=A0 It sounds like you're seeing it not do=
=20
that, but rather they stay "blocked" forever or they simply stay stuck=20
and are never reattempted.

Ultimately I may need you to set ServerTracing (in etc/config) to 0xFFF,=20
restart faxq, and then let it run again until a problem happens and then=20
provide me the FaxQueuer entries from your syslog.

And, it would be helpful to know if 'faxalter -p <jobid>' works to get=20
the "stuck" jobs to go out.

Thanks,

Lee.


____________________ HylaFAX(tm) Users Mailing List _____________________=
__
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.c=
gi
 On UNIX: mail -s unsubscribe [email protected] < /dev/nu=
ll
  *To learn about commercial HylaFAX(tm) support, mail [email protected].*