HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

faxq hanging (aargh!)



Hi

I've setup a fax server for a small office. The server is running RedHat
6.1 with Hylafax 4.0p12 and a USR external 33.6 Sportster Voice Modem.

Initially I had problems where it wouldn't send or receive correctly but
eventually I got a decent config file setup that seemed to be working
correctly for a week or so. I wasn't entirely happy though because the
modem sends out fax beeps when originating a call, but it stops sending
them after a fairly short period (which irritates me because some
combination fax/answering machines will then get confused because the modem
stops beeping before the answering machine gets the opportunity to hear the
beeps and switch to fax mode). BTW- I'm not using the @ symbol in the dial
string because that makes the modem send no beeps at all ever!

I then saw in the mailinglist archives for December that someone posted
their working USR config file, so I thought I'd set mine up as in that
config file (there were only a few differences).

I sent a few short faxes (using whfc) and the first 2 went through fine,
but the 3rd one caused faxq to 'hang' as described in some posts from last
month (where faxq hogs as much CPU time as it can but does nothing).
Nothing I did made any difference. The only way I could even remove the fax
from the queue was to manually delete the queue files, or kill hylafax
(faxq needs to be killed with a -9), lock the serial port with another
program (like minicom), restart hylafax, which then doesn't get into it's
locked state because it can't talk to the modem, and then I can use whfc to
gracefully remove the fax from the queue. But as soon as the serial port is
freed up from the other program, if there's a fax in the queue, faxq hangs.

I've watched the modem lights when I queue up a fax and hylafax doesn't
even try to talk to the modem before it locks up. The modem is still in
exactly the same state it was left in by faxgetty (i.e. TR,CS light on and
ARQ light flashing - indicating it's in class2.0 mode) but faxq has locked
the serial port (in anticipation for opening it I guess, but whether it has
opened it yet or not I don't know). The TR light doesn't at any time
toggle. Even if faxgetty isn't running and I reset the modem manually (so
that it's not it class 2.0 mode and TR isn't on) faxq will still hang when
I queue a fax.

I tried everything I could think of for 3 hours trying to get it to work
but nothing helped. I'm sure it can't be the changes I made to the config
file because it seems that faxq gets stuck before it even tries to talk to
the modem. From reading the posts about recompiling hylafax to change the
way it uses the FIFO's I thought I'd try delete the FIFO files to see what
happens. Then when I started hylafax again it created the 'FIFO' file but
queueing a fax didn't result in the creation of a 'FIFO.ttyS1' file. I
don't know if this should happen or not but that file is only created again
when I start/restart faxgetty (which can successfully talk to the modem, as
can anything else, like minicom).

Eventually I resorted to trying to queue a fax from a different windows
machine. To my amazement it managed to send the fax successfully. But the
second one I tried from that machine caused faxq to hang again. So I tried
yet another machine and it worked first time. (Of course after having
killed the hung faxq and clearing the queue and restarting hylafax). I
found this very puzzling. All the machines are setup identically in whfc
(even using the same username to 'login' to hylafax). So I tried the
orginal machine that I had first encountered the problem from and it then
managed to send two faxes in succession (this was the machine that had
originally queued the first 2 successfully but failed for every single
attempt thereafter). Increadibly frustrated I decided to call it a night
and went home.

Now this morning I get a call from the guy whose office the fax server is
in, saying that someone had tried to send a fax to them and it seemed as
though the modem had hung (it hadn't released the phone line). So I'm
inclined to think the new config could be causing some problems but that
doesn't explain why faxq hangs seemingly before even trying to talk to the
modem, and certainly not why changing to another client machine will kick
it out of it's hanging state (even rebooting the machine doesn't manage to
get it to stop hanging).

The times when I managed to get a fax to send (when trying from a different
machine) I noticed in the message log that FaxQueuer sent messages talking
about the modem (can't remember what it said though), but the times it had
failed it only said something like 'SUBMIT JOB xx' where xx is the JobID,
and it would then hang.

I'm going to go back there today and try to increase the trace level (I
assume that'll make more messages) and change the config back to what it
was and generally do some more testing. I'll make another post later after
I've worked with it some more, then I can try to provide what messages
which processes give etc.

There was one other thing that I noticed that could be contributing. When I
run faxsetup, as part of some of the first stuff it prints it says
something like 'created for i586-inknown-linux'. It's running on a 486, so
I wonder...

I would like to avoid recompiling it because it'll be a headache since the
rpm version uses different directory locations, but if it's been compiled
with 'i586' optimisations then it really should be recompiled for a 486.
But that wouldn't explain why other people have the same problem when they
DO compile it themselves.

<#*$%@>
<sigh>

Sorry for such a long post, but this thing is driving me crazy. PLEASE
anybody, if you have any insight please respond (and CC me any replies
because I'm not on the mailing list.)

Thanks,
/Jerome/





Project hosted by iFAX Solutions