Thank you all who responded to my pitiful request for help. The
explanation for the message
DUMP: fopen on /dev/tty fails
is that dump was running under cron, and had no "controlling
terminal to open in order to communicate with the operator."
This is true...unfortunately, the error message preceding
the fopen message merely said "write failed".
Almost everyone suggested that I had run out of tape. I have
experienced this problem before with this script, and actually
got messages stating that the tape had reached the end. I
was not getting that kind of feed-back, nor were the total blocks
being backed up greater than the tape capacity.
It seems that no one does the command line for an Exabyte 5 GB
drive the same as anyone else--even the suggestions from Sun
are different (the size of 145000 is straight out of the Sun
SysAdmin class manual). I got two suggestions to use
/dev/nrst9 instead of nrst1, and several people used the
cartridge blocking size of 126. Since I had tried the other
suggestions, I changed blocking to 126, and the device to
nrst9--I don't know which one really did the trick, but at
least my backups are working again!
I also still do not know why what did work stopped working, but
I don't care as much at this point.
One person mentioned a problem with dumps failing because an
/etc/rmt process was hanging around. I had not experienced that
problem before, but during my testing, I started seeing it.
Thanks for anticipating!
Thanks again, and Happy Holidays to the Best Support Group around...
Linda Roy
linda_roy@imatron.com
---------------------------------------------------------------------
Original Question:
We have been using a home-grown script to do daily backups on a
Sparc2 (4.1.2 SunOS) to an Exabyte 8500 8mm tape drive. The script
sets up the file systems to back up, and uses the dump utility.
This procedure has been working fine for the 6 months that I have
been with the company. Last week, the dumps started failing with
the following message:
DUMP: fopen on /dev/tty fails
A typical dump command line looks like this:
/etc/dump 0bdfsu 1024 108000 /dev/nrst1 145000 /data
Since the failures started, the SunOS has been upgraded to 4.1.3,
the tape drive has been replaced with a new unit, the sequence of
file systems to dump has been changed, and the execution time has
been moved up by two hours.
The backups _always_ fail 2 hours 40-some minutes into each session.
Does anyone know what is happening here and how I can resolve my
problem?
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:33 CDT