SUMMARY: Backup problems with shared memory (?)

From: John Deacon <jrd_at_star.ucl.ac.uk>
Date: Mon, 05 Feb 2001 15:48:44 +0000 (GMT)

Hi All -


ORIGINAL PROBLEM:

I suddenly started getting the following failure and error message when
using dump:

> # dump -0u -b 64 -f /dev/nrmt0h /export/home
> dump: Dumping from host wibble.star.ucl.ac.uk
> dump: Date of this level 0 dump: Fri Feb 2 19:53:50 2001 GMT
> dump: Date of last level 0 dump: the start of the epoch
> dump: Dumping /dev/rrz0g (/export/home) to /dev/nrmt0h
> dump: Mapping (Pass I) [regular files]
> dump: Mapping (Pass II) [directories]
> dump: Cannot get shared memory
> alloc_tape(): shmget(): No space left on device
> dump: Cannot attach shared memory
> alloc_tape(): shmat(): Invalid argument
> dump: SIGSEGV received -- ABORTING!
> Abort process
> #


THE SOLUTION:

I got the following reply from Tom Blinn

>That's fascinating.. I didn't realize the "dump" utility used System V
>style shared memory; but that's what "shmget()" and "shmat()" are about.
>
>You can use the "ipcs" utility (see the reference page) to examine the
>current use of shared memory on your system. Since it's possible for
>an application to create a shared memory segment and leave it behind,
>you may have a "shared memory leak" on your system. Unless you can
>figure out how to resolve this otherwise, you may find that a reboot
>clears the problem.
>
>The documentation on the System V style shared memory and related stuff
>is pretty sparse.
>
>Tom
>
> Dr. Thomas P. Blinn + UNIX Software Group + Compaq Computer Corporation

a little reading of the 'ipcs' man page later and i could display a whole
pile of shared memory allocated to one user who'd since logged off the
machine, these could then be deallocated using 'ipcrm' so there was no
need for a reboot. also managed to get our software people to admit that
one application was "...responsible for leaving shared memory segments on
systems. It is (unfortunately) very bad in this respect. It may also leave
orphaned monoliths occupying process slots..." Lovely.


cheers,

 john


----------------------------------------------------------------------------
Dr John Deacon | UCL Starlink Site Manager
Dept Physics and Astronomy | Email: star_at_star.ucl.ac.uk
University College London | Tel: 020 7679 7147
Gower Street London WC1E 6BT | Fax: 020 7679 7145
----------------------------------------------------------------------------
  
Received on Mon Feb 05 2001 - 15:49:58 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:41 NZDT