Your message dated Thu, 14 Feb 2008 10:19:38 -0600
with message-id <[EMAIL PROTECTED]>
and subject line Fwd: [bacula 0001048]: MTX script fails in Dell PV124T
has caused the Debian Bug report #452136,
regarding bacula: MTX script fails in Dell PV124T - terminated with signal 15.
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
452136: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452136
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: bacula
Version: 2.2.5-1
Severity: important
*** Please type your report below this line ***
Using the btape testing program, the testing of the autochanger Dell PV124T
with an LTO-3 drive failed. As far as I could tell, the mtx control script
was timing out and being killed with a signal 15.
Upon inspection of the bacula mtx script (/etc/bacula/scripts/mtx-changer) I
found that the problem lies in the function wait_for_drive(). The loop in the
function checks to see when the drive is available by matching 'ONLINE' on
the output of mt -f /dev/nst0 status.
In my system, ONLINE never appears in status, instead it lists the following
when the tape is available in the drive and hangs/errors otherwise.
# mt -f /dev/nst0 status
drive type = 114
drive status = 1140850688
sense key error = 0
residue count = 0
file number = 0
block number = 0
removing the pipe to grep solved the problem and the tape and changer passed
the test. At this point I am still testing bacula, so I have no idea of the
impact of this change in aditional functionality.
Thank you very much
João Sousa
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Versions of packages bacula depends on:
ii bacula-client 2.2.5-1 Network backup, recovery and
verif
ii bacula-server 2.2.5-1 Network backup, recovery and
verif
bacula recommends no packages.
-- no debconf information
--
--- End Message ---
--- Begin Message ---
Never heard back from submitter on questions. Closed upstream due to that,
so closing here due to that as well.
--- Begin Message ---
The following issue has been CLOSED
======================================================================
http://bugs.bacula.org/view.php?id=1048
======================================================================
Reported By: jgoerzen
Assigned To:
======================================================================
Project: bacula
Issue ID: 1048
Category: btape
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Resolution: not a bug
Fixed in Version:
======================================================================
Date Submitted: 01-29-2008 16:31 UTC
Last Modified: 02-14-2008 10:55 UTC
======================================================================
Summary: MTX script fails in Dell PV124T
Description:
Received at the Debian BTS from João Sousa <[EMAIL PROTECTED]> at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452136
Using the btape testing program, the testing of the autochanger Dell
PV124T
with an LTO-3 drive failed. As far as I could tell, the mtx control script
was timing out and being killed with a signal 15.
Upon inspection of the bacula mtx script (/etc/bacula/scripts/mtx-changer)
I
found that the problem lies in the function wait_for_drive(). The loop in
the
function checks to see when the drive is available by matching 'ONLINE' on
the output of mt -f /dev/nst0 status.
In my system, ONLINE never appears in status, instead it lists the
following
when the tape is available in the drive and hangs/errors otherwise.
# mt -f /dev/nst0 status
drive type = 114
drive status = 1140850688
sense key error = 0
residue count = 0
file number = 0
block number = 0
removing the pipe to grep solved the problem and the tape and changer
passed
the test. At this point I am still testing bacula, so I have no idea of
the
impact of this change in aditional functionality.
Thank you very much
João Sousa
======================================================================
----------------------------------------------------------------------
Dan Langille - 01-29-08 16:40
----------------------------------------------------------------------
FYI, 1.38.11 is a very old version, it was released over a year ago.
I believe you are referring to this line:
if mt -f $1 status 2>&1 | grep "${ready}" >/dev/null 2>&1; then
Referring to lines 56-69, approximately, you'll see that the various
states for various OS are handled there.
Can you tell me what line of your "mt -f" output indicates a ready or
online state?
----------------------------------------------------------------------
Dan Langille - 01-29-08 16:48
----------------------------------------------------------------------
BTW, what OS is that 1.38.11 running upon? This may be a clue to the
difference.
----------------------------------------------------------------------
kern - 01-29-08 17:40
----------------------------------------------------------------------
If you do not get an ONLINE status on a Linux system when there is a tape
in the drive, then you probably have some non-standard mt installed on your
system or perhaps Dell has made non-compatible changes to mt for their tape
drive????
Note: the mtx-changer script normally must be manually edited by each user
to conform to his particular situation. We do our best to make it adjust as
automatically as possible -- this is documented in the manual and should be
done during part of the tape testing.
To resolve this problem, you will either need to load the standard mt or
determine why on your system that mt is behaving differently from all other
Linux systems that I have seen. At that point, maybe we can find a work
around. If there is no way to uniquely determine that the tape is online,
then you will need to manually disable the call to the wait script and to
use a sleep as is documented in the code ...
I don't consider this a bug rather tuning the user must do. However, I
will leave the bug report open for awhile in case you can supply
information that will allow us to automate the script for your case.
----------------------------------------------------------------------
jgoerzen - 01-29-08 18:24
----------------------------------------------------------------------
Yeah, I know 1.38.x is old. The submitter is running 2.2.5 as I mentioned;
I just gave that as a point of reference.
I have passed your question on to him, but from his comments, I gather
that mt is returning an error code (nonzero exit status) and no useful
output when offline. I don't know exactly how you could tell the
difference between online here and online with other drives though, so I've
asked.
I also wonder, could he have the wrong tape device? Have you ever seen
output like this before?
----------------------------------------------------------------------
Dan Langille - 01-29-08 19:18
----------------------------------------------------------------------
I'm not convinced that /dev/nst0 is a tape CHANGER. I suspect it may be a
tape drive instead. Perhaps he needs /dev/sg*. He should check the output
of dmesg and see what he finds (well, that's what I'd do on FreeBSD).
And if he wants to see what I did:
http://www.freebsddiary.org/digital-tl891.php
Full and detailed tape/changer testing appears there.
----------------------------------------------------------------------
jgoerzen - 01-29-08 19:37
----------------------------------------------------------------------
I have sent these comments on to the submitter.
Dan, /dev/nst0 is never a tape changer. But then it should not be. We
are talking about mt here, not mtx. mt only works on drives. mtx is for
changers. I tested mt on /dev/sg1 locally, which is our changer, and it
will not work on it.
Kern, I understand where you're coming from that this is a configurable
command. I almost just closed it myself, but I thought that if we can
support this sort of configuration out of the box, it would be nice to do
so. I have asked the submitter for more details about his mt.
----------------------------------------------------------------------
kern - 01-29-08 21:03
----------------------------------------------------------------------
Yes, I didn't close the bug immediately because I would like to support it
out of the box too (if we can). The output looks more like FreeBSD mtx
output (if I remember right). Maybe Dan can comment on that.
By the way, I repeat (I think) that the solution in case there is no way
to detect that the tape is loaded is not to eliminate the pipe as the user
did but to comment out the call to the wait... and to put uncomment the
sleep and then adjust the sleep time to be correct. You might ask the user
if he is really running on a Debian system :-)
----------------------------------------------------------------------
kern - 01-29-08 21:08
----------------------------------------------------------------------
Response to Dan note http://bugs.bacula.org/view.php?id=3115: in this case the
/dev/nst0 is supposed to be a
tape drive not the control channel. The designation /dev/nst0 is correct
for a Linux drive, however as John pointed out, he may be using the wrong
device number.
----------------------------------------------------------------------
kern - 02-14-08 10:55
----------------------------------------------------------------------
As noted, it appears that the reporter is running a non-standard mt, and in
that case he must modify the mtx-changer script. If there is any new input
on this, please re-open the bug report. With the proper information, we
will be happy to adapt the script to be auto-configuring as we have done
with other platforms.
Issue History
Date Modified Username Field Change
======================================================================
01-29-08 16:31 jgoerzen New Issue
01-29-08 16:40 Dan Langille Note Added: 0003106
01-29-08 16:48 Dan Langille Note Added: 0003107
01-29-08 17:40 kern Note Added: 0003108
01-29-08 17:40 kern Status new => feedback
01-29-08 18:24 jgoerzen Note Added: 0003113
01-29-08 19:18 Dan Langille Note Added: 0003115
01-29-08 19:37 jgoerzen Note Added: 0003116
01-29-08 21:03 kern Note Added: 0003119
01-29-08 21:08 kern Note Added: 0003120
02-14-08 10:55 kern Note Added: 0003143
02-14-08 10:55 kern Status feedback => closed
02-14-08 10:55 kern Resolution open => not a bug
======================================================================
--- End Message ---
--- End Message ---
