Hi all,
I've been using Amanda v2.5 for years an switched to v3.3.6 on freshly
installed FC21 server and all clients (SLES11) a few days ago. My
configuration contains the definition
define dumptype my-dump {
global
auth ssh
ssh_keys /var/lib/amanda/.ssh/id_rsa
program
The problem here is the answer you entered to set owner/mode for '.'?
is never sent to the dump process, and dump is just waiting for the answer.
The problem is not related to compression.
Some older amrecover version had problem restoring client compressed
backup, but it is fixed in newer
On Mar 30, 2015, at 11:33 AM, Jean-Louis Martineau martin...@zmanda.com wrote:
On 03/30/2015 04:05 AM, Michael Schmitz wrote:
Hi all,
I've been using Amanda v2.5 for years an switched to v3.3.6 on freshly
installed FC21 server and all clients (SLES11) a few days ago. My
configuration
On 03/30/2015 04:05 AM, Michael Schmitz wrote:
Hi all,
I've been using Amanda v2.5 for years an switched to v3.3.6 on freshly
installed FC21 server and all clients (SLES11) a few days ago. My
configuration contains the definition
define dumptype my-dump {
global
auth ssh
Here is the tail end of the amandad debug log on the failing server. It
appears that maybe a sub-process is aborting ?
OPTIONS features=9efefbff3f;
Tue Mar 31 00:45:13 2015: thd-0x7f2223302e00: amandad: tcpm_send_token: data is
still flowing
Tue Mar 31 00:45:23 2015:
A number of weeks ago, I posted a query regarding the failure of one of our
servers with the error
ERROR Request to x failed: tcpm_recv_token: invalid size
I tried all sorts of things to resolve the issue and failed miserably, then the
issue fixed itself. I felt at the time that I
it can be because a subprocess write garbage to the socket.
Check the debug files.
Jean-Louis
On 03/30/2015 02:18 PM, Glen Eustace wrote:
A number of weeks ago, I posted a query regarding the failure of one
of our servers with the error
ERROR Request to x failed: tcpm_recv_token:
