Re: [hylafax-users] Seeing a lot of KILL TIME EXPIRED

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Hi Adam,

Unfortunately, we could only guess here as to what is going wrong.  
While the likelihood is that your HylaFAX version is largely-based on 
open-source HylaFAX and therefore may be something similar to what we 
understand, there is no assurance that we'd be doing you any favors by 
speculating as to whether or not the problems you're experiencing are 
configuration problems or bugs in the software.  With proprietary 
software you almost always have to return to the software provider in 
order to get authoritative support; when contemplating whether or not 
something is a bug access to the source code is really a must.

Your behavior of killing faxq automatically and then restarting it seems 
to be based on a conclusion that you are hitting on a bug.  Per your 
statement, it's being done automatically at night because it's what you 
have to do manually during the day to restore operations.  Allow me to 
suggest that if you are truly dealing with a bug, and if your only real 
course of action is to restart faxq (rather than appealing to the 
software provider), that simply doing it on a clock schedule is 
inadequate.  Instead, you should probably have a small script or 
something that very regularly (like every 5 minutes or less) monitors 
the queue, and if the queue is stalled to then to do what is necessary.  
You're going to be the best-suited to do that scripting, as much of what 
is required is to be able to identify what constitutes a stalled queue.

I am curious, however, as to why you turned for support here rather than 
to the software provider. (?)

Thanks,

Lee.


Adam Engel wrote:
> Hey all,
>
> CentOS release 5.3 (Final)
> hylafax-enterprise-4.1.4-rhel5  ( I realize it's enterprise but 
> figured that this is an issue most likely not related to it )
> Current Kill time - now +6 hour
>
> Recently I have noticed that we are getting A LOT of KILL TIME EXPIRED 
> errors in /var/log/messages.  We send out over 400 pages a day during 
> the week with most of them happening kind of at the same time. We have 
> a job that will query a database to see what it needs to send out and 
> then will send the faxes.
>
> Part of me thinks that faxq is having issues and dies so I set up a 
> script to run every night at 1am to stop hylafax, 'killall faxq', then 
> start hylafax in hopes that this resolves the issue. I think that this 
> is the issue because when I am informed that "faxes don't seem to be 
> going out", I will look at 'faxstat -s' and see hundreds of faxes in 
> the queue prompting me to stop hylafax, kill faxq and then restart it.
>
> I have a Brooktrout card with 12 channels dedicated to outbound faxing 
> so I doubt I am sending too many faxes at once.
>
> Our FaxNotify script has been edited so that it uses custom in-house 
> scripts to change the status of the fax in our database. I added a 
> line for time outs, but does a timedout fax even go through etc/FaxNotify?
>
>     echo "$failedline" | grep -i "timedout" > /dev/null 2>&1
>      if [ $? -eq 0 ] ; then
>       substatus="Killtime was met";
>      fi;
>
> If hylafax attempts to send a fax and it fails, does it go to the end 
> of the queue or does it hold up the batch until it's killtime has expired?
>
> Do you guys have any suggestions on what I can do to resolve the KILL 
> TIME EXPIRED errors?  I have a Nagios server and am in the process of 
> setting up the queue monitoring so that I can monitor the queue for 
> when it gets out of hand during these times.
>
> Thanks,
> Adam
>
>
> *** Confidential ***
> This message and any files transmitted with it may contain information that is privileged, 
> confidential, and exempt from disclosure under applicable law.  They are intended solely for 
> the use of the intended recipient.  If you are the not the intended recipient, distributing, 
> copying, disclosing, or reliance on the contents of this communication is strictly prohibited.
>
> If this has reached you in error, kindly destroy this message and notify the sender immediately. 
> Thank you for your assistance.
>
> Loan Protector attempts to sweep harmful content (e.g., viruses) from e-mail and attachments, 
> however we cannot guarantee their safety and can accept no liability for any resulting damage.  
> The recipient is responsible to verify the safety of this message and any attachments before 
> accepting them.
>   


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