20050714: McIDAS: Error - resource temporarily unavailable

>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