On Wed, Feb 18, 2009 at 12:28:24PM -0500, Dustin J. Mitchell wrote:
> On Wed, Feb 18, 2009 at 11:30 AM, stan <stanb AT panix DOT com> wrote:
> > However, what I am suspecting is that we have been using a "corner case"
> > for years which may not work now. The new design appears to be able to more
> > correctly
> > describe our confguration, so I am suspecting that I need to change the
> > basic config to one using chg-rait, as i posted a minute ago. Or would you
> > suggest that we continue to use the older config, and debug it?
>
> I think your case is actually pretty typical. The advantage of using
> chg-rait is that you can employ chg-zd-mtx to operate a tape robot for
> your physical tapes. If you have no such robot, then the chg-multi
> solution is simpler. Also, the chg-rait shell script seems to be a
> bit buggy. I'm about to commit a new Amanda::Changer::rait, but
> obviously that's not in 2.6.1 :(
>
> > Now Here is the output of a failed run with 2.6.1 using the 2.6.1 chg-multi:
> >
> > arguments -> -info
> > Note: setting posteject to a default of true
> > Exit -> 2 25 1
> > arguments -> -slot current
> > Note: setting posteject to a default of true
> > Exit -> 2 chg-multi: slot is empty:
> (etc.)
>
> chg-multi is running 'amdevcheck' on each device to find out if there
> is a volume loaded, and apparently deciding that nothing is loaded.
> What is the output of
> amdevcheck DailyDump "rait:{file:/vtapes/DailyDump/vtape1,tape:/dev/nst0}"
********
OK, now we have uncovered what is probably the root cause of my problems:
amanda@amanda:/opt/amanda.2.6.1_02172009/sbin$ ./amdevcheck DailyDump
"rait:{file:/vtapes/DailyDump/vtape1,tape:/dev/nst0}"
Can't load '/usr/local/share/perl/5.8.8/auto/Amanda/Types/libTypes.so' for
module Amanda::Types: libamglue.so: cannot open shared object file: No such
file or directory at /usr/lib/perl/5.8/DynaLoader.pm line 225.
at /usr/local/share/perl/5.8.8/Amanda/Types.pm line 11
Compilation failed in require at
/usr/local/share/perl/5.8.8/Amanda/Device.pm line 10.
Compilation failed in require at ./amdevcheck line 24.
BEGIN failed--compilation aborted at ./amdevcheck line 24.
amanda@amanda:/opt/amanda.2.6.1_02172009/sbin$ vi +24 amdev
So the perl script cannot load the required module. Yet:
amanda@amanda:/usr/local/share/perl/5.8.8/auto/Amanda/Types$ ls -l
/usr/local/share/perl/5.8.8/auto/Amanda/Types/libTypes.so
-rwxr-xr-x 1 root root 199639 2009-01-28 10:25
/usr/local/share/perl/5.8.8/auto/Amanda/Types/libTypes.so
It exists and seems to have a set of permissions that I would think would
work.
file seems to like it:
amanda@amanda:/usr/local/share/perl/5.8.8/auto/Amanda/Types$ file
/usr/local/share/perl/5.8.8/auto/Amanda/Types/libTypes.so
/usr/local/share/perl/5.8.8/auto/Amanda/Types/libTypes.so: ELF 64-bit LSB
shared object, x86-64, version 1 (SYSV), not stripped
amanda@amanda:/usr/local/share/perl/5.8.8/auto/Aman
I have to admit, I have never had perl dynamically load a shared object
library, so I don't quite know where to go at this point.
Can I also register a concern? In the past, we have done work where we created
our own perl modules. One of the problems with that is that when you
upgrade perl, you have to go back and recreate all your own perl modules,
because perl puts these in a directory that is specific to the version. So,
for example on the Ubuntu server, I may accidently break Amanda, just by
doing an apt-get upgrade to isntall a fixed perl :-(
Also, we have clients with no perl installed on them. Is the use of perl
confined to the server? Some of the clients are old versions of Solaris,
HP-UX, etc. and we can't change them because they are production machines
in an industrial manufacturing environment. If they won't work with 2.6.1
we might have to backtrack to 2.5.2 (or 2.5.1).
--
One of the main causes of the fall of the roman empire was that, lacking
zero, they had no way to indicate successful termination of their C
programs.
|
