what is this
I found these files and directory being created upon boot, in the /tmp directory. Do they have anything to do with Amanda? Thank you in advance for any help you may be able to offer. Regards Fred James [where am i]$ ls -ltr /tmp total 40 -rw-r--r--1 root root 62 Jun 7 16:56 pdf.log drwx--2 backups backups 4096 Jun 7 16:56 orbit-backups/ [where am i]$ rm /tmp/fred rm: remove regular file `/tmp/fred'? y [where am i]$ ls -ltr /tmp/orbi* total 4 srwxr-xr-x1 backups backups 0 Jun 7 16:56 linc-902-0-3d60e2e4a4dea= srwxrwxr-x1 backups backups 0 Jun 7 16:56 linc-8c3-0-629270b0add34= srwxrwxr-x1 backups backups 0 Jun 7 16:56 linc-904-0-253f0dcca4a07= -rw-rw-r--1 backups backups 661 Jun 7 16:56 bonobo-activation-server-ior -rwx--1 backups backups 0 Jun 7 16:56 bonobo-activation-register.lock* srwxrwxr-x1 backups backups 0 Jun 7 16:56 linc-908-0-7e61a91484ec1= srwxrwxr-x1 backups backups 0 Jun 7 16:56 linc-912-0-456ffb6289926= srwxrwxr-x1 backups backups 0 Jun 7 16:56 linc-916-0-472801fca7cdf= srwxrwxr-x1 backups backups 0 Jun 7 16:56 linc-918-0-35348657409cd= srwxrwxr-x1 backups backups 0 Jun 7 16:56 linc-926-0-1a633543e6252= srwxrwxr-x1 backups backups 0 Jun 7 16:56 linc-928-0-66813f2ec41f5= [ -- ...we are fellow passengers...
Re: /dev/null caused backups to fail
On Mon, Jun 07, 2004 at 04:15:47PM +0200, Paul Bijnens wrote:
> + error("%s: open /dev/null returned: %s", cmd, strerror(errno));
May I suggest a wording change in the message: "failed" instead
of "returned". Besides the nit-picky observation that what was
*returned* was -1, it's better to state explicitly that it was a
failure, rather then leaving the reader to infer it.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
| | /
It must be said that they would have sounded better if the singer
wouldn't throw his fellow band members to the ground and toss the
drum kit around during songs.
- Patrick Lenneau
Re: sporadic errors - could not connect ...
Hi, Frank, on Montag, 07. Juni 2004 at 17:43 you wrote to amanda-users: FS> Did you configure Amanda with one of the 'portrange' options and not allow FS> enough ports to accomodate the number of hosts you dump in parallel? Exactly what I thought ;-) -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: sporadic errors - could not connect ...
--On Monday, June 07, 2004 13:18:49 +0200 Oliver Simon <[EMAIL PROTECTED]> wrote: > Hi List ! > > Were great anyone could help ... > > We are experiencing strange errors at the time. > We have an amand-server that backs up about 30 hosts a night. > Most of the time it went well, but now there are very often etrange errors. > > It sais: > > x /opt lev 0 FAILED 20040606[could not connect to x] > > And that on about 15 of 30 hosts. The more interesting is, that the first > filesystems (or dle´s) are fine, only some of them are failing. > Next day everything is fine, or other filesystems on other hosts are failing .. !? > On some days > There seem to be no networking problems, all hosts are 100 Mbit connected by a 1 > Gbit HP Switch separated in VLANS. Did you configure Amanda with one of the 'portrange' options and not allow enough ports to accomodate the number of hosts you dump in parallel? Frank > The amanda-server is a 1GHz Pentium 3 with 2 2TB RAids attached to it, so Space > should not be the problem. > I wrote a little script, that monitors wih amdump the backup every 3 minutes in a > file named date-time, but the output doesnt´t give any hints ... > Neither the amanda-server, nor the clients tell anything in the log-files ... !? > > Would it be an idea to set (if existent) a higher debug-level at the amanda-server, > and where should i do that ? > > Thanks in Advance ... > > ...olli -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: /dev/null caused backups to fail
In a message dated: Mon, 07 Jun 2004 16:15:47 +0200 Paul Bijnens said: >Besides the fact that a LOT of programs will fail mysteriously when >/dev/null has been tampered with, here is a patch for sendsize.c . Thanks! >ps. Ever replaced /dev/null with a plain file by accident? :-) M, can I plead the 5th ? ;) >PPS. patch not tested to verify it it really detects the problem :-) Thanks for the warning :) -- Seeya, Paul GPG Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE If you're not having fun, you're not doing it right!
Re: Problem: cannot overwrite active tape
On Mon, Jun 07, 2004 at 10:16:29AM +0200, Sebastian Kösters wrote: > Hi! > > I don't use real tapes. It's 680GB Raid-System and so these tapes are > virtual. I created one tape and made a test-backup. It is the first time > that I use Amanda and I don't know how to create another blank tape on my > raid. You created one vtape, right? How did you do that? It has been a while since I've done it, but if I recall correctly you made a directory that was to be the vtape, put in that directory a subdirectory called data, and used amlabel. Make some more, the same way but with different names and labels. Don't trust my memory (or yours), see the HOW-TO in the docs directory. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: /dev/null caused backups to fail
[EMAIL PROTECTED] wrote:
All file systems on one of my backup clients failed over the weekend.
The dump summary thinks the system was offline, but it wasn't, and
the amadad debug log had this in it:
amandad: time 0.016: amandahosts security check passed
amandad: time 0.016: running service "/usr/lib/amanda/sendsize"
sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor]
...
After digging through all this, I tried seeing what amcheck revealed
(which I should have done first It stated:
ERROR: jpt: [can not read/write /dev/null: Permission denied]
Evidently, from what I can tell, /dev/null's permissions were changed
sometime on Friday (16:42 to be precise) after my cron-driven amcheck runs.
Is there any way to have amanda mention in the summary report that
the reason a backup failed was because /dev/null was not writeable?
Besides the fact that a LOT of programs will fail mysteriously when
/dev/null has been tampered with, here is a patch for sendsize.c .
ps. Ever replaced /dev/null with a plain file by accident? :-)
PPS. patch not tested to verify it it really detects the problem :-)
--
Paul Bijnens, XplanationTel +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, *
* kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...*
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***
--- sendsize.c_ORIG 2004-06-07 16:08:12.0 +0200
+++ sendsize.c 2004-06-07 16:07:04.0 +0200
@@ -797,6 +797,9 @@
rundump_cmd = stralloc(cmd);
stdoutfd = nullfd = open("/dev/null", O_RDWR);
+if (nullfd < 0) {
+ error("%s: open /dev/null returned: %s", cmd, strerror(errno));
+}
pipefd[0] = pipefd[1] = killctl[0] = killctl[1] = -1;
pipe(pipefd);
Re: sporadic errors - could not connect ...
Hi, Oliver, on Montag, 07. Juni 2004 at 13:18 you wrote to amanda-users: OS> It sais: OS> x /opt lev 0 FAILED 20040606[could not connect to x] OS> And that on about 15 of 30 hosts. The more interesting is, that the OS> first filesystems (or dle´s) are fine, only some of them are failing. OS> Next day everything is fine, or other filesystems on other hosts are OS> failing .. !? Is that setup working through a firewall? -- regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
/dev/null caused backups to fail
All file systems on one of my backup clients failed over the weekend. The dump summary thinks the system was offline, but it wasn't, and the amadad debug log had this in it: amandad: time 0.016: amandahosts security check passed amandad: time 0.016: running service "/usr/lib/amanda/sendsize" sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor] sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor] sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor] sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor] sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor] sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor] sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor] sendsize: error [spawn /usr/lib/amanda/runtar: dup2 in: Bad file descriptor] amandad: time 0.566: sending REP packet: The sendsize debug log also reveals: # grep 'no size line' sendsize.20040605234503.debug sendsize[30741]: no size line match in /bin/tar output for "/u1/backup/all" sendsize[30742]: no size line match in /bin/tar output for "/u1/backup/aog" sendsize[30745]: no size line match in /bin/tar output for "/u1/backup/archive" sendsize[30747]: no size line match in /bin/tar output for "/u1/backup/bfb" sendsize[30749]: no size line match in /bin/tar output for "/u1/backup/cvs-repos" sendsize[30751]: no size line match in /bin/tar output for "/u1/backup/pd" sendsize[30753]: no size line match in /bin/tar output for "/u1/backup/rt" sendsize[30755]: no size line match in /bin/tar output for "/u1/backup/sw" After digging through all this, I tried seeing what amcheck revealed (which I should have done first :) It stated: ERROR: jpt: [can not read/write /dev/null: Permission denied] Evidently, from what I can tell, /dev/null's permissions were changed sometime on Friday (16:42 to be precise) after my cron-driven amcheck runs. Is there any way to have amanda mention in the summary report that the reason a backup failed was because /dev/null was not writeable? Thanks, -- Seeya, Paul GPG Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE If you're not having fun, you're not doing it right!
Re: sporadic errors - could not connect ...
Oliver Simon wrote: x /opt lev 0 FAILED 20040606[could not connect to x] ... Would it be an idea to set (if existent) a higher debug-level at the amanda-server, and where should i do that ? I would look in the client(s) in the directory /tmp/amanda and there should be files with a datetimestamp. Have a look in there, especially in amandad..debug. Compare them with a host or DLE that does succeed. Post them if they still look normal to you (or mail to me, if privacy is a concern). -- Paul Bijnens, XplanationTel +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, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
sporadic errors - could not connect ...
Hi List ! Were great anyone could help ... We are experiencing strange errors at the time. We have an amand-server that backs up about 30 hosts a night. Most of the time it went well, but now there are very often etrange errors. It sais: x /opt lev 0 FAILED 20040606[could not connect to x] And that on about 15 of 30 hosts. The more interesting is, that the first filesystems (or dle´s) are fine, only some of them are failing. Next day everything is fine, or other filesystems on other hosts are failing .. !? On some days There seem to be no networking problems, all hosts are 100 Mbit connected by a 1 Gbit HP Switch separated in VLANS. The amanda-server is a 1GHz Pentium 3 with 2 2TB RAids attached to it, so Space should not be the problem. I wrote a little script, that monitors wih amdump the backup every 3 minutes in a file named date-time, but the output doesnt´t give any hints ... Neither the amanda-server, nor the clients tell anything in the log-files ... !? Would it be an idea to set (if existent) a higher debug-level at the amanda-server, and where should i do that ? Thanks in Advance ... ...olli
Re: AW: Problem: cannot overwrite active tape
Hi, Sebastian, on Montag, 07. Juni 2004 at 10:16 you wrote to amanda-users: SK> Hi! SK> I don't use real tapes. It's 680GB Raid-System and so these tapes are SK> virtual. I created one tape and made a test-backup. It is the first time SK> that I use Amanda and I don't know how to create another blank tape on my SK> raid. SK> Hope this explanation is better? You have to amlabel your tapes, even your vtapes. Follow HOWTO-FILE-DRIVER in the docs. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
AW: Problem: cannot overwrite active tape
Hi! I don't use real tapes. It's 680GB Raid-System and so these tapes are virtual. I created one tape and made a test-backup. It is the first time that I use Amanda and I don't know how to create another blank tape on my raid. Hope this explanation is better? -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Jon LaBadie Gesendet: Freitag, 4. Juni 2004 20:27 An: [EMAIL PROTECTED] Betreff: Re: Problem: cannot overwrite active tape On Fri, Jun 04, 2004 at 05:45:25PM +0200, Sebastian Ksters wrote: > I only want to create more then one tabes but don´t know what to do to > create more tabes?! > > -Ursprüngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im > Auftrag von Jon LaBadie > Gesendet: Freitag, 4. Juni 2004 17:32 > An: [EMAIL PROTECTED] > Betreff: Re: Problem: cannot overwrite active tape > > On Fri, Jun 04, 2004 at 05:32:30PM +0200, Sebastian Kösters wrote: > > Thank your for the help. > > > > The tapecycle parameter is active und set to 14. > > But how could I create more tapes? > > > > I created the first tape with "amlabel DailySet1 DailySet100" now I tried > to > > create another tape with "amlabel DailySet1 DailySet101" but then the > > following error message comes: > > > > rewinding, reading label DailySet100, tape is active > > rewinding > > tape not labelled > > > > What must I do to create more tapes? > ... > > > > -Ursprüngliche Nachricht- > > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Im > > Auftrag von Jon LaBadie > > Gesendet: Freitag, 4. Juni 2004 17:02 > > An: [EMAIL PROTECTED] > > Betreff: Re: Problem: cannot overwrite active tape > > > > On Fri, Jun 04, 2004 at 04:45:36PM +0200, Sebastian Kösters wrote: > > > Hi! > > > > > > I got a Problem with Amanda. > > > > > > I did a backup with amdump <>. > > > > > > Doing the backup works fine but making a amcheck <> after the > > > backup (before the backup is everything ok) says the following error : > > > cannot overwrite active tape DailySet100. > > > After making the backup it is not possible to do the backup once again. > > > > > > What must I do to make it work correctly? > > > > Amanda works on the assumption that you have many/several/more-than-one > > tape that will be used for backups. It cycles through those tapes, > > using one or more for each amdump run. You specify the "minimum" > > number of tapes in the cycle with the "tapecycle" parameter. Each > > tape must be uniquely labeled with the amlabel command before use. > > > > I don't know what you are doing. > Are you putting in the same tape each time? > It can't have the two labels. > Don't use the same tape, label 14 separate tapes. > If you somehow have multiple tapes with the same > label, or you for some reason need to change a > tapes label, use the '-f' option of amlabel. > Put a tape, blank or otherwise unused by amanda, in the drive and use amlabel. Am I missing something? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
