[Bacula-users] btape dumps core

2005-10-21 Thread John Kodis
I'm trying to install bacula on a 64-bit version of Red Hat Linux, 
and cannot get past the btape tests when I use an autochanger storage
configuration.  I am able to operate the changer manually using the
mtx program, and the btape "test" command will test the tape drive
successfully so long as I omit the autochanger part of the storage
configuration file.  The only changes that I've made to the
autoconf-generated storage config file are to eliminate the file
storage section and to instead uncomment the autochanger and two tape
drive sections.

Here are the series of commands that I issued to run the btape program:

[EMAIL PROTECTED] sbin]# LD_ASSUME_KERNEL=2.4.19
[EMAIL PROTECTED] sbin]# export LD_ASSUME_KERNEL
[EMAIL PROTECTED] sbin]# ulimit -c unlimited
[EMAIL PROTECTED] sbin]# ./btape -c ../etc/bacula-sd.conf /dev/nst0
Tape block granularity is 1024 bytes.
btape: butil.c:264 Using device: "/dev/nst0" for writing.
21-Oct 13:48 btape: 3301 Issuing autochanger "loaded drive 0" command.
21-Oct 13:48 btape: Fatal Error because: Bacula interrupted by signal
11: Segmentation violation
Kaboom! btape, btape got signal 11. Attempting traceback.
Kaboom! exepath=/opt/bacula/sbin
Calling: /opt/bacula/sbin/btraceback /opt/bacula/sbin/btape 0
Traceback complete, attempting cleanup ...
Segmentation fault (core dumped)

A backtrace of the resulting core file provides the following enlightenment:

(gdb) bt
#0  dequeue_messages (jcr=0x0) at message.c:1268
#1  0x0042c89e in b_free_jcr (file=0x572078 "\001", line=0, jcr=0x0) at 
jcr.c:392
#2  0x00404aff in terminate_btape (stat=11) at btape.c:302
#3  0x00437026 in signal_handler (sig=11) at signal.c:162
#4  0x002a9558f2e8 in __pthread_sighandler () from /lib64/libpthread.so.0
#5  
#6  edit_device_codes (dcr=0x579808, omsg=0x589e88 "", imsg=0x0, cmd=0x43ddc8 
"loaded") at autochanger.c:444
#7  0x0041b6c8 in get_autochanger_loaded_slot (dcr=0x579808) at 
autochanger.c:159
#8  0x004115ef in DEVICE::open_tape_device (this=0x578de8, 
dcr=0x579808, omode=3) at dev.c:338
#9  0x0041184e in DEVICE::open (this=0x578de8, dcr=0x579808, omode=3) 
at dev.c:281
#10 0x00414933 in first_open_device (dcr=0x579808) at device.c:267
#11 0x0040ed69 in setup_jcr (name=0x578098 '\u' ..., dev_name=0x579808 "", bsr=0x0, VolumeName=0x0, mode=0) at butil.c:173
#12 0x00409c3d in main (margc=0, margv=0x7fb9e0) at btape.c:260

I also receive an email with the Subject: Bacula GDB traceback of btape

Using host libthread_db library "/lib64/libthread_db.so.1".
ptrace: Operation not permitted.
/tmp/0: No such file or directory.
$1 = '\0' 
$2 = 0x0
$3 = 0x0
$4 = "PostgreSQL"
$5 = 0x449e53 "1.37.40 (01 October 2005)"
$6 = 0x449e3a "x86_64-unknown-linux-gnu"
$7 = 0x449e33 "redhat"
$8 = 0x449e20 "Enterprise release"
No stack.
/opt/bacula/etc/btraceback.gdb:11: Error in sourced command file:
No stack.

I'd welcome any suggestions about what further steps I can take to
track down what's going wrong here.

-- 
John KodisGoddard Space Flight Center
[EMAIL PROTECTED]  Greenbelt, Maryland, USA
Phone: 301-286-7376 Fax: 301-286-1771


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] btape dumps core

2005-10-21 Thread Arno Lehmann

Hello,

On 21.10.2005 20:18, John Kodis wrote:

I'm trying to install bacula on a 64-bit version of Red Hat Linux, 
and cannot get past the btape tests when I use an autochanger storage

configuration.  I am able to operate the changer manually using the
mtx program, and the btape "test" command will test the tape drive
successfully so long as I omit the autochanger part of the storage
configuration file.  The only changes that I've made to the
autoconf-generated storage config file are to eliminate the file
storage section and to instead uncomment the autochanger and two tape
drive sections.


I've seen that... I could work around that by using my older 
bacula-sd.conf file - one without the autochanger resource. I supposte 
that btape is simply not yet developed to know about the newer 
configuration file format.


So, I suggest you create a small fake configuration file and report your 
results!


Arno


Here are the series of commands that I issued to run the btape program:

[EMAIL PROTECTED] sbin]# LD_ASSUME_KERNEL=2.4.19
[EMAIL PROTECTED] sbin]# export LD_ASSUME_KERNEL
[EMAIL PROTECTED] sbin]# ulimit -c unlimited
[EMAIL PROTECTED] sbin]# ./btape -c ../etc/bacula-sd.conf /dev/nst0
Tape block granularity is 1024 bytes.
btape: butil.c:264 Using device: "/dev/nst0" for writing.
21-Oct 13:48 btape: 3301 Issuing autochanger "loaded drive 0" command.
21-Oct 13:48 btape: Fatal Error because: Bacula interrupted by signal
11: Segmentation violation
Kaboom! btape, btape got signal 11. Attempting traceback.
Kaboom! exepath=/opt/bacula/sbin
Calling: /opt/bacula/sbin/btraceback /opt/bacula/sbin/btape 0
Traceback complete, attempting cleanup ...
Segmentation fault (core dumped)

A backtrace of the resulting core file provides the following enlightenment:

(gdb) bt
#0  dequeue_messages (jcr=0x0) at message.c:1268
#1  0x0042c89e in b_free_jcr (file=0x572078 "\001", line=0, jcr=0x0) at 
jcr.c:392
#2  0x00404aff in terminate_btape (stat=11) at btape.c:302
#3  0x00437026 in signal_handler (sig=11) at signal.c:162
#4  0x002a9558f2e8 in __pthread_sighandler () from /lib64/libpthread.so.0
#5  
#6  edit_device_codes (dcr=0x579808, omsg=0x589e88 "", imsg=0x0, cmd=0x43ddc8 
"loaded") at autochanger.c:444
#7  0x0041b6c8 in get_autochanger_loaded_slot (dcr=0x579808) at 
autochanger.c:159
#8  0x004115ef in DEVICE::open_tape_device (this=0x578de8, 
dcr=0x579808, omode=3) at dev.c:338
#9  0x0041184e in DEVICE::open (this=0x578de8, dcr=0x579808, omode=3) 
at dev.c:281
#10 0x00414933 in first_open_device (dcr=0x579808) at device.c:267
#11 0x0040ed69 in setup_jcr (name=0x578098 '\u' ..., 
dev_name=0x579808 "", bsr=0x0, VolumeName=0x0, mode=0) at butil.c:173
#12 0x00409c3d in main (margc=0, margv=0x7fb9e0) at btape.c:260

I also receive an email with the Subject: Bacula GDB traceback of btape

Using host libthread_db library "/lib64/libthread_db.so.1".
ptrace: Operation not permitted.
/tmp/0: No such file or directory.
$1 = '\0' 
$2 = 0x0
$3 = 0x0
$4 = "PostgreSQL"
$5 = 0x449e53 "1.37.40 (01 October 2005)"
$6 = 0x449e3a "x86_64-unknown-linux-gnu"
$7 = 0x449e33 "redhat"
$8 = 0x449e20 "Enterprise release"
No stack.
/opt/bacula/etc/btraceback.gdb:11: Error in sourced command file:
No stack.

I'd welcome any suggestions about what further steps I can take to
track down what's going wrong here.



--
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann  http://www.its-lehmann.de


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] btape dumps core

2005-10-21 Thread John Kodis
On Fri, Oct 21, 2005 at 09:29:04PM +0200, Arno Lehmann wrote:

> I've seen that... I could work around that by using my older 
> bacula-sd.conf file - one without the autochanger resource. I supposte 
> that btape is simply not yet developed to know about the newer 
> configuration file format.

Yes, that would explain it.  I was fooled by the section of the
"Testing Your Tape Drive With Bacula" web page that says that "If you
have an autochanger and it is configured, Bacula will automatically
use it."

It looks like the guys writing the documentation just got a bit ahead
of the guys writing the btape code.  Since I've verified that the tape
drives themselves pass the btape tests, I'll just proceed with setting
up Bacula and not worry about this test code failure.

Thanks for the suggestion.  It saved me a potentially painful session
with gdb trying to figure out what was going wrong.

-- 
John KodisGoddard Space Flight Center
[EMAIL PROTECTED]  Greenbelt, Maryland, USA
Phone: 301-286-7376 Fax: 301-286-1771


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] btape dumps core

2005-10-22 Thread Arno Lehmann

Hello,

On 21.10.2005 23:11, John Kodis wrote:


On Fri, Oct 21, 2005 at 09:29:04PM +0200, Arno Lehmann wrote:


I've seen that... I could work around that by using my older 
bacula-sd.conf file - one without the autochanger resource. I supposte 
that btape is simply not yet developed to know about the newer 
configuration file format.



Yes, that would explain it.  I was fooled by the section of the
"Testing Your Tape Drive With Bacula" web page that says that "If you
have an autochanger and it is configured, Bacula will automatically
use it."


Well, that's what you get for using development versions :-)


It looks like the guys writing the documentation just got a bit ahead
of the guys writing the btape code.  Since I've verified that the tape
drives themselves pass the btape tests, I'll just proceed with setting
up Bacula and not worry about this test code failure.


After all, it's mainly only one guy...


Thanks for the suggestion.  It saved me a potentially painful session
with gdb trying to figure out what was going wrong.


Arno


--
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann  http://www.its-lehmann.de


---
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users


Re: [Bacula-users] btape dumps core

2005-10-25 Thread Kern Sibbald
Hello,

Yes, I forgot to ensure that all the tools properly initialize the 
autochangers. I've corrected this in the latest CVS.  Alternatively, you can 
simply add an "Autochanger Command = ..." to each of your Device definitions 
(copy the one in your Autochanger resource).

Regards, Kern

On Friday 21 October 2005 20:18, John Kodis wrote:
> I'm trying to install bacula on a 64-bit version of Red Hat Linux,
> and cannot get past the btape tests when I use an autochanger storage
> configuration.  I am able to operate the changer manually using the
> mtx program, and the btape "test" command will test the tape drive
> successfully so long as I omit the autochanger part of the storage
> configuration file.  The only changes that I've made to the
> autoconf-generated storage config file are to eliminate the file
> storage section and to instead uncomment the autochanger and two tape
> drive sections.
>
> Here are the series of commands that I issued to run the btape program:
>
> [EMAIL PROTECTED] sbin]# LD_ASSUME_KERNEL=2.4.19
> [EMAIL PROTECTED] sbin]# export LD_ASSUME_KERNEL
> [EMAIL PROTECTED] sbin]# ulimit -c unlimited
> [EMAIL PROTECTED] sbin]# ./btape -c ../etc/bacula-sd.conf /dev/nst0
> Tape block granularity is 1024 bytes.
> btape: butil.c:264 Using device: "/dev/nst0" for writing.
> 21-Oct 13:48 btape: 3301 Issuing autochanger "loaded drive 0" command.
> 21-Oct 13:48 btape: Fatal Error because: Bacula interrupted by signal
> 11: Segmentation violation
> Kaboom! btape, btape got signal 11. Attempting traceback.
> Kaboom! exepath=/opt/bacula/sbin
> Calling: /opt/bacula/sbin/btraceback /opt/bacula/sbin/btape 0
> Traceback complete, attempting cleanup ...
> Segmentation fault (core dumped)
>
> A backtrace of the resulting core file provides the following
> enlightenment:
>
> (gdb) bt
> #0  dequeue_messages (jcr=0x0) at message.c:1268
> #1  0x0042c89e in b_free_jcr (file=0x572078 "\001", line=0,
> jcr=0x0) at jcr.c:392 #2  0x00404aff in terminate_btape (stat=11)
> at btape.c:302 #3  0x00437026 in signal_handler (sig=11) at
> signal.c:162
> #4  0x002a9558f2e8 in __pthread_sighandler () from
> /lib64/libpthread.so.0 #5  
> #6  edit_device_codes (dcr=0x579808, omsg=0x589e88 "", imsg=0x0,
> cmd=0x43ddc8 "loaded") at autochanger.c:444 #7  0x0041b6c8 in
> get_autochanger_loaded_slot (dcr=0x579808) at autochanger.c:159 #8 
> 0x004115ef in DEVICE::open_tape_device (this=0x578de8,
> dcr=0x579808, omode=3) at dev.c:338 #9  0x0041184e in DEVICE::open
> (this=0x578de8, dcr=0x579808, omode=3) at dev.c:281 #10 0x00414933
> in first_open_device (dcr=0x579808) at device.c:267 #11 0x0040ed69
> in setup_jcr (name=0x578098 '\u' ...,
> dev_name=0x579808 "", bsr=0x0, VolumeName=0x0, mode=0) at butil.c:173 #12
> 0x00409c3d in main (margc=0, margv=0x7fb9e0) at btape.c:260
>
> I also receive an email with the Subject: Bacula GDB traceback of btape
>
> Using host libthread_db library "/lib64/libthread_db.so.1".
> ptrace: Operation not permitted.
> /tmp/0: No such file or directory.
> $1 = '\0' 
> $2 = 0x0
> $3 = 0x0
> $4 = "PostgreSQL"
> $5 = 0x449e53 "1.37.40 (01 October 2005)"
> $6 = 0x449e3a "x86_64-unknown-linux-gnu"
> $7 = 0x449e33 "redhat"
> $8 = 0x449e20 "Enterprise release"
> No stack.
> /opt/bacula/etc/btraceback.gdb:11: Error in sourced command file:
> No stack.
>
> I'd welcome any suggestions about what further steps I can take to
> track down what's going wrong here.


---
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users