This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Gilbert, > Quick question. DOing an "ipcs" as root gives me this: > > ipcs > > ------ Shared Memory Segments -------- > key shmid owner perms bytes nattch status > 0x00000000 196608 ldm 600 384320 0 > 0x00000000 229377 ldm 600 512000 0 > 0x00000000 294914 ldm 600 384320 0 > 0x00000000 327683 ldm 600 512000 0 > 0x00000000 360452 ldm 600 393216 2 dest > 0x00000000 393221 ldm 600 393216 2 dest > 0x00000000 425990 ldm 600 393216 2 dest > 0x00000000 458759 ldm 600 393216 2 dest > 0x00000000 491528 ldm 600 393216 2 dest > 0x00000000 524297 ldm 600 393216 2 dest > 0x00000000 557066 ldm 600 393216 2 dest > 0x00000000 589835 ldm 600 12288 2 dest > 0x00000000 622604 ldm 600 12288 2 dest > key semid owner perms nsems > 0x00000000 491520 apache 600 1 > 0x00000000 32769 apache 600 1 > 0x00000000 524290 apache 600 1 > 0x00000000 557059 apache 600 1 > 0x00000000 589828 apache 600 1 > 0x00000000 622597 apache 600 1 > 0x00000000 655366 apache 600 1 > 0x00000000 688135 apache 600 1 > > ------ Message Queues -------- > key msqid owner perms used-bytes messages > > Is this good or bad? I know the LDM tries to do as much stuff in memory as > possible. This is what is happening, correct? All child LDM processes memory-map the product-queue. While technically not a shared memory segment, I suspect that the memory-mapped queue is showing up in the "ipcs" output as such. It's harmless. Regards, Steve Emmerson Ticket Details =================== Ticket ID: NNE-789939 Department: Support LDM Priority: Normal Status: Closed