>From: "Kwan-yin Kong" <address@hidden> >Organization: CCNY >Keywords: 200507131709.j6DH91jo022573 McIDAS shared memory pipe read Hi Kwan, >I checked the contents of .mctmp in 'mcidas', 'ldm', >and my own account but found no temp directories. The directory names would be numbers, not 'temp'. The names match the shared memory segment id that is created by a McIDAS session (mini or otherwise). An example of what I am talking about can be seen in the following listing from a Linux (Fedora Core 3) machine running the LDN and XCD decoders: <as 'ldm'> total 64 drwx------ 16 ldm Unidata 4096 Jul 14 16:31 . drwxr-xr-x 28 ldm Unidata 4096 Jul 14 13:35 .. drwx------ 2 ldm Unidata 4096 Jul 11 19:51 723812377 drwx------ 2 ldm Unidata 4096 Jul 11 19:51 723779604 drwx------ 2 ldm Unidata 4096 Jul 11 18:59 721944602 drwx------ 2 ldm Unidata 4096 Jul 11 18:54 721780758 drwx------ 2 ldm Unidata 4096 Jun 20 15:13 324239381 drwx------ 2 ldm Unidata 4096 Jun 13 17:33 188743680 drwx------ 2 ldm Unidata 4096 Jun 13 17:33 188776449 drwx------ 2 ldm Unidata 4096 Jun 3 06:02 48168962 drwx------ 2 ldm Unidata 4096 May 26 15:05 3899414 drwx------ 2 ldm Unidata 4096 May 26 14:43 2228244 drwx------ 2 ldm Unidata 4096 May 26 14:41 1966088 drwx------ 2 ldm Unidata 4096 May 26 14:41 1998860 drwx------ 2 ldm Unidata 4096 May 26 14:41 2031632 drwx------ 2 ldm Unidata 4096 May 26 07:34 819202 The directories timestamped on the 11th are current. The ones with older timestamps are remnants of improperly terminated McIDAS sessions. When I run ipcs as 'ldm', I see: ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 188743680 ldm 600 384300 0 0x00000000 188776449 ldm 600 384300 0 0x00000000 48168962 ldm 600 384300 0 0x00000000 188809219 ldm 600 512000 0 0x00000000 188841988 ldm 600 512000 0 0x00000000 48201733 ldm 600 512000 0 0x00000000 251396104 root 644 106496 2 dest 0x00000000 723779604 ldm 600 384300 2 0x00000000 324239381 ldm 600 384300 0 0x00000000 721780758 ldm 600 384300 0 0x00000000 324304919 ldm 600 512000 0 0x00000000 721813528 ldm 600 512000 0 0x00000000 723812377 ldm 600 384300 2 0x00000000 721944602 ldm 600 384300 0 0x00000000 721977371 ldm 600 512000 0 0x00000000 723845148 ldm 600 512000 0 0x00000000 723877917 ldm 600 512000 0 ------ Semaphore Arrays -------- key semid owner perms nsems ------ Message Queues -------- key msqid owner perms used-bytes messages In a situation where lots of shared memory segments are found and the corresponding directories under ~/.mctmp are old, it means that system resource (shared memory in this case) is being prevented from returning to a pool where new application invocations can use it. One other thing occurs to me. Are you running GEMPAK/GEMPAK scripts? If yes, then your system resource may be being eaten up by GEMPAK plot processes that did not properly exit (gpend). At this point, I would recommend rebooting to see what happens. >Meanwhile, the pipe errors persist. The last time I saw pipe errors it indicated an unexpected interruption of an ADDE transaction. That case was found when running UAPLOT to plot soundings, and the error only showed up under Linux. >I also ran the ipcs >command in 'root' but it didn't show any entries with >owner 'mcidas'. OK, this is probably the most compelling piece of information you have sent. This is what led me to ask if you are running GEMPAK. Cheers, Tom -- 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. >From address@hidden Thu Jul 14 14:53:59 2005 Hi Tom, Although I have GEMPAK installed, I have not run it for a long time (probably a year). Before you sent me your last email, I only ran ipcs as 'root' but not in other accounts. When I ran it in 'mcidas', it shows empty entries, i.e. <-mcidas-> ipcs IPC status from <running system> as of Thu Jul 14 16:41:46 EDT 2005 T ID KEY MODE OWNER GROUP Message Queues: Shared Memory: Semaphores: Kwan
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.