I am attempting to do an automated dump process nightly loosely based
on the example in the TZ877 manual. Basically, I start off with
making sure that the current tape in /dev/rmt0h is rewound. Then I
proceed to dump each of the mounted filesystems to /dev/nrmt0h. Then
I offline /dev/nrmt0h. This seems to work okay, it's just that now
dump is giving me all sorts of grief in the form of the following:
Nightly Backup Starting at : Tue Mar 12 00:50:00 EST 1996
/dev/rmt0h: Device busy
###
### Dumping /devl
###
dump: Dumping from host pat.ccix.com
dump: Date of this level 0 dump: Tue Mar 12 00:53:00 1996 EST
dump: Date of last level dump: the start of the epoch
dump: Dumping /dev/rrza26g (/devl) to /dev/nrmt0h
dump: Mapping (Pass I) [regular files]
dump: Mapping (Pass II) [directories]
dump: Cannot open device file /dev/nrmt0h
dump: Cannot fopen /dev/tty for reading
query(): fopen(): No such device or address
dump: SIGTERM received -- Try rewriting
dump: Unexpected signal -- cannot recover
dump: Cannot remove shared memory
remove_shared_memory(): shmctl(): Invalid argument
dump: SIGTERM received -- Try rewriting
dump: Unexpected signal -- cannot recover
###
### Dumping /test
###
dump: Dumping from host pat.ccix.com
dump: Date of this level 0 dump: Tue Mar 12 00:54:34 1996 EST
dump: Date of last level dump: the start of the epoch
dump: Dumping /dev/rrza28g (/test) to /dev/nrmt0h
dump: Mapping (Pass I) [regular files]
dump: Mapping (Pass II) [directories]
dump: Cannot open device file /dev/nrmt0h
dump: Cannot fopen /dev/tty for reading
query(): fopen(): No such device or address
dump: SIGTERM received -- Try rewriting
dump: Unexpected signal -- cannot recover
dump: Cannot remove shared memory
remove_shared_memory(): shmctl(): Invalid argument
dump: SIGTERM received -- Try rewriting
dump: Unexpected signal -- cannot recover
What's even stranger is that on the previous evening, /devl dumped
fine while /test gave me the same error. I have successfully backed
up /test before, though. A note on the shared memory, we do have
Oracle 7.2.3 running on the machine and I had tweaked the kernel
shared memory size parameters. I don't think that that would
necessarily cause this problem, but you never really know.
Bob Capps
bob.capps_at_ps.net
Received on Tue Mar 12 1996 - 16:57:19 NZDT