- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Shared memory - not being freed / cannot use ipcrm
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-22-2003 02:23 AM
тАО10-22-2003 02:23 AM
Shared memory - not being freed / cannot use ipcrm
ipcs -a shows: -
Message Queues:
T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QN
UM QBYTES LSPID LRPID STIME RTIME CTIME
q 0 0x41a90511 --rw------- root system root system 0
0 65535 524389 524858 15:17:01 15:17:01 20:12:17
Shared Memory:
T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH
SEGSZ CPID LPID ATIME DTIME CTIME
m 0 0 D-rw------- ingres users ingres users 1
589824 942895 1016901 10:18:33 10:18:33 9:43:45
m 1 0 D-rw------- ingres users ingres users 1
147693568 942942 943258 9:56:49 10:17:56 9:43:45
m 4 0 D-rw------- ingres users ingres users 1
164118528 943264 944055 9:43:55 10:11:29 9:43:48
m 5 0 D-rw------- ingres users ingres users 1
482795520 943264 944055 9:43:55 10:11:29 9:43:48
m 6 0 D-rw------- ingres users ingres users 1
8192 943264 944055 9:43:55 10:11:29 9:43:53
m 7 0 D-rw------- ingres users ingres users 1
5210112 943264 944055 9:43:55 10:11:29 9:43:53
m 11 0 D-rw------- ingres users ingres users 1
3686400 944254 944275 9:43:55 9:43:55 9:43:55
Semaphores:
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OT
IME CTIME
s 0 0x696e6974 --ra-r--r-- root system root system 8 20:1
2:17 20:12:17
s 1 0x41a90511 --ra------- root system root system 1 20:1
2:16 20:12:16
s 514 0 --ra------- httpd httpd root system 1 no-e
ntry 20:14:25
s 3 0 --ra------- httpd httpd root system 1 no-e
ntry 20:14:25
It seems to think that a task is holding the memory segments 0 thru to 11. None of the PID's exist on the system. ipcrm -m xx just gives "ipcrm: shmid(xx): not found"
How can I get this shared memory back or find out what is actually holding it from being released ??
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-22-2003 04:21 PM
тАО10-22-2003 04:21 PM
Re: Shared memory - not being freed / cannot use ipcrm
It seems that the owner process that created the shared memory segment exited without at least un-attaching itself from the memory and that possible the shared memory is wired in physical memory. The NATTACH is 1 therefore the shared memory IPC sub-system believes there is a consumer of the memory, yet as you pointed out there is not. If NATTACH is 1 and you ipcrm -m {ID}, remove a segment, it will wait until the NATTACH is 0 before deleting it.
I'd want to understand why the process which setup the shared memory segment exited without first detaching itself from the shared memory. Maybe the process run by ingres is failing abnormally ?
I think your only recourse to safely recover this memory is to reboot.
Dave Bechtold
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-23-2003 04:15 AM
тАО10-23-2003 04:15 AM
Re: Shared memory - not being freed / cannot use ipcrm
it should not matter, whether the process failed abnormally or not. In any case, the os is the the one, which ends a process and releases the held resources, so why not here!
regards
Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-23-2003 09:37 AM
тАО10-23-2003 09:37 AM
Re: Shared memory - not being freed / cannot use ipcrm
It's the responsibility of the creator of the Shared Memory to destroy the shared memory. Depending on the application it may destroy the shared memory segment upon a normal exit, SIGTERM causes the process to exit and in doing so cleans up and destroys the shared memory. But, the shared memory will not be destroyed until all ATTACHes to that memory detach themselves - then the shared memory segment will be removed from the system.
Now that I look at this a bit closer - your shared memory segments have an KEY of "0" thus the ipcrm failing with "not found", but the NATTACH is non-zero meaning another consumer of the shared memory is attached, or at least we believe it's still attached - it never detached it's reference to the shared memory. Maybe it exited abnormally ?
So, when you say "None of the PID's exist on the system." are you saying that none of the CPID's, creator of the shared memory, or LPID's, last process to attach/detach the shared memory segment, exist on the system?
If that's the case I'd expect that the CPID process exited cleanly and marked the segment to be destroyed/removed but it remained because of the other LPID process had an attachment and that process exited abnormally with out first detaching from that segment. In that scenario I'm not sure the OS would know to actually remove the segment since it was never asked to detach it from the LPID.
Dave Bechtold
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-23-2003 07:36 PM
тАО10-23-2003 07:36 PM
Re: Shared memory - not being freed / cannot use ipcrm
In this particular case, the owner should be ingres. The ingres DBMS servers had been dropped via a "kill -9" (as it had totally stopped responding). There were no ingres userid/PID's on the system at all. In fact before the reboot there was nothing apart from OS pid's running.
Nope, it looks to me as though a kill -9 against a process holding shared memory can result in you being unable to free that memory without a reboot.
Reboot cures by the way (but hey we knew it would - because thats a standard MS Windoze answer !).
Cheers
Gary
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-23-2003 07:49 PM
тАО10-23-2003 07:49 PM
Re: Shared memory - not being freed / cannot use ipcrm
In your case the "Deletion" was forced (mode contains the flag "D"), but memory will not be freed until the last process detaches the segment (see "man ipcs" for a description).
Have you checked if a defunc process is still running?