There are no chunker debug files. I couldn't see any, walking through the directories in
/tmp/amanda, and then I did`# find /tmp/amanda -name *chunker*`, and it came back with nothing.
--------------
in amdump.1 log file, I found:
driver: hdisk-state time 2935.228 hdisk 0: free 3492775072 dumpers 3 hdisk
1: free 3485259712
dumpers 3
Can't locate Amanda/Chunker/Controller.pm: Permission denied at
/usr/local/libexec/amanda/chunker line 32.
BEGIN failed--compilation aborted at /usr/local/libexec/amanda/chunker line
32.
Can't locate Amanda/Chunker/Controller.pm: Permission denied at
/usr/local/libexec/amanda/chunker line 32.
etc...
Then locating Controller.pm, I found:
root@marlin:/usr/local/share/perl/5.18.2/Amanda# ls -l Chunker
total 48
-rw-r--r-- 1 root root 21619 Aug 21 15:51 Controller.pm
-rw-r--r-- 1 root root 3088 Aug 21 15:51 Protocol.pm
-rw-r--r-- 1 root root 17091 Aug 21 15:51 Scribe.pm
So the problem appears to be something I had run into a couple of years ago (in 3.3.x) and reported
at that time. Amanda's `make install` puts these files in without setting the permissions. The
resulting permissions don't allow them to be executed. This is the case throughout the
/usr/local/share/perl/5.18.2/Amanda/ directory and all its subdirectories.
I reset the permissions. I'm hoping that does it, and that Amanda will run
properly tonight.
----------------
Before setting the permissions on the perl modules for Amanda, the chunker would not run from the
command line. It gave the same error as reported in the log file above. After setting the
permissions, it ran from the command line and there were no errors in /tmp/tmp-chunker-log, just the
starting INFO line.
Should be fixed.
On 8/23/17 12:28 PM, Jean-Louis Martineau wrote:
Can you post the chunker debug files?
Look for error in amdump.1 log file
Can you try to run the chunker from the command line?
/path/to/chunker CONFIG --log-file /tmp/tmp-chunker-log
Jean-Louis
On 23/08/17 11:42 AM, Chris Hoogendyk wrote:
> I updated from Amanda 3.3.6 to Amanda 3.4.5 by building from source.
> The example amanda.conf didn't look much different from what I was
> running, so, initially, I ran it with the same amanda.conf file. We
> had changed out the SSDs being used for holding space, and the new 4TB
> SSDs were set up with permissions 755 amanda:amanda. I changed the
> amanda.conf to point to them (/amanda3 and /amanda4).
>
> The run last night failed on all DLEs, with:
>
> FAILURE DUMP SUMMARY:
> amreport: ERROR '/usr/local/etc/amanda/daily/amanda.conf', line
> 74: warning: Keyword usetimestamps is deprecated.
> localhost /etc lev 0 FAILED [chunker1 died]
> localhost /usr/local lev 1 FAILED [chunker1 died]
> localhost/home/bio/evazey/./evazey1 lev 1 FAILED [chunker0 died]
> localhost/home/bio/evazey/./evazey2 lev 0 FAILED [chunker1 died]
> localhost/home/bio/evazey/./evazey3 lev 0 FAILED [chunker1 died]
> etc. ...
>
> The holding space was completely empty.
>
> The file /tmp/amanda/server/daily/driver.20170822233002.debug had
> lines in it like:
>
> Wed Aug 23 00:18:58.716563539 2017: pid 4470: thd-0xa78000: driver:
> rename_tmp_holding: open of
> /amanda4/20170822233002/localhost._home_bio_evazey_._evazey3.0.tmp
> failed: No such file or directory
>
> Is it possible that it is as simple as the deprecated usetimestamps
> being actually worse than just deprecated?
>
> I'm continuing to look through things, but I wanted to get this off to
> the list while it was still early in my day.
>
>
*Disclaimer*
This message is the property of *CARBONITE, INC.* <http://www.carbonite.com> and may contain
confidential or privileged information.
If this message has been delivered to you by mistake, then do not copy or deliver this message to
anyone. Instead, destroy it and notify me by reply e-mail.
--
---------------
Chris Hoogendyk
-
O__ ---- Systems Administrator
c/ /'_ --- Biology & Geosciences Departments
(*) \(*) -- 315 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst
<hoogen...@bio.umass.edu>
---------------
Erdös 4
