Re: [hylafax-users] FaxGetty defuncts on sarge/etch

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Erik Enge wrote:

> We are seeing the same thing.  We are running HylaFAX 4.3.0 on RedHat
> 7.3.  During receiving of a fax there will be multiple faxgettys spawned
> and defunc'd.  They do disappear shortly.  However, the original
> faxgetty which reads from ttyS0 stays running the entire time under the
> same PID, though mysteriously (at least to me) changes owner to root and
> then back  to uucp every now and then.
>
> Should I worry about this?  Is there an explanation?

FaxGetty forks a number of times during an average call in order to 1) 
make it possible that blocking calls, like writing to a TIFF file, get 
handled in the background while the foreground process can continue fax 
protocol should the blocking call actually block due to, say a busy hard 
drive, 2) perform protocol flow control if/when needed, and 3) decode 
incoming fax images without interruption in ECM protocol, which gets 
image data in an interrupted fashion.

There's no doubt that this design could be improved.  In my estimation 
each faxgetty could be running two processes, one for the protocol, and 
the other for everything else.  But the current system was easier to 
implement (than trying to make HylaFAX portably multi-threaded) and 
seems to work just fine.

The consequences, however, of the design the way that it is - is 1) pids 
get consumed faster - much faster if you have a lot of active faxgettys, 
and 2) some child processes will, after becoming defunct, necessarily 
wait for a while until faxgetty calls on Dispatcher to clean them up.  I 
don't know that either of these consequences are particularly a bad 
thing.  So there shouldn't be any worries.

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*