Re: flexfax: aborting faxes

[Matthias.Apitz@SOFTCON.de]

Yves Trudeau wrote:
    
    Nico Garcia wrote:
    > 
    > -----BEGIN PGP SIGNED MESSAGE-----
    > 
    > On Wed, 12 Nov 1997, Luiz Otavio L. Zorzella wrote:
    > 
    > > Hi,
    > >
    > > I'm trying to share my modem between hylafax and my pppd.
    > >
    > > I'm being able to do it using the "faxstate" command: I issue a
    > > "faxstate -s busy" before I call pppd, so that hylafax won't mess with
    > > my connection, and a "faxstate -s ready" after the pppd goes down, so
    > > that the waiting faxes will be sent.
    > >
    > > My problem is that I'm trying to make this thing automatic (putting
    > > this commands in my scripts), but I'm having problems when the pppd
    > > trys to "go up", and hylafax is using the modem.
    > 
    > This should be unnecessary. HylaFAX and uucp and kermit and tip and
    > minicom and pppd should all be looking in the same directory for the
    > same style of lock files: this is /var/lock on Linux, /var/spool/locks
    > on SunOS, etc.
    > 
    > Try running each program and seeing where and what kind of lock file it
    > generates: these really should interoperate.
    > 
    >                         Nico Garcia
    
    I have a similar problem to. I use v4.0pl1 on Linux 2.0.29. Everythings
    works fine when hylafax is idle but if there is jobs in the sendq it's a
    different story.

What's the story? If there are jobs in the sendq faxq(1M) will
process them if the modem is free. If the modem is free or not
will be detected by lock-files. The consequence of this it that
all software tools sharing the modem *must* use the same
locking style (e.g. the same filename and the same format
of information in this file). Filenames are usually derived from
information about the device (e.g. major and minor number
of the modem dev) or from the name of the device itself. If you
use different drivers (using different major/minor numbers) for
the same physical device or use different device names it will
cause problems. This logic is simple and clear.
Just watch with the ls(1) and cat(1) or hd(1)
command which lock-file HylaFAX's daemons are using (just call
the line from a telephone while faxgetty(1M) is answering and
go to the lock directory and use ls(1)) and also watch which
lock-file your other software is using.

    I tried "faxstate cua1 -s down", "TimeOfDay:  
    0500-0530" in config.cua1 (I need the modem between 5:00 and 5:00 AM)

TimeOfDay: belongs to the server config file config(4F) and not
to the modem config file. The timerange you set is the time
frame for sending outbound jobs. If you don't like outbound
traffic from 5 AM to 5:30 AM you have to set 0530-0500.
Check the man page for more details.

Normally faxstate(1M) sends the message to the faxgetty(1M)
process.  If there is no faxgetty(1M) running you have to use
the flag "-n" to send the message directly to the faxq(1M).

    and faxquit with no success. If faxgetty is no running on cua1, faxq
    will in fact exit after the "faxquit" command... only after all the jobs
    in sendq are done. We do a lot of broadcast faxing so there is always
    jobs in sendq. I have already hack faxq in order to make it generate a
    "faxq.pid" files which a can use to kill it but this means that the
    current jobs will not be notified. Any input is greatly welcomed.

faxquit(1M) should quit faxq(1M). The stop isn't immediately if
there are active jobs (e.g. jobs for which faxq(1M) has spawned a
child proc like faxsend(1M) or imaging). I've just tested it:

# bin/faxstat -s
HylaFAX scheduler on thias: Running
Modem ttyFN01 (+49.89.xxxxxxxx): Waiting for login session to terminate

JID  Pri S  Owner Number       Pages Dials     TTS Status
32   127 W   guru 12345678      0:0   0:12         
# sbin/faxquit
# bin/faxstat -s
HylaFAX scheduler on thias: Not running
Modem ttyFN01 (+49.89.xxxxxxxx): Waiting for login session to terminate

JID  Pri S  Owner Number       Pages Dials     TTS Status
32   127 W   guru 12345678      0:0   0:12         
#

	matthias