Re: flexfax: Okay, so it was a FAQ...

[Steve Williams <steve@genie96.com>]

> 
> 	In my earlier post, I asked about making HylaFax work with tip. 
> Afterwards, I consulted the FAQ and came away feeling much embarrassed, 
> but not at all enlightened.
> 
> 	Once again: server is OSF 4.0, Hylafax 4.0pl1.
> 
> Quoting from the FAQ:
> 
> >...First verify that your data communication software is configured to use 
> >the correct modem initialization strings
> 	They do. 
> 
> > and that both HylaFAX
> > and the program(s) in question are using the same device name.
> 	They are.
> 
> 	To clarify, tip works. Tip works very well. So does HylaFax. My 
> problem, specifically, is that getty recognizes the lock file and obeys 
> it... for about 30 seconds. Then, as the modem is in the midst of 
> dialing, getty calmly declares the UUCP lock file 'stale' and blows it away,
> grabbing control of the modem back from 'tip'. And I cannot for the life of
> me find the place in the config files where that 30-second default resides...
> 

Hi,

Just so you understand the UUCP locking mechanism a bit better...

The UUCP Lockfile contains the Process ID of the process that contains the
lockfile.

There are two formats for lockfiles.
	- Binary Lockfiles, where the PID is stored in a binary format
	- Ascii Lockfiles, where the PID is stored in an ascii format,
	  human readable form.

Before ANY program nukes the lockfile, the program checks to see if the
Process still exists.  If the process still exists, the Lockfile is considered
valid, and NOT removed.  The process is checked for existance by using the 
"kill 0" signal on the PID.  This even works from the shell.

It is critical that two criteria are met for the locking to work properly.
	- All programs on a system accessing the modem MUST use the same format
	  of UUCP Lockfile.  ( Binary OR Ascii )

	- All programs on a system accessing the modem MUST be looking for the
	  lockfile in the same location ( directory ).

To diagnose the problem, try..

1.  Send a ( longish ) fax.  Once it is transmitting, do a "uustat -p"
    This should show some "fax" process that has the port.  If not, then
    HylaFAX is not using the same directory as your system's UUCP is expecting.
    OR HylaFAX is writing the wrong format lock file.

2.  While the fax is being sent, change into the UUCP lock directory.  It 
    could be /etc/locks, or /usr/lib/uucp, ..., and look for a file with the
    name LCK..[tty_name].

3.  "cat" this file.  If you can read it, you should see the process id of
    the sending fax program.  If you cannot read it ( or get garbage ), then
    HylaFAX is set to use binary lock files.  This is OK if the uustat -p
    showed the sending fax process, because your system uses binary lockfiles.

4.  Wait for the fax to finish.

5.  "tip" to the port.

6.  From another terminal ( or shell out, or whatever, but do it within 30 
    seconds <g> ), do a uustat -p.  If that shows "tip" as having the port,
    then I am really confused.  If it doesn't, then "tip" is either putting
    the lockfile in a different directory than is expected, OR it is using
    the wrong format lockfile.

7.  Change directory into the lock directory, and "cat" the lockfile to 
    determine what format of lockfile "tip" is writing.

Figure it out from there....,

I would suspect that HylaFAX is compiled up to use the wrong format lockfile
for your system.

Good Luck,
-- 
	Steve Williams, Calgary, Alberta, Canada
	Genie Computer Systems Inc.
	steve@genie96.com