This seems to happen occasionally, but right now I can't make the
problem go away - it seems that the tape drive (quantum m1500) is
not talking to the server correctly anymore.
14:35:55.998 [10306] <2> select_media: selected media id 000533 for
backup[0], megastore(rl = 1) <----------
14:35:55.999 [10306] <2> mount_open_media: Waiting for mount of media id
000533 (copy 1) on server dumped.
14:35:55.999 [10306] <2> mount_open_media: setting NDMP_TAPE_MOUNT flag
for tpreq, SpNum field is 1
14:40:52.540 [10334] <2> bptm: INITIATING (VERBOSE = 5): -count -cmd -rt 8
-rn 0 -stunit dumped-dlt3-robot-tld-0 -den 21 -mt 2 -masterversion 450000
14:40:52.541 [10334] <2> bptm: EXITING with status 0 <----------
14:40:52.581 [10336] <2> bptm: INITIATING (VERBOSE = 5): -count -cmd -rt 8
-rn 0 -stunit megastore-dlt3-robot-tld-0 -den 21 -mt 3 -masterversion
450000 -c megastore
14:40:52.582 [10336] <2> bptm: EXITING with status 0 <----------
14:40:55.741 [10306] <2> mount_open_media: mount canceled detected in
tpreq(), signo = 1
14:40:55.762 [10306] <16> mount_open_media: media manager terminated
during mount of media id 000533, possible media mount timeout
I set a timeout on the mount, otherwise this would hang infinitely.
On my console I notice :
Mar 11 14:37:03 dumped tldcd[10092]: Cannot find request in
decode_response, pid = 10313
Sometimes I see this message, other times I don't, and everything
is still hung, like it's waiting for a "OK" from the tape drive that
it never receives.
Googling for "Cannot find request in decode_response" tells me
this was a fix w/no workaround in 4.5MP6 (the version I was running).
So I upgraded to 4.5MP8. (Server, clients, NDMP, and Java, in that
order).
I'm still having this issue - looking at the tape drive, I see that
the tape does get loaded, but apparently the tape drive never is able
to tell VNB that this event happened.
Also, through the Java GUI, my server still appears as 4.5MP6, even
though I ran all the upgrade scripts, etc.
Any suggestions? Thoughts?
--
It's always September somewhere on the 'net. | http://angui.sh
Another proud member of Eep's killfile. | Unix Sys. Admin.
All projects approach the ghetto, some |
faster than others. | matt AT angui DOT sh
|
