Brian:
>From a thread on the sudo user's mailing list earlier today:
Check your environment for the amcheck and ensure that the missing library
is not in a location that depends on LD_LIBRARY_PATH, which gets cleared
when running a setUID program and the real and effective users are not the
same.
Since you are probably running amcheck as the Amanda user ID and the amcheck
program is setUID root, if libintl.so.2 is not in one of the normally
searched library directories, it will not be found. If you recompile
amcheck so that the path to the library is in the executable (not sure how
to do that with Solaris, but Tru64's cc uses the '-rpath' option to tell the
loader where to find other libraries), then amcheck will not depend on the
contents of LD_LIBRARY_PATH.
Best wishes for the New Year,
Donald L. (Don) Ritchey
E-mail: Donald.Ritchey AT exeloncorp DOT com
-----Original Message-----
From: Brian Cuttler [mailto:brian AT wadsworth DOT org]
Sent: Tuesday, January 06, 2004 12:54 PM
To: amanda-users AT amanda DOT org
Cc: Chris Knight
Subject: Re: error ?
Jon,
Thanks (and happy new years).
That makes good sense - I should have realized it but I had
something else playing in the back of my mind. namely...
FAILURE AND STRANGE DUMP SUMMARY:
wcnotes /maildb lev 2 FAILED [no more holding disk space]
which was produced by 2.4.2p2 (rather than this new error) by
2.4.4 as this error was.
Well, it addresses the issues I'd brought up in my previous
out-of-spool email message (back on 12-Dec-2003).
Different results from running out of spool between the two
different versions of the amanda server.
On a completely different note - my 2.4.4 version of amanda
installs on my other Solaris 9 system but will not run.
Can't seem to resolve this library issue. Any ideas ?
# /usr/local/sbin/amcheck hal
ld.so.1: /usr/local/sbin/amcheck: fatal: libintl.so.2: open failed: No such
file or directory
Killed
thanks,
Brian
> On Tue, Jan 06, 2004 at 10:23:34AM -0500, Brian Cuttler wrote:
> >
> > Hello amanda users,
> >
> > My report from last night has the following error(?) or does it ?
> >
> >
> > But the "Dumper Summary" seems to show that all is ok and I've put
> > about 2x this amount of data to tape other times (LTO 220 drive).
> >
> > Was there actually an error ? If so what was/is it ?
> >
>
>
> I pulled just a few things out:
>
>
> > USAGE BY TAPE:
> > Label Time Size % Nb
> > NEWTONR05 4:03 100238.2 83.6 20
>
>
> Completed DLE's did not fill the tape.
>
> > NOTES:
> > taper: tape NEWTONR05 kb 102644512 fm 20 [OK]
>
> And this report seems to say nothing else was attempted. Full tapes
> show more total data written then the successful data written report
> above. And they show something like "[short write]"
>
>
> > NOTES:
> > driver: WARNING: /amanda/workr: 73400320 KB requested,
> > but only 10129652 KB available.
>
>
> Is this refering to your holding disk maybe?
>
>
> > FAILED AND STRANGE DUMP DETAILS:
> >
> > /-- lyra / lev 0 FAILED [write_tapeheader: No space left on
device]
> > sendbackup: start [lyra:/ level 0]
> > sendbackup: info BACKUP=/usr/sbin/ufsdump
> > sendbackup: info RECOVER_CMD=/usr/sbin/ufsrestore -f... -
> > sendbackup: info end
>
> And maybe this is a report saying could not write to holding disk
> so switching to direct to tape because of full holding disk?
>
> > csserv /source2 0 6992608 6992608 -- 21:41 5374.8 21:41
5374.2
> > csserv /var/spool 0 17794048 17794048 -- 45:18 6546.2 45:18
6546.0
> > lyra /db8 0 34624864 34624864 -- 110:45 5210.6 110:45
5210.5
> > lyra /db9 0 16814464 16814464 -- 42:32 6587.7 42:33
6587.3
>
> I notice a lot of your big DLE's show the same dump and tape times.
> That always suggests to me dump directly to tape.
>
> > mira /db4 1 2345760 2345760 -- 55:23 705.8 2:03
19081.4
> > mira /home1 0 2973024 2973024 -- 69:00 718.1 3:13
15434.5
> > panther / 0 3413763 3413792 -- 13:21 4261.0 2:24
23764.9
> > panther /data 1 20 32 -- 0:05 3.9 0:02
18.3
>
> Yet your other, smaller ones seem to dump and tape at different rates.
> Maybe they fit in the small holding space available.
>
> --
> Jon H. LaBadie jon AT jgcomp DOT com
> JG Computing
> 4455 Province Line Road (609) 252-0159
> Princeton, NJ 08540-4322 (609) 683-7220 (fax)
************************************************************************
This e-mail and any of its attachments may contain Exelon Corporation
proprietary information, which is privileged, confidential, or subject
to copyright belonging to the Exelon Corporation family of Companies.
This e-mail is intended solely for the use of the individual or entity
to which it is addressed. If you are not the intended recipient of this
e-mail, you are hereby notified that any dissemination, distribution,
copying, or action taken in relation to the contents of and attachments
to this e-mail is strictly prohibited and may be unlawful. If you have
received this e-mail in error, please notify the sender immediately and
permanently delete the original and any copy of this e-mail and any
printout. Thank You.
************************************************************************
|
