BHeess@mcws.fidonet.org (Brian Heess) (06/20/91)
Hi.
Anybody know what's wrong for the above error to occur in the uulog?
I installed HDB3.5, and in Telephone setup I defined only Line 1 as connected.
I set polling for hourly.
The complete line is:
uucp mcws (6/19-23:24:52,99,0) CONN FAILED (DEVICE LOCKED)
There are more of them with other numbers in front of the 0.
Any ideas? Thanks!
-Brian
--
: Brian Heess - via FidoNet node 1:102/851 (818)352-2993
: ARPA/INTERNET: BHeess@mcws.fidonet.org
: UUCP: ...!{elroy,elroy!bohica}!mcws!BHeess
: Compu$erve: >internet:BHeess@mcws.fidonet.org
: or at Xerox: bheess.es_xc15@Xerox.com .OR. heess@arisia.Xerox.comgak@gakbox.Corp.Sun.COM (Richard Stueven) (06/21/91)
In article <455.28605DC6@mcws.fidonet.org>, BHeess@mcws.fidonet.org (Brian Heess) writes: |> |> uucp mcws (6/19-23:24:52,99,0) CONN FAILED (DEVICE LOCKED) I've seen this happen a lot. When an incoming call disconnects, often the lock file does not get removed. I wrote a small program, "uuunlock.c", that validates the lock file(s) and removes them if they're invalid. Since it's a short program, I'll include it here rather than posting to the source group. ============================================================================== #include <stdio.h> #include <fcntl.h> char *ulockf[] = { "/usr/spool/uucp/LCK..ph1" }; #define NULOCKF 1 main(argc,argv) int argc; char **argv; { int i, fd; long uucppid; char errbuff[512]; for (i = 0; i < NULOCKF; i++) { if ((fd = open(ulockf[i],O_RDONLY)) == -1) { sprintf(errbuff,"Can't open %s",ulockf[i]); perror(errbuff); } else if (read(fd,&uucppid,sizeof(uucppid)) == -1) { perror("read error"); } else { close(fd); if (kill((int)uucppid,0) == -1) { if (unlink(ulockf[i]) == -1) { sprintf(errbuff,"Can't unlink %s",ulockf[i]); perror(errbuff); } } else { sprintf(errbuff,"kill -0 %d failed",(int)uucppid); perror(errbuff); } } } } ================================================================================ -- I guess there's some things | Seems like the more I think I know I'm not meant to understand | The more I find I don't Ain't life a riot? Ain't love grand? | Every answer opens up so many questions Richard Stueven gak@Corp.Sun.COM ...!attmail!gak
gak@gakbox.Corp.Sun.COM (Richard Stueven) (06/21/91)
I forgot to mention in my previous article that I run "uuunlock" regularly via cron. The solution for Brian might be to have cron run "uuunlock" one minute before it runs uudaemon.poll. -- I guess there's some things | Seems like the more I think I know I'm not meant to understand | The more I find I don't Ain't life a riot? Ain't love grand? | Every answer opens up so many questions Richard Stueven gak@Corp.Sun.COM ...!attmail!gak
clewis@ferret.ocunix.on.ca (Chris Lewis) (06/22/91)
In article <4474@jethro.Corp.Sun.COM> gak@gakbox.Corp.Sun.COM (Richard Stueven) writes: >In article <455.28605DC6@mcws.fidonet.org>, BHeess@mcws.fidonet.org (Brian Heess) writes: >|> uucp mcws (6/19-23:24:52,99,0) CONN FAILED (DEVICE LOCKED) > >I've seen this happen a lot. When an incoming call disconnects, often the >lock file does not get removed. I wrote a small program, "uuunlock.c", that >validates the lock file(s) and removes them if they're invalid. Since it's >a short program, I'll include it here rather than posting to the source group. Odd, my HDB UUCP does do a validate on the lock file. If I kill -9 a uucico, the locks are left around. Running a second UUCP with debug on shows that it's found a lock file and that it's okay to remove it. I believe that HDB also does the kill 0 trick. On the other hand, I'd be more interested in seeing if there was still a process running. Run uustat -p and see if there's a running uugetty with a lock. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!