[LDM #ZJQ-667038]: LDM - message queue locked

Hi Mike,

re:
> Ldm starts fine..see attachment 1.
> 
> After ldm has been running awhile it has a few warnings...see attachment 2
> 
> Now ldm generally continues to run fine and do it's job, but there are
> some oddities. If not sure if these are gempak related or ldm related.
> I'm guessing it is caused by some config error on my part somewhere, but
> I need help tracking that down.
> 
> Symptoms:
> 
> From the command line as user ldm:
> ---------------------
> methost203:~/logs$ps
> semget: No such file or directory
> semop: Invalid argument
> [DEVICE -1]  The requested IPC message queue is locked.
> Error in message send = 22
> itype, ichan, nwords,2,-1,2
> ---------------------

Please run 'which ps' to see what command is actually being
executed.  I suggest this since GEMPAK has a 'ps' command,
and you could be accessing it if the PATH for your 'ldm' user
has the GEMPAK executable directory included before the location
of the OS' 'ps' command.

> This is a new one for me. I have seen message queues full because
> of hung gempak processes, but this seems to be related to ldm
> somehow.

Without further information, I am betting that it is a GEMPAK issue.

> I can run the ps command from a different user and get results.

This comment makes me 99.99% sure that the problem is the PATH defined
for your 'ldm' user.  If this is the case, do the following:

- change 'ldm's PATH so that any non-system directories occur at the
  end

- make sure that your changes are active in your login session

- stop and restart your LDM

> Now, the ldm is still running, but the machine is behaving "strangely".

> I am also getting hung gempak gf process, but usually this occurs when
> someone or some script does not enter "gpend". These gempak problems
> "seems" to originate or be caused by ldm or with the decoders writing
> files and not with gempak itself (I could be way off there). I do have
> a number of symbolic links and I recall an error somewhere referencing
> symbolic links.

Let's hold off further investigation until you verify/disprove my contention
that your PATH is incorrect.

> I know I have not giving enough info, but perhaps you could point me
> in the right direction of things to look for. This machine is operational
> and serves all our classes with data, so troubleshooting is tough, I can't
> really take the machine down. Gotta go to class...

Please let us know the outcome of your PATH investigation.

Cheers,

Tom
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: ZJQ-667038
Department: Support LDM
Priority: Normal
Status: Closed