Re: Too many taper retries
Gene Heskett wrote: On Tuesday 28 April 2020 05:33, Gene Heskett wrote: I just noted that my clock was foobar, set for something in april 2020! As I have a daily rdate, is there any way to ascertain that the rdate request to the server returns a sane result before it blindly resets everything? It happened yesterday morning on cron executing my setibatch -uploads script which includes this rdate command as it finishes up. Sort of embarrasing that I missed it for nearly 2 days. rdate -p server --- outputs the result to screen rdate -s server --- sets the time Mozzi
amanda is stuck in the middle of backup
I have a strange problem with amanda my server is a Redhat linux 7.3 machine with amanda 2.4.3b3 my client is a redhat7.3 machine with a stock amanda package from redhat version 2.4.2p2 In my report for this client some backup work and some don't I got the message could not connect to molure for some of the partition. Indeed when i ran amcheck this machine coul'nt be check and i got the same message. When i log on this machine all is running except the fact than xinetd didn't spawn the amandad process. when i do a ps i found an amandad process 15933 ?Z 0:00 [amandad defunct] this process is a son of the xinetd process but when i look at amandad file related to this process all seems ok Here is the end of this file got packet: Amanda 2.4 REQ HANDLE 000-F8B70708 SEQ 1031857221 SECURITY USER dumpy SERVICE sendbackup OPTIONS hostname=molure; GNUTAR /var/spool/imap13 0 1970:1:1:0:0:0 OPTIONS |;bsd-auth;compress-fast;index;exclude-list=/usr/local/lib/amanda/exclude.gtar; sending ack: Amanda 2.4 ACK HANDLE 000-F8B70708 SEQ 1031857221 bsd security: remote host backup.int-evry.fr user dumpy local user amanda amandahosts security check passed amandad: running service /usr/lib/amanda/sendbackup amandad: sending REP packet: Amanda 2.4 REP HANDLE 000-F8B70708 SEQ 1031857221 CONNECT DATA 57421 MESG 57422 INDEX 57423 OPTIONS ;compress-fast;bsd-auth;index; amandad: got packet: Amanda 2.4 ACK HANDLE 000-F8B70708 SEQ 1031857221 amandad: pid 15933 finish time Thu Sep 12 22:17:32 2002 But the prcess stuck seems to prevent the launch of the following backup of different partition on the same machine? if i restart xinetd all run fine again but at the next backup i got again this problem. Has someone already seen that kind of problem? Thanks in advance for any help -- Eric Doutreleau I.N.T | Tel : +33 (0) 160764687 9 rue Charles Fourier | Fax : +33 (0) 160764321 91011 Evry France | email : [EMAIL PROTECTED]
Re: win32
On Thu, 12 Sep 2002 12:23:25 -0400
Galen Johnson [EMAIL PROTECTED] wrote:
JC Simonetti wrote:
amrecover is possible. You extract the tarball archive on your backup server and
upload it to the Windows box, and there you untar it with the WinTar provided with
Win32 Amanda (different of course from the GNU tar, due to NT file rights...).
amrestore is possible, but I don't like the ability of the client to log in as root
without password on the backup server, so I tested the solution but did not put it in
production. amrestore is also helped by a GUI written in Python (need to install a
Python interpreter on your Windows box, easy way but not so easy to automatically
deploy).
Have you, or will you, put the changes out for others?
Will be done. See my previous mail ;)
Can I assume from what you've been saying that you've actually gotten
the amanda-win32 project from sourceforce to compile properly? What
about the selfcheck bug? Or sendsize crashes that were reported? these
questions assume you are using amanda-win32. I've tried contacting the
current maintainer with no success. All the source files are about 18
months old and CVS hasn't been touched in as long.
Also, what version of amanda have you gotten it to work with? There was
a previous response from someone who couldn't get it to work on the more
recent code.
=G=
Well... You're right, I got the actual state of the Sourceforge project and did not
touch to anything to the sources. Everything goes well.
For your bugs :
1. selfcheck bug is not a bug, it's just that selfcheck is not provided in the Win32
version. If you are suck with the amcheck errors, do the same thing as me :
selfcheck.c : int main() {return 0;}, and if you are lazy compiling such a thing,
I've attached it here.
2. sendsize crash ? Well... Er... Er... Er... Where ??? I've had some problems with
sendsize, but it corrected itself with the -udp=10080 -no-exit parameters to the
amandad.exe program. I did not examine precisely the source code but the -no-exit
seems to be very important...
What I've done with this project? Well... Just got it from Sourceforge and installed
it on W2K boxes: what I've done is installed it as a WinNT service. I am running it
with an Amanda 2.4.3b2 server on a Linux box, and no errors reported yet (1,5 Go
backed up every night). Not checked with omre recent versions.
--
Jean-Christian SIMONETTI email: [EMAIL PROTECTED]
SysAdmin Wanadoo Portails phone: (+33)493004911
Sophia Antipolis, France
--
attachment: selfcheck.exe
Antigen Notification:Antigen found FILE FILTER= in*.exe file
Antigen for Exchange found selfcheck.exe matching FILE FILTER= in*.exe file filter. The file is currently Removed. The message, Re: win32, was sent from JC Simonetti and was discovered in IMC Queues\Inbound located at Cognex/Tokyo/WENDY.
Re: Too many taper retries
On Friday 13 September 2002 02:37, Mozzi wrote: Gene Heskett wrote: On Tuesday 28 April 2020 05:33, Gene Heskett wrote: I just noted that my clock was foobar, set for something in april 2020! As I have a daily rdate, is there any way to ascertain that the rdate request to the server returns a sane result before it blindly resets everything? It happened yesterday morning on cron executing my setibatch -uploads script which includes this rdate command as it finishes up. Sort of embarrasing that I missed it for nearly 2 days. rdate -p server --- outputs the result to screen rdate -s server --- sets the time Mozzi Uh huh, and it was rdate that messed it up in the first place, apparently accepting garbage for a bad reply. The last log entry with the right time was about 5 minutes before a cron script servicing my setiathome cache finished up by running rdate to set the time. I haven't yet changed the script, and its worked properly the last 2 times, and will be executed again in about 12 minutes. One of the reasons I'm sitting here at this time of the morning. :-( -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.15% setiathome rank, not too shabby for a WV hillbilly
Re: amanda is stuck in the middle of backup
On Friday 13 September 2002 02:57, [EMAIL PROTECTED] wrote: I have a strange problem with amanda my server is a Redhat linux 7.3 machine with amanda 2.4.3b3 my client is a redhat7.3 machine with a stock amanda package from redhat version 2.4.2p2 In my report for this client some backup work and some don't I got the message could not connect to molure for some of the partition. Indeed when i ran amcheck this machine coul'nt be check and i got the same message. When i log on this machine all is running except the fact than xinetd didn't spawn the amandad process. when i do a ps i found an amandad process 15933 ?Z 0:00 [amandad defunct] this process is a son of the xinetd process but when i look at amandad file related to this process all seems ok Here is the end of this file got packet: Amanda 2.4 REQ HANDLE 000-F8B70708 SEQ 1031857221 SECURITY USER dumpy SERVICE sendbackup OPTIONS hostname=molure; GNUTAR /var/spool/imap13 0 1970:1:1:0:0:0 OPTIONS |;bsd-auth;compress-fast;index;exclude-list=/usr/local/lib/amanda/ |exclude.gtar; sending ack: Amanda 2.4 ACK HANDLE 000-F8B70708 SEQ 1031857221 bsd security: remote host backup.int-evry.fr user dumpy local user amanda amandahosts security check passed amandad: running service /usr/lib/amanda/sendbackup amandad: sending REP packet: Amanda 2.4 REP HANDLE 000-F8B70708 SEQ 1031857221 CONNECT DATA 57421 MESG 57422 INDEX 57423 OPTIONS ;compress-fast;bsd-auth;index; amandad: got packet: Amanda 2.4 ACK HANDLE 000-F8B70708 SEQ 1031857221 amandad: pid 15933 finish time Thu Sep 12 22:17:32 2002 But the prcess stuck seems to prevent the launch of the following backup of different partition on the same machine? if i restart xinetd all run fine again but at the next backup i got again this problem. Has someone already seen that kind of problem? Thanks in advance for any help The last time I had a zombie process like that, which was blocking any new incarnations, I failed to 'kill number' it several times and finally had to reboot, but that was probably 20 kernel versions back up the log. Thats probably what you'll have to do to the machine with the zombie process. You might even consider a fresher kernel version. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.15% setiathome rank, not too shabby for a WV hillbilly
Re: Antigen Notification:Antigen found FILE FILTER= in*.exe file
On Friday 13 September 2002 03:51, ANTIGEN_WENDY wrote: Antigen for Exchange found selfcheck.exe matching FILE FILTER= in*.exe file filter. The file is currently Removed. The message, Re: win32, was sent from JC Simonetti and was discovered in IMC Queues\Inbound located at Cognex/Tokyo/WENDY. It wasn't a viri. Please go play on the interstate. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.15% setiathome rank, not too shabby for a WV hillbilly
