Re: flexfax: problem with faxgetty + Solaris-2.6 + Magma serial ports

["Thomas A. Szybist" <szybist@boxhill.com>]

In message <199905181522.LAA10055@lucky.misty.com>, "Mark G. Thomas" writes:
> 
> Tom,
> 
> Thanks very much for the info on this.  Yes, I did actually see this once
> with the Sun serial ports, but wrote it off since it was so much less
> frequent then with the Magma ports.
> 
> I know it's a bit of a work-around, but do you think it might be possible 
> to change faxgetty to either check for lock files periodically, or otherwise 
> check the port's state?  I've observed that even after another process 
> has come and gone, the port is stuck with DTR turned off.  Perhaps if 
> faxgetty woke up and noted that the port was in this state or that a lock file
> from something else was in place, it would either have to re-initialize
> things or else wait for the lock file to go away, then re-initialize things?
> This seems like a pretty major shortcoming with faxgetty at this point.
> 
> Mark
> 

Faxgetty does check for lock files, but only if the select() has been
tripped.  When the lock goes away, faxgetty resets everything.
However, if the select() hasn't been tripped, the lock file can come
and go with out faxgetty ever knowing.  I suppose faxgetty could always
look for lock files, but it would have to wakeup very often so as not to
miss it.

At one point I had a cron job kill faxgetty every so often. (inetd
would restart it).  This way I would be assured things we're never
stuck for more and 15 minutes or so.  Not great.

It would seem this is not a great mechanism.  However, Sam said that
select() should work this way.  If not, it's a bug in select()'s
implementation.

Tom