[prev in list] [next in list] [prev in thread] [next in thread]
List: hylafax
Subject: Re: State UUCP lock ...
From: Alex Ongena <ao () able ! be>
Date: 1996-07-30 22:45:07
[Download RAW message or body]
On Mon, 29 Jul 1996, Sam Leffler wrote:
> To: flexfax@sgi.com
> Subject: State UUCP lock ...
> Date: Mon, 29 Jul 1996 18:32:42 +0200
> From: Alex Ongena <ao@able.be>
>
> Hi,
>
> I was just a witnes of something strange happening with the Hyla-
> fax system. As usual, when something strange happens, the logging
> level is low, but maybe somebody very experienced with the code
> can figure out what happened.
>
> Environment:
> Linux 2.0.7, 1 Tornado modem, ...
> V 4.0 beta 18
> ghostscript 4.01
>
> What I noticed:
> - I send a FAX using sendfax (to another computer in house
> where Winfax Pro 7.0 is installed)
> - Hylafax tried but during transmission there was an error
> (something that there was no EOP from the receiver)
> - After a while Hylafax tried again and the same error occured.
> (BTW never use Winfax Pro 7.0, it fails often without reason)
> - and a third attempt ...
> - Then a fax arrived, receiving procedure started normal but
> suddenly, without any reason, it was stopped.
> - After a while, the other FAX tried again and everything was
> fine.
>
> I phoned the company that was sending the FAX and they got a
> 'page sent fault' on there first attempt.
>
> In the log attached below you can see the reason why Hylafax cut receiving
> the FAX, but:
>
> 1) Why was the UUCP lock file there? I do not use UUCP and it is even not
> installed. So the LOCK must come from Hylafax, I guess from sendfax
> when the transmission has failed.
>
> UUCP lock files are created by the HylaFAX server processes so that
> unrelated outbound applications such as cu and uucp do not collide
> with a HylaFAX server process while it is actively using the modem.
> Look at the HTML documentation for more info.
>
> 2) Why does Hylafax start answering first and notice afterwards that the
> LOCK is there ? This does't seem to be logical.
>
> It appears that faxgetty terminated prematurely leaving the lock file in
> place. The new faxgetty process that was started by init recognized the
> lock file was stale (i.e. that the owner did not exist) and removed the
> lock file.
>
> Any hints ?
>
> <...log deleted...>
>
> You don't show the session log for the receive but I just fixed a problem
> that is probably the cause. If you look at the bottom of the receive session
> log and find a fairly long text message indicating the reason the receive
> failed then faxgetty dumped core because it overwrote a static buffer that
> holds a FIFO message that is sent to faxq. A fix for this bug will appear
> in the next distribution.
>
For your help, here is the session log of the fax that was transmitted
to the other computer. This session occured 3 times.
I hope that this confirms your above statement.
Alex
---
Report failed calls and associated session logs:
To: nobody@asterix.a Date: 07/29/96 15:52
Error: No response to EOP repeated 3 times
---- Transcript of session follows ----
Jul 29 15:52:28.48: [ 3816]: SESSION BEGIN 00000068 3216483
Jul 29 15:52:28.48: [ 3816]: DELAY 2600 ms
Jul 29 15:52:31.09: [ 3816]: <-- [15:ATE0V1Q0S0=0H0\r]
Jul 29 15:52:31.85: [ 3816]: --> [14:ATE0V1Q0S0=0H0]
Jul 29 15:52:31.85: [ 3816]: --> [2:OK]
Jul 29 15:52:31.85: [ 3816]: <-- [21:ATS8=2S7=60\Q3&D3&C1\r]
Jul 29 15:52:31.96: [ 3816]: --> [2:OK]
Jul 29 15:52:31.96: [ 3816]: <-- [12:AT+FCLASS=2\r]
Jul 29 15:52:32.07: [ 3816]: --> [2:OK]
Jul 29 15:52:32.07: [ 3816]: <-- [3:AT\r]
Jul 29 15:52:32.08: [ 3816]: --> [2:OK]
Jul 29 15:52:32.08: [ 3816]: <-- [10:AT+FBOR=0\r]
Jul 29 15:52:32.09: [ 3816]: --> [2:OK]
Jul 29 15:52:32.09: [ 3816]: <-- [3:AT\r]
Jul 29 15:52:32.10: [ 3816]: --> [2:OK]
Jul 29 15:52:32.10: [ 3816]: <-- [24:AT+FDCC=1,5,2,2,0,0,0,0\r]
Jul 29 15:52:32.11: [ 3816]: --> [2:OK]
Jul 29 15:52:32.11: [ 3816]: <-- [5:ATM0\r]
Jul 29 15:52:32.12: [ 3816]: --> [2:OK]
Jul 29 15:52:32.40: [ 3816]: <-- [12:AT+FCLASS=2\r]
Jul 29 15:52:32.51: [ 3816]: --> [2:OK]
Jul 29 15:52:32.51: [ 3816]: <-- [3:AT\r]
Jul 29 15:52:32.62: [ 3816]: --> [2:OK]
Jul 29 15:52:32.62: [ 3816]: <-- [10:AT+FBOR=0\r]
Jul 29 15:52:32.73: [ 3816]: --> [2:OK]
Jul 29 15:52:32.73: [ 3816]: <-- [3:AT\r]
Jul 29 15:52:32.84: [ 3816]: --> [2:OK]
Jul 29 15:52:32.84: [ 3816]: <-- [24:AT+FDCC=1,5,2,2,0,0,0,0\r]
Jul 29 15:52:32.95: [ 3816]: --> [2:OK]
Jul 29 15:52:32.95: [ 3816]: <-- [18:AT+FLID="Able NV"\r]
Jul 29 15:52:33.06: [ 3816]: --> [2:OK]
Jul 29 15:52:33.15: [ 3816]: DIAL 483
Jul 29 15:52:33.15: [ 3816]: <-- [8:ATDT483\r]
Jul 29 15:52:47.86: [ 3816]: --> [5:+FCON]
Jul 29 15:52:49.91: [ 3816]: --> [29:+FCSI: "ABLE_NV "]
Jul 29 15:52:49.91: [ 3816]: REMOTE CSI "ABLE_NV"
Jul 29 15:52:49.91: [ 3816]: --> [22:+FDIS: 0,3,0,2,0,0,0,5]
Jul 29 15:52:49.91: [ 3816]: --> [2:OK]
Jul 29 15:52:49.91: [ 3816]: REMOTE best rate 9600 bit/s
Jul 29 15:52:49.92: [ 3816]: REMOTE max page width 1728 pixels in 215 mm
Jul 29 15:52:49.92: [ 3816]: REMOTE max unlimited page length
Jul 29 15:52:49.92: [ 3816]: REMOTE best vres 3.85 line/mm
Jul 29 15:52:49.92: [ 3816]: REMOTE best format 1-D MR
Jul 29 15:52:49.92: [ 3816]: REMOTE best 20 ms/scanline
Jul 29 15:52:49.92: [ 3816]: USE 9600 bit/s
Jul 29 15:52:49.92: [ 3816]: USE 20 ms/scanline
Jul 29 15:52:49.92: [ 3816]: SEND file "docq/doc25.ps;00"
Jul 29 15:52:50.09: [ 3816]: USE page width 1728 pixels in 215 mm
Jul 29 15:52:50.09: [ 3816]: USE unlimited page length
Jul 29 15:52:50.09: [ 3816]: USE 3.85 line/mm
Jul 29 15:52:50.09: [ 3816]: USE 1-D MR
Jul 29 15:52:50.10: [ 3816]: <-- [24:AT+FDIS=0,3,0,2,0,0,0,5\r]
Jul 29 15:52:50.21: [ 3816]: --> [2:OK]
Jul 29 15:52:50.21: [ 3816]: <-- [7:AT+FDT\r]
Jul 29 15:52:56.16: [ 3816]: --> [22:+FDCS: 0,3,0,2,0,0,0,5]
Jul 29 15:52:56.65: [ 3816]: --> [7:CONNECT]
Jul 29 15:52:56.70: [ 3816]: SEND wait for XON
Jul 29 15:52:56.70: [ 3816]: --> [1:]
Jul 29 15:52:56.70: [ 3816]: SEND begin page
Jul 29 15:53:08.78: [ 3816]: SENT 18284 bytes of data
Jul 29 15:53:08.78: [ 3816]: SEND end page
Jul 29 15:53:12.16: [ 3816]: --> [26:]
Jul 29 15:53:12.16: [ 3816]: --> [2:OK]
Jul 29 15:53:12.16: [ 3816]: SEND send EOP (no more pages or documents)
Jul 29 15:53:12.16: [ 3816]: <-- [9:AT+FET=2\r]
Jul 29 15:53:30.35: [ 3816]: --> [9:+FHNG: 54]
Jul 29 15:53:30.35: [ 3816]: REMOTE HANGUP: No response to EOP repeated 3 times (code 54)
Jul 29 15:53:30.35: [ 3816]: <-- [5:ATH0\r]
Jul 29 15:53:30.35: [ 3816]: --> [2:OK]
Jul 29 15:53:30.36: [ 3816]: SESSION END
--
+---------------------------------------------------------------------+
| Able nv tel: +32.16.53.64.80 |
| Networking Consultancy & Services fax: +32.16.53.64.88 |
| Villadreef 9 - 3128 Tremelo - Belgium e-mail: Alex.Ongena@able.be |
+---------------------------------------------------------------------+
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic