HylaFAX The world's most advanced open source fax server

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

Re: about faxstate and faxrm



In message <19990302094545.BYPG24014.fep04-svc@[212.216.109.52]>, Giulio Orsero
 writes:
>>
>>With no faxgetty? *bzzzzt* From faxstate(8c):
>>
>>DESCRIPTION
>>       faxstate  sends a message to the HylaFAX faxgetty(8C) pro-
>>      cess servicing modem telling it to use the specified state
>>       when notifying the HylaFAX scheduler that a modem is ready
>>      and available for use.  This  is  useful  for  controlling
>>       outbound  use  of  a  modem; by marking a modem's state as
>>       busy or down the HylaFAX scheduler  will  not  assign  any
>>       outbound jobs to the modem.
>
>... Why don't you continue?  :-))
>
>From faxstate(8c):
>....
>       If the -n option, faxstate emulates  what  faxgetty  would
>       do; sending a message directly to the faxq process marking
>       the specified modem down, busy, or ready.  This  interface
>       is  useful  for  send-only  environments in which faxgetty
>       processes are not used.  Note that modems  manipulated  in
>       this  way  must  previously  have been configured with the
>       faxmodem(8C) program.
>.....


Yes, you're right, sorry for missing that. I did not read far enough. My 
mistake, your invocation of faxstate with -n should be fine.


>I have one more problem now, so that the questions about faxstate are 2:
>1) How do I poll the state of the modem after having issued faxstate.

Without running faxgetty, I don't know. Is there a specific reason you cannot 
run faxgetty? It's the recommended configuration . . .

>2) If I issue "faxstate -s busy" when there are no faxes in the spool, the nex
>t faxes are
>blocked; if I issue "faxstate -s busy" when there are faxes in the spool, faxq
> finishes to
>send all those faxes before marking the modem as busy.

I have noticed this as well, even when using faxgetty. Jobs assigned to a
modem seem to complete before the modem is "busy-ed" and goes idle. This does
not seem to be "ideal" behaviour . . . . similar to the LONG delay one might
experience after issuing a `faxquit` before faxq actually exits.

-Darren






Project hosted by iFAX Solutions