Re: missing result
On Saturday 24 March 2007, Joe Konecny wrote: Gene Heskett wrote: snip I believe, and somebody correct me if I'm wrong, but ISTR that file needs to be touched by root, 'chown'ed to 'amanda:disk' or whatever your amanda user is named: and a member of that :group, then chmod'ed to 0600, so that 'amanda' is the only normal user with rights to that file. I use amanda:disk here cause then I don't have to remember who the operator for amanda is. I left it 644 and it seems ok. Strange the whole amandates thing isn't in the docs (except for the cygwin part so you'd think it wouldn't apply) and it's not in the faq either. Seems like it should be part of the installation instructions. If it was going to be mentioned, I'd think it would be in the manpage for amdump, but you are correct, its not in there. In the src tree's docs dir, a grep shows it in 'amanda.client.conf.5.txt': amanda-client.conf.5.txt: amandates string amanda-client.conf.5.txt: Default: /etc/amandates. The file where amanda keep the last date of each amanda-client.conf.5.txt- dumplevel. And in 'whatwasnew.txt': - Since Gnu TAR does not maintain a dumpdates file itself, nor give an estimate of backup size, those need to be done within Amanda. Amanda maintains an /etc/ amandates file to track the backup dates analogously to how dump does it. NOTE: if your /etc directory is not writable by your dumpuser, you'll have to create the empty file initially by hand, and make it writable by your dumpuser ala /etc/dumpdates. NOTE: Since tar traverses the directory hierarchy and reads files as a regular user would, it must run as root. The two new Amanda programs calcsize and runtar therefore must be installed setuid root. I've made them as simple as possible to to avoid potential security holes. --- But that, it appears, does not make it into the manpages. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Yevtushenko has... an ego that can crack crystal at a distance of twenty feet. -- John Cheever
Re: missing result
On Sat, Mar 24, 2007 at 12:01:16AM -0400, Joe Konecny wrote: I left it 644 and it seems ok. Strange the whole amandates thing isn't in the docs (except for the cygwin part so you'd think it wouldn't apply) and it's not in the faq either. Seems like it should be part of the installation instructions. There are two separate attempts to create the /etc/amandates file in the source code client-src/amandates.c when access to the file is first attempted. So it typically would not be an installation item. Perhaps cygwin is a special case where those creation attemps fail. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: missing result
On Saturday 24 March 2007, Jon LaBadie wrote: On Sat, Mar 24, 2007 at 12:01:16AM -0400, Joe Konecny wrote: I left it 644 and it seems ok. Strange the whole amandates thing isn't in the docs (except for the cygwin part so you'd think it wouldn't apply) and it's not in the faq either. Seems like it should be part of the installation instructions. There are two separate attempts to create the /etc/amandates file in the source code client-src/amandates.c when access to the file is first attempted. So it typically would not be an installation item. Perhaps cygwin is a special case where those creation attemps fail. ISTR it also failed here on this FC6 box and I had to touch it after installing amanda from the old installs /home/amanda tree, back in the middle of November 2006. ISTR amanda didn't have perms to touch (create) a file in the /etc dir, so I had to do it as root, then chown and chmod it. Then everybody was happy. Which at the time may have been an selinux problem. That's such a PITA its been disabled after the first week of its screwups like that. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) There are more old drunkards than old doctors.
Re: missing result
Gene Heskett wrote: snip Yes, start with howto-auth.txt in the tarballs doc directory to do it how I am, which probably isn't the ultimate model, but it works for me. This looks like it was because the file /etc/amandates was missing. Apparently the install does not create it. I found an error in the auth.log... Mar 22 00:00:01 r4p17 sendsize[90503]: error [opening /etc/amandates: No such file or directory] I don't know what /etc/amandates is for but my backups seem much happier with it. Thanks for your help!
Re: missing result
On Friday 23 March 2007, Joe Konecny wrote: Gene Heskett wrote: snip Yes, start with howto-auth.txt in the tarballs doc directory to do it how I am, which probably isn't the ultimate model, but it works for me. This looks like it was because the file /etc/amandates was missing. Apparently the install does not create it. I found an error in the auth.log... Mar 22 00:00:01 r4p17 sendsize[90503]: error [opening /etc/amandates: No such file or directory] I don't know what /etc/amandates is for but my backups seem much happier with it. Thanks for your help! I believe, and somebody correct me if I'm wrong, but ISTR that file needs to be touched by root, 'chown'ed to 'amanda:disk' or whatever your amanda user is named: and a member of that :group, then chmod'ed to 0600, so that 'amanda' is the only normal user with rights to that file. I use amanda:disk here cause then I don't have to remember who the operator for amanda is. It will then be maintained in an uptodate status from then on by the amdump supervisory utils. Its general format will resemble this: === /GenesAmandaHelper-0.6 0 1174288560 /GenesAmandaHelper-0.6 1 1174453248 /GenesAmandaHelper-0.6 2 1174541095 /GenesAmandaHelper-0.6 3 1174625228 [snip another 100k of different pathlistings] === The number after the path is the level, and I'm not sure what the last number is, possibly a timestamp, but I've NDI what notation format that represents. Swahili to this old fart. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The bureaucracy is expanding to meet the needs of an expanding bureaucracy.
Re: missing result
Gene Heskett wrote: snippage re /etc/amandates === /GenesAmandaHelper-0.6 0 1174288560 /GenesAmandaHelper-0.6 1 1174453248 /GenesAmandaHelper-0.6 2 1174541095 /GenesAmandaHelper-0.6 3 1174625228 [snip another 100k of different pathlistings] === The number after the path is the level, and I'm not sure what the last number is, possibly a timestamp, but I've NDI what notation format that represents. Swahili to this old fart. The number is a timestamp in UNIX epoch time (seconds since 1-1-1970). Your first number, 1174288560, is Mon Mar 19 07:16:00 2007 UTC You can do the conversion with the Perl function localtime, , or a C program using the system ctime function, or use one of the online javascript converters like http://dan.drydog.com/unixdatetime.html Frank -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: missing result
On Friday 23 March 2007, Frank Smith wrote: Gene Heskett wrote: snippage re /etc/amandates === /GenesAmandaHelper-0.6 0 1174288560 /GenesAmandaHelper-0.6 1 1174453248 /GenesAmandaHelper-0.6 2 1174541095 /GenesAmandaHelper-0.6 3 1174625228 [snip another 100k of different pathlistings] === The number after the path is the level, and I'm not sure what the last number is, possibly a timestamp, but I've NDI what notation format that represents. Swahili to this old fart. The number is a timestamp in UNIX epoch time (seconds since 1-1-1970). Your first number, 1174288560, is Mon Mar 19 07:16:00 2007 UTC You can do the conversion with the Perl function localtime, , or a C program using the system ctime function, or use one of the online javascript converters like http://dan.drydog.com/unixdatetime.html Frank Thanks, Frank. I figured maybe it was Julian, but those numbers look way too old to be current. Unix epoch time format never occurred to me. But it makes perfect sense now. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) HAL 9000: Dave. Put down those Windows disks, Dave. DAVE!
Re: missing result
Gene Heskett wrote: snip I believe, and somebody correct me if I'm wrong, but ISTR that file needs to be touched by root, 'chown'ed to 'amanda:disk' or whatever your amanda user is named: and a member of that :group, then chmod'ed to 0600, so that 'amanda' is the only normal user with rights to that file. I use amanda:disk here cause then I don't have to remember who the operator for amanda is. I left it 644 and it seems ok. Strange the whole amandates thing isn't in the docs (except for the cygwin part so you'd think it wouldn't apply) and it's not in the faq either. Seems like it should be part of the installation instructions.
Re: missing result
On Thursday 22 March 2007, Joe Konecny wrote:
I upgraded from 2.4.5? to 2.5.1p3 and now have the following problem...
Can anyone provide any insight?
The security model was changed in the middle of that transition. Did you
do the appropriate changes, which I believe are explained in the FAQ?
These dumps were to tape daily set1006.
The next tape Amanda expects to use is: DailySet1002.
FAILURE AND STRANGE DUMP SUMMARY:
R4P17.rmtohio.com amrd0s1f lev 0 FAILED [missing result for
amrd0s1f in R4P17.rmtohio.com response]
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0
Filesystems Taped 0 0 0
Chunks Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --
USAGE BY TAPE:
Label Time Size %NbNc
DailySet1006 0:000k0.0 0 0
--
Cheers, Gene
There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Success is relative: It is what we can make of the mess we have made of
things.
-- T.S. Eliot, The Family Reunion
Re: missing result
Gene Heskett wrote: On Thursday 22 March 2007, Joe Konecny wrote: I upgraded from 2.4.5? to 2.5.1p3 and now have the following problem... Can anyone provide any insight? The security model was changed in the middle of that transition. Did you do the appropriate changes, which I believe are explained in the FAQ? I've searched the faq but have turned up nothing. Is there a chance you could point me in the right direction to find the info I need to make this work?
Re: missing result
On Thursday 22 March 2007, Joe Konecny wrote: Gene Heskett wrote: On Thursday 22 March 2007, Joe Konecny wrote: I upgraded from 2.4.5? to 2.5.1p3 and now have the following problem... Can anyone provide any insight? The security model was changed in the middle of that transition. Did you do the appropriate changes, which I believe are explained in the FAQ? I've searched the faq but have turned up nothing. Is there a chance you could point me in the right direction to find the info I need to make this work? Not right at the moment but I expect a google search for amanda + bsdtcp-security might turn up something. I had to add a line to my configuration driver script which I posted in another thread on this list just this evening, and I had to create a couple of files, the exact details of which elude me as I've reached that age (72) where short term memory isn't so quick. I do see that the /home/amanda/.amandahosts file has some additions also. More aliases mainly. This line in my gh.cf file which drives the configure stage here was added: --with-bsdtcp-security \ There might be something in the docs directory of the tarball. Yes, start with howto-auth.txt in the tarballs doc directory to do it how I am, which probably isn't the ultimate model, but it works for me. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) You want brutality and heuristics? I'll give you brutality and heuristics... - Eric S. Raymond on linux-kernel
Re: missing result ... in ... response ???
* Paul Bijnens [EMAIL PROTECTED] [2006:05:29:14:13:00+0200] scribed: snip / Jean-Louis created a patch for 2.5.0, which break at 64K (just as 2.4.x), which fixes your problem. Yes. As I stated earlier, it is better for me to use debian packages; rather than attempting to maintain personal compilations ... It fixes it until you hit the 64Kbyte limit, at which time, 2.5.1 or 2.5.2 will have removed that limit, we hope. OK. Just to clarify, do I understand you correctly, that amanda developers are working on solution to this problem, and some expectation has been set (by them?) that these subsequent dot releases should correct this problem? If so, I shall be patient -- and wait ; Thank you, for your contributions to this problem ... -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: missing result ... in ... response ???
* On 2006:05:25:08:25:07-0500 I, Michael D Schleif [EMAIL PROTECTED], scribed: Something has changed in amanda. I have been running amanda on this lan for several years. For the most part, DLE's have been constant for at least six months. I have six linux servers, all running debian. Regarding amanda-server, my records show that I upgraded amanda to version: 2.4.5 on 16JUN05 Everything was backing up, and restoring, to my satisfaction, until last week. At that time, two servers (brono jord) were terribly old, regarding kernel and debian os. So, I upgraded via aptitude, which also upgraded amanda-client to version: 2.5.0 Since that time, many -- but, NOT all -- DLE's on brono and jord are FAIL'ing, e.g.: brono /var lev 0 FAILED [missing result for /var in brono response] jord /var lev 0 FAILED [missing result for /var in jord response] Yes, both of these servers have many DLE's; but, as stated above, this HAS been working without incident at the older version. Numbers of DLE's: brono 137 jord 219 snip / Bdale Garbee published to debian repository version 2.5.0p2. I have tried this on brono and jord, and this does NOT resolve the problem. I now have this on ALL of my boxen, except brono and jord, which I have downgraded to 2.4.4p3-3. Last night was my first completely successful backup in more than one week! I have received several private emails explaining the situation. I do understand those issues. However, amanda DOES succeed in my situation in versions _prior_ to v2.5.x -- and it FAILS in ALL v2.5.x ; This I do NOT understand. What am I missing? How will I know when a new version corrects this problem? -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: missing result ... in ... response ???
On 2006-05-29 13:38, Michael D Schleif wrote: * On 2006:05:25:08:25:07-0500 I, Michael D Schleif [EMAIL PROTECTED], scribed: Something has changed in amanda. I have been running amanda on this lan for several years. For the most part, DLE's have been constant for at least six months. I have six linux servers, all running debian. Regarding amanda-server, my records show that I upgraded amanda to version: 2.4.5 on 16JUN05 Everything was backing up, and restoring, to my satisfaction, until last week. At that time, two servers (brono jord) were terribly old, regarding kernel and debian os. So, I upgraded via aptitude, which also upgraded amanda-client to version: 2.5.0 Since that time, many -- but, NOT all -- DLE's on brono and jord are FAIL'ing, e.g.: brono /var lev 0 FAILED [missing result for /var in brono response] jord /var lev 0 FAILED [missing result for /var in jord response] Yes, both of these servers have many DLE's; but, as stated above, this HAS been working without incident at the older version. Numbers of DLE's: brono 137 jord 219 snip / Bdale Garbee published to debian repository version 2.5.0p2. I have tried this on brono and jord, and this does NOT resolve the problem. I now have this on ALL of my boxen, except brono and jord, which I have downgraded to 2.4.4p3-3. Last night was my first completely successful backup in more than one week! I have received several private emails explaining the situation. I do understand those issues. However, amanda DOES succeed in my situation in versions _prior_ to v2.5.x -- and it FAILS in ALL v2.5.x ; In Amanda 2.4.x there is upper limit of 64K on the size of the request packets using the UDP. That resulted in errors once you got above the system limit. The system limit for UDP packets is on some systems only 8K or so, but most (all?) can be increased to 64K. Larger than 64K is not possible due to the layout of a UDP packet, which has only 2 bytes for the length. All text that does not fit in the 64K is discarded. In Amanda 2.5.0 there is code that breaks up the request in multiple chunks. However, that code is only implemented in the server side. The client code has not yet any provisions to re-assemble the multiple requests (or even to detect that the packet was divided!). I guess that doing this in a backward compatible way was not evident (multiple possibilities exist, some using feature bits, to extend the protocol, another way is to change the server code even more). Now, it just happens (why I don't know) that 2.5.0 breaks up those chunks in 32Kbytes, while 64Kbytes would have be good enough too (maybe because the answer needs to fit in a 1 packet too -- which it currently does, but maybe the implementor forsaw more info in the reply?). Jean-Louis created a patch for 2.5.0, which break at 64K (just as 2.4.x), which fixes your problem. It fixes it until you hit the 64Kbyte limit, at which time, 2.5.1 or 2.5.2 will have removed that limit, we hope. Setting the limit to 64K instead of 32K is perfectly fine here. But it does not solve the fundamental problem that was already present in Amanda 2.4.x either. This I do NOT understand. Or I'm confused about what exactly you do not understand... What am I missing? Or me? How will I know when a new version corrects this problem? Watching the ChangeLog and NEWS file... -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: missing result ... in ... response ???
Michael,
If the problem is that you have too many DLE for a udp packet, try the
attached patch which will double the size of the packet.
Jean-Louis
Michael D Schleif wrote:
Something has changed in amanda.
I have been running amanda on this lan for several years. For the most
part, DLE's have been constant for at least six months. I have six
linux servers, all running debian. Regarding amanda-server, my records
show that I upgraded amanda to version:
2.4.5 on 16JUN05
Everything was backing up, and restoring, to my satisfaction, until last
week. At that time, two servers (brono jord) were terribly old,
regarding kernel and debian os. So, I upgraded via aptitude, which also
upgraded amanda-client to version:
2.5.0
Since that time, many -- but, NOT all -- DLE's on brono and jord are
FAIL'ing, e.g.:
brono /var lev 0 FAILED [missing result for /var in brono response]
jord /var lev 0 FAILED [missing result for /var in jord response]
Yes, both of these servers have many DLE's; but, as stated above, this
HAS been working without incident at the older version. Numbers of
DLE's:
brono 137
jord 219
At first, I thought that this maybe conflict between amanda-server and
amanda-client versions; so, I upgraded amanda-server:
2.5.0 on 23MAY06
NO difference.
So, I searched these archives, and I googled. All I found was this URL:
http://wiki.zmanda.com/index.php/Amdump:_results_missing
amanda.conf has never had `etimeout' configured. Yesterday, I set it:
etimeout 600
NO difference. Remember, this exact same configuration has been working
WITHOUT incident at older version for eleven months!
This is NOT a firewall issue, since this is only for my internal lan.
Regarding maximum udp datagram size:
net.inet.udp.maxdgram=63535
Apparently, sysctl on linux/debian does NOT support this. I have pinged
debian-user on this issue; but, there has been NO response. I do NOT
know what the current, default size is; nor do I know how to change it.
I prefer NOT to combine DLE's; which will pose other challenges, not the
least of which is DLE larger than tape. These DLE's are very dynamic.
I cannot predict when a particular DLE will contain enormous data; and
the nature of this dynamic data is already compressed ...
What am I missing? This used to work; then, it b0rk; and the only
change was a newer amanda version.
What do you think?
diff -u -r --show-c-function --exclude-from=amanda.diff amanda-2.5.0p2.orig/server-src/amcheck.c amanda-2.5.0p2.new/server-src/amcheck.c
--- amanda-2.5.0p2.orig/server-src/amcheck.c 2006-05-12 15:26:12.0 -0400
+++ amanda-2.5.0p2.new/server-src/amcheck.c 2006-05-25 10:11:46.0 -0400
@@ -1329,7 +1332,7 @@ void start_host(hostp)
/*
* Allow 2X for err response.
*/
- if(req_len + l_len MAX_PACKET / 2) {
+ if(req_len + l_len = MAX_PACKET) {
amfree(l);
break;
}
diff -u -r --show-c-function --exclude-from=amanda.diff amanda-2.5.0p2.orig/server-src/planner.c amanda-2.5.0p2.new/server-src/planner.c
--- amanda-2.5.0p2.orig/server-src/planner.c 2006-04-24 07:16:43.0 -0400
+++ amanda-2.5.0p2.new/server-src/planner.c 2006-05-25 10:11:28.0 -0400
@@ -1338,7 +1338,7 @@ am_host_t *hostp;
/*
* Allow 2X for err response.
*/
- if(req_len + s_len MAX_PACKET / 2) {
+ if(req_len + s_len = MAX_PACKET) {
amfree(s);
break;
}
Re: missing result ... in ... response ???
* Jean-Louis Martineau [EMAIL PROTECTED] [2006:05:25:10:16:56-0400] scribed: Michael, If the problem is that you have too many DLE for a udp packet, try the attached patch which will double the size of the packet. Thank you, for your participation in this matter. Yes, I can get this source, and compile it myself. However, I have two issues with that solution: [1] Did this _change_ between v2.4.5 and v2.5.x? If so, why? If so, at which version? Perhaps, I can down-grade? [2] One reason for using debian is, package management is so easy. Managing one, or dozens, or hundreds of personally compiled programs is a mess that I prefer to avoid. what do you think? -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- signature.asc Description: Digital signature
Re: missing result
Christoph Scheeder wrote: Iulian Topliceanu schrieb: Hi, After upgrading a client to amanda 2.4.5 on a RH9 the following problem has occured: I have 115 DLE for that client, and since upgrading, 14 volumes faile to be backuped. The *same* 14 volumes. I'm getting this: FAILURE AND STRANGE DUMP SUMMARY: planner: ERROR Request to client timed out. client /data/data0/share1/Technik_Betrieb lev 0 FAILED [missing result for /data/data0/share1/Technik_Betrieb in client response] client /data/data0/share1/Studenten lev 0 FAILED [missing result for /data/data0/share1/Studenten in client response] The weird thing is that non of the these 14 volumes appear in sendsize.*.debug so I can't offer you any details. I've erased all the other DLE's from the 'disklist' and left only these 14 volumes. The backup went fine without any errors. What could be the problem? Regards, Iulian Topliceanu Hm, could it be a problem with the maximum UDP-packet size? you have many DLE's, so perhaps the request packet gets truncated at the client side. Christoph Yes, It what because of the maximum UDP-packet size. I've decreased the number of the DLE's and everything worked fine. Thanks for the help, Iulian begin:vcard fn:Iulian Topliceanu n:Topliceanu;Iulian org:;Operations adr:;;Moersenbroicher Weg 200;Duesseldorf;NRW;D-40470;net mobile AG email;internet:[EMAIL PROTECTED] url:http://www.net-m.de version:2.1 end:vcard
Re: missing result
Iulian Topliceanu schrieb: Hi, After upgrading a client to amanda 2.4.5 on a RH9 the following problem has occured: I have 115 DLE for that client, and since upgrading, 14 volumes faile to be backuped. The *same* 14 volumes. I'm getting this: FAILURE AND STRANGE DUMP SUMMARY: planner: ERROR Request to client timed out. client /data/data0/share1/Technik_Betrieb lev 0 FAILED [missing result for /data/data0/share1/Technik_Betrieb in client response] client /data/data0/share1/Studenten lev 0 FAILED [missing result for /data/data0/share1/Studenten in client response] The weird thing is that non of the these 14 volumes appear in sendsize.*.debug so I can't offer you any details. I've erased all the other DLE's from the 'disklist' and left only these 14 volumes. The backup went fine without any errors. What could be the problem? Regards, Iulian Topliceanu Hm, could it be a problem with the maximum UDP-packet size? you have many DLE's, so perhaps the request packet gets truncated at the client side. Christoph
Re: missing result
What causes missing results? Usually a timeout. Take a look at /tmp/amanda/sendsize*debug on the client and figure out the total time (look at the first and last lines). Amanda allows five minutes per disk. If that's not enough, crank up the etimeout value in amanda.conf. george herson John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
RE: missing result for...
8 SEQ 975476700 = ------------ ----- = Thanks again for your time. -Original Message- From: John R. Jackson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 28, 2000 8:21 PM To: Joe Prochazka Cc: [EMAIL PROTECTED] Subject: Re: missing result for... In addition to what you sent, I asked whether "amcheck -c config" worked and what was in /tmp/amanda/amandad*debug. It looks like sendsize is starting but never completing. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result for...
sendsize: reading /etc/amandates: Is a directory I swear I'm going to get rid of that damned thing :-). /etc/amandates is supposed to be a file, not a directory. Do this: # rm -fr /etc/amandates # touch /etc/amandates # chown amanda-user /etc/amandates Just for curiosity, did you create (mkdir) /etc/amandates? If so, why? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result in amanda 2.4.2
Here's what's in sendsize.debug: sendsize: debug 1 pid 3614 ruid 11 euid 11 start time Mon Nov 27 23:11:42 2000 /usr/lib/amanda/sendsize: version 2.4.1p1 amandad.debug is pretty long, but also has references to 2.4.1p1. I guess the old one isn't gone. I'll try removing it "better", and then recompiling. Thanks, Dylan - Original Message - From: "John R. Jackson" [EMAIL PROTECTED] To: "Dylan Casey" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 28, 2000 12:36 AM Subject: Re: missing result in amanda 2.4.2 ... So, I downloaded 2.4.2, and after some stuggling with the configure command, got it setup. amcheck runs fine, but now _none_ of the disks get backed up! Here are the errors: ... What's in /tmp/amanda/sendsize*debug and amandad*debug on ettin? Dylan Casey John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result in amanda 2.4.2
Hi, Thanks for the help. I removed 2.4.1p1 and installed 2.4.2 again. I had to do a couple of tries on the configuring, but eventually got it to work. The last problem was finding out that I had to put in the amandates file. Once I did that, everthing worked just fine with gnu tar (dump still doesn't work with the big disk). Thanks again, Dylan - Dylan P. Casey email:[EMAIL PROTECTED] Michigan State University office:517-432-0216 home:810-695-8615 On Tue, 28 Nov 2000, John R. Jackson wrote: ... So, I downloaded 2.4.2, and after some stuggling with the configure command, got it setup. amcheck runs fine, but now _none_ of the disks get backed up! Here are the errors: ... What's in /tmp/amanda/sendsize*debug and amandad*debug on ettin? Dylan Casey John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result in amanda 2.4.2
Once I did that, everthing worked just fine with gnu tar ... Glad to hear it. (dump still doesn't work with the big disk). What do you mean? If you're using Linux, make sure you get the latest version of dump from SourceForge. It's maintanence was nil for a long time and it had serious problems, which have recently (months) become vastly improved. Dylan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result in amanda 2.4.2
I am running Linux. I have a dump 0.4b9-1 ... As I recall, that's **way** too old. ... Before I go to the work of installing it, are there good reasons to prefer dump to gnu-tar or vice versa? Oh, no. Here we go on this subject again :-). Yes, there are reasons. But for every one side A gives, side B has a counter, so it's mostly philosophical. Pick what you're comfortable with. I will throw in that GNU tar alters the last access time of every file backed up, and that's the main reason I don't use it. Dylan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result for...
Anyone have any ideas as to why I am getting this report back. ... localhost /var/log lev 0 FAILED [missing result for /var/log in localhost response] Does amcheck work? What's in /tmp/amanda/amandad*debug? How about sendsize*debug? Any core file in /tmp/amanda? Take a look at the amdump.1 file and see if it has anything interesting to say, especially towards the end. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result for...
In addition to what you sent, I asked whether "amcheck -c config" worked and what was in /tmp/amanda/amandad*debug. It looks like sendsize is starting but never completing. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing result in amanda 2.4.2
--- "John R. Jackson" [EMAIL PROTECTED] wrote: I am running Linux. I have a dump 0.4b9-1 ... As I recall, that's **way** too old. ... Before I go to the work of installing it, are there good reasons to prefer dump to gnu-tar or vice versa? Oh, no. Here we go on this subject again :-). Yes, there are reasons. But for every one side A gives, side B has a counter, so it's mostly philosophical. Pick what you're comfortable with. I will throw in that GNU tar alters the last access time of every file backed up, and that's the main reason I don't use it. I typed a reply, hit a key stroke and landed back in my inbox, so if this comes across twice that's why. I made note for myself that didn't include enough data for me to be able to decipher: "Tar --atime-preserve" But I do remember this keeps tar from changing the last-access time of files as it backs them up. This doesn't look like a tar option so is it an option for the configure script of AMANDA? If so does this resolve your issue with tar? I read that the amverify is much more reliable with tar than dump. That's good enough for me. Randy Cordell Dylan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: missing result in amanda 2.4.2
On Nov 29, 2000, Randolph Cordell [EMAIL PROTECTED] wrote:
"Tar --atime-preserve" But I do remember this keeps tar from
changing the last-access time of files as it backs them up.
Which forces it to change the inode update time, that makes each file
seem out-of-date on the next run.
This doesn't look like a tar option
It is a GNU tar option.
so is it an option for the configure script of AMANDA?
Nope. You have to tweak some define in
client-src/send{size,backup-gnutar}.c for Amanda to use this option.
But you don't want to do that.
I read that the amverify is much more reliable with tar than dump.
Yep. amverify will only check a DUMP image if it was created on a
similar system as that on which you run amverify. Even then, restore
will only check the dump header. tar, OTOH, will go over the whole
tar image.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: missing result in amanda 2.4.2
... So, I downloaded 2.4.2, and after some stuggling with the configure command, got it setup. amcheck runs fine, but now _none_ of the disks get backed up! Here are the errors: ... What's in /tmp/amanda/sendsize*debug and amandad*debug on ettin? Dylan Casey John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
