HylaFAX The world's
most advanced open source fax server
Re: [hylafax-users] Seeing a lot of KILL TIME EXPIRED
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. (?)
Adam Engel wrote:
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";
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.
*** 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
____________________ 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*