HylaFAX The world's most advanced open source fax server

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

Locking problem on FreeBSD?



Hi all,

Could somebody please help me, I'm absolutely stumped on this one even
after reading the FAQs and docs.

I'm setting up HylaFax 4.0 pl2 on a FreeBSD 2.2.7 server, and I'm having
problems using faxgetty with user ppp (aka iijppp), as opposed to kernel
based ppp.  I'm running a single generic 33.6k internal fax modem
attached to COM2 (/dev/cuaa1).

The system works great.  Faxgetty answers calls when its supposed to,
queues are sharing perfectly with my NT box across samba, and whfc is
taking care of fax transmissions from Word and the like wonderfully.

The only problem comes when I try to dial into my office (or any other
ISP) via PPP.  As soon as ppp picks up the modem and starts dialing out,
faxgetty picks up the link and from what I can see starts attempting to
answer an incoming call!  I've established this by the fact that when
faxgetty is running and I attempt to dial out with PPP I can't get a
carrier and the modem transmits a slow beep sound every two or so
seconds which sounds like a fax waiting for a carrier.  When I kill -9
the ppp process the modem stays online emitting the beep until it times
out.  When I remove the faxgetty line for cuaa1 in /etc/ttys, reboot the
machine and try again, everything works fine.

>From what I understand, faxgetty and ppp both make use of standard uucp
ascii-style locking.  That is, when either program accesses the modem, a
file /var/spool/lock/LCK..cuaa1 is created with permissions 644.  

I ran two tests:  1. If I have hylafax pick up the line (using
faxanswer), I see that the file is created correctly and when I then try
to run ppp it reports that the device is locked and does not touch the
modem.  2. When I run ppp however the lock file is still created but
faxgetty appears to ignore it and starts interacting with the modem
anyway.  I checked the PIDs set in the lock file in both tests.  In test
1, the pid corresponded to the faxanswer process I'd just started.  In
test 2 the PID corresponded with that of ppp, so everything seems fine
there.

The best guess that I can come up with is that when PPP accesses the
line it touches it prior to implementing the lock file, whereupon
faxgetty detects some sort of activity on the port and picks up at the
same moment that ppp picks up and then sets the lock file - a sort of
race condition if you will.  Of course I could be completely off track
here.

Can anybody give me some advice as to what is causing the problems
describe above, or even better, how to rectify them?

Much appreciated in advance,
D.

---

Dan Makovec, BCompInfSc
Senior Systems Analyst
I-NeX Corporation Pty. Ltd.

> Level 6, 45 King William Street, Adelaide.
> GPO Box I-NeX, Adelaide, South Australia 5001.
> Ph: (08) 8410 6160, Fax: (08) 8410 6164, ICQ: 1398090




Project hosted by iFAX Solutions