Dave, I managed to get the following stack dump of the hung downstream LDM process on Virga that was receiving IDS data from us: (gdb) where #0 0x957587c1 in fcntl$UNIX2003 () #1 0x00028a76 in fd_lock (fd=1, cmd=9, l_type=3, offset=0, l_whence=0, extent=4096) at pq.c:3106 #2 0x00028d91 in rgn_lock (pq=0x101670, offset=0, extent=4096, rflags=4) at pq.c:3312 #3 0x0002994b in mm0_ftom (pq=0x101670, offset=0, extent=4096, rflags=4, ptrp=0x10168c) at pq.c:3785 #4 0x0002a99d in ctl_get (pq=0x101670, rflags=4) at pq.c:4361 #5 0x0002bad3 in pqe_new (pq=0x101670, infop=0x1220c0, ptrp=0x349a8, indexp=0xbfffe42c) at pq.c:5078 #6 0x00007fcf in down6_comingsoon (argp=0xbfffe4b0) at down6.c:355 #7 0x0000ace5 in comingsoon_6_svc (comingPar=0xbfffe4b0, rqstp=0xbfffe9dc) at ldm6_server.c:678 #8 0x0000b008 in ldmprog_6 (rqstp=0xbfffe9dc, transp=0x100530) at ldm6_svc.c:128 #9 0x0001515f in svc_getreqsock (sock=4) at svc.c:543 #10 0x00022696 in one_svc_run (xp_sock=4, inactive_timeo=60) at one_svc_run.c:89 #11 0x0000d60f in run_service (socket=4, inactiveTimeout=60, upName=0x101470 "idd.unidata.ucar.edu", upAddr=0xbfffec34, upId=19781, pqPathname=0xbfffefb7 "/usr/local/unidata/ldm/prodqueue/ldm.pq", expect=0x101490, pq=0x101670) at requester6.c:228 #12 0x0000e317 in req6_new (upName=0x101470 "idd.unidata.ucar.edu", port=388, request=0x101890, inactiveTimeout=60, pqPathname=0xbfffefb7 "/usr/local/unidata/ldm/prodqueue/ldm.pq", pq=0x101670, isPrimary=0) at requester6.c:671 #13 0x000036ce in prog_requester (source=0x101470 "idd.unidata.ucar.edu", port=388, clssp=0x101890, isPrimary=0, hostCount=2) at acl.c:1508 #14 0x00003beb in run_requester (hostId=0x101470 "idd.unidata.ucar.edu", port=388, clssp=0x101890, isPrimary=0, hostCount=2) at acl.c:1680 #15 0x00003ccd in new_requester (remoteLocation=0x100428, clssp=0x101890, isPrimary=0, hostCount=2) at acl.c:1735 #16 0x00003d29 in requester_add (remoteLocation=0x100428, clssp=0x101890, isPrimary=0, hostCount=2) at acl.c:1779 #17 0x00003ecf in invert_request_acl (ldmPort=388) at acl.c:1844 #18 0x00007819 in read_conf (conf_path=0xbfffefdf "/usr/local/unidata/ldm/etc/ldmd.conf", doSomething=1, defaultPort=388) at parser.y:635 #19 0x0000c964 in main (ac=6, av=0xbfffeeac) at ldmd.c:1012 Mike Schmidt tried to get a "dtruss" dump of the system calls that process was making but nothing was printed. He was able to get "dtruss" output for the downstream LDM that was receiving IDS data from Washington. Both of the above are consistent with a bug in the operating system that's preventing the fcntl() system-call from returning -- they're also consistent with what we've been seeing up to now. Mike is going to look into getting access to an Apple bug-reporting site to see if anyone else has reported this problem. Sorry for the bad news. Regards, Steve Emmerson Ticket Details =================== Ticket ID: TXN-293177 Department: Support LDM Priority: Normal Status: Open
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.