Re: big update killed 1 host
On Mon, Jan 30, 2017 at 02:07:46PM -0500, Jean-Louis Martineau wrote: > Jon, > > Why systemd print the ExecStart on the socket? it's a systemd bug or a > misconfiguration. > > Jean-Louis > I don't know that "systemd" is printing the string. I simply said the string matches what is in the amanda@.service file. To be more precise, the debug file shows character by character the reads from the socket. It is 'g' ':' '' "the string" '' I modified the string in amanda@.service and the mods showed up in the debug file. Any ideas what might be the misconfiguration? On Mon, Jan 30, 2017 at 08:23:55PM +0100, Stefan G. Weichinger wrote: > Am 2017-01-30 um 20:07 schrieb Jean-Louis Martineau: > > Jon, > > > > Why systemd print the ExecStart on the socket? it's a systemd bug or a > > misconfiguration. > > correct, it should be in amanda@.service > > -> (on gentoo linux): > > # cat /usr/lib64/systemd/system/amanda@.service ... > # cat /usr/lib64/systemd/system/amanda.socket ... While my corresponding files vary slightly from yours, I pulled copies from a backup. They have not changed from before the updates and amanda was running fine. Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: big update killed 1 host
Am 2017-01-30 um 20:07 schrieb Jean-Louis Martineau: > Jon, > > Why systemd print the ExecStart on the socket? it's a systemd bug or a > misconfiguration. correct, it should be in amanda@.service -> (on gentoo linux): # cat /usr/lib64/systemd/system/amanda@.service [Unit] Description=Amanda Backup System After=local-fs.target [Service] User=amanda Group=amanda ExecStart=/usr/libexec/amanda/amandad -auth=bsdtcp amdump amindexd amidxtaped StandardInput=socket StandardOutput=socket # cat /usr/lib64/systemd/system/amanda.socket [Unit] Description=Amanda Socket [Socket] ListenStream=10080 Accept=true [Install] WantedBy=sockets.target
Re: big update killed 1 host
Jon, Why systemd print the ExecStart on the socket? it's a systemd bug or a misconfiguration. Jean-Louis On 30/01/17 12:38 AM, Jon LaBadie wrote: > Follow-up, > > amrecover gives the same error whether run from the server/client > or from another client. > > On the server/client I also ran: > >$ amservice mums.jgcomp.com bsdtcp noop < /dev/null >Request failed: tcpm_recv_token: invalid size: "Executing: \ >/usr/sbin/amandad -auth=bsdtcp amdump amdumpd\n" > > According to one wiki document, > >http://wiki.zmanda.com/index.php/Selfcheck_request_failed > > this suggests a failure in bsdtcp authentication. > > BTW the string "/usr/sbin/amandad -auth=bsdtcp amdump amdumpd" > matches the "ExecStart=" value in the systemd service file > "/usr/lib/systemd/system/amanda@.service". > > > On Sun, Jan 29, 2017 at 10:45:37PM -0500, Jon LaBadie wrote: >> I added updates to my CentOS Amanda server that >> changed the OS release from 7.2 to 7.3. Amanda >> version remained at 3.3.3. Before update, all >> clients including the server were working fine. >> >> After the update, all clients backed up fine >> except the server itself. >> >> amcheck -c gives an error: >>tcpm_recv_token: Invalid size. >> >> The amcheck debug file ends with reading a string >> from a socket and saying: >> >>amcheck-clients: tcpm_recv_token: invalid size "Executing: >> /usr/sbin/amandad \ >> -auth=bsdtcp amdump amdumpd\n" >>amcheck-clients: security_stream_seterr(0x7f6be589fac0, tcpm_recv_token: \ >> invalid size: "Executing: /usr/sbin/amandad \ >> -auth=bsdtcp amdump amdumpd\n") >> >> The amandad debug file contains these lines: >> >>amandad: security_stream_seterr(0x7fcfccf15e00, write error to: \ >> Bad file descriptor) >>amandad: security_seterror(handle=0x7fcfccf14f00, driver=0x7fcfcac0f7e0 \ >> (BSDTCP) error=write error to: Bad file descriptor) >> >> The problem is neither firewall nor selinux >> related as I've turned both off and still see >> the same error. >> >> Ideas? >> >> Jon >> -- >> Jon H. LaBadie j...@jgcomp.com >> 11226 South Shore Rd. (703) 787-0688 (H) >> Reston, VA 20190 (703) 935-6720 (C) End of included message <<<
big update killed 1 host
I added updates to my CentOS Amanda server that changed the OS release from 7.2 to 7.3. Amanda version remained at 3.3.3. Before update, all clients including the server were working fine. After the update, all clients backed up fine except the server itself. amcheck -c gives an error: tcpm_recv_token: Invalid size. The amcheck debug file ends with reading a string from a socket and saying: amcheck-clients: tcpm_recv_token: invalid size "Executing: /usr/sbin/amandad \ -auth=bsdtcp amdump amdumpd\n" amcheck-clients: security_stream_seterr(0x7f6be589fac0, tcpm_recv_token: \ invalid size: "Executing: /usr/sbin/amandad \ -auth=bsdtcp amdump amdumpd\n") The amandad debug file contains these lines: amandad: security_stream_seterr(0x7fcfccf15e00, write error to: \ Bad file descriptor) amandad: security_seterror(handle=0x7fcfccf14f00, driver=0x7fcfcac0f7e0 \ (BSDTCP) error=write error to: Bad file descriptor) The problem is neither firewall nor selinux related as I've turned both off and still see the same error. Ideas? Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: big update killed 1 host
Am 2017-01-30 um 06:38 schrieb Jon LaBadie: > Follow-up, > > amrecover gives the same error whether run from the server/client > or from another client. > > On the server/client I also ran: > > $ amservice mums.jgcomp.com bsdtcp noop < /dev/null > Request failed: tcpm_recv_token: invalid size: "Executing: \ > /usr/sbin/amandad -auth=bsdtcp amdump amdumpd\n" > > According to one wiki document, > > http://wiki.zmanda.com/index.php/Selfcheck_request_failed > > this suggests a failure in bsdtcp authentication. > > BTW the string "/usr/sbin/amandad -auth=bsdtcp amdump amdumpd" > matches the "ExecStart=" value in the systemd service file > "/usr/lib/systemd/system/amanda@.service". maybe I misunderstand, but on the amanda *server* you need: ExecStart=/usr/sbin/amandad -auth=bsdtcp amdump amindexd amidxtaped as far as I understand. amandad has to "provide" index services as well. I don't know of any "amdumpd" so far (?)
amsamba NT_STATUS_INVALID_PARAMETER for some shares?
Hi, I am using AMANDA 3.39 and amsamba with the latest patches (amsamba, utf) installed. In the selfcheck.20170130131748.debug I find the following error. Mon Jan 30 13:17:48 2017: thd-0x56311847e000: selfcheck: Executing: /usr/bin/lsb_release '--id' '-s' Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: Executing: /usr/bin/lsb_release '--description' '-s' Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: pid 27070 ruid 34 euid 34 version 3.3.9: rename at Mon Jan 30 13:17:49 2017 Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: checking disk //192.168.0.248/service_svn2 Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: Spawning "/usr/lib/amanda/application/amsamba amsamba support --config a2g-5 --host localhost --disk //192.168.0.248/se rvice_svn2 --device //192.168.0.248/service_svn2" in pipeline Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: CONFIG YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: HOST YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: DISK YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: MAX-LEVEL 1 Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: INDEX-LINE YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: INDEX-XML NO Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: MESSAGE-LINE YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: MESSAGE-XML NO Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: RECORD YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: COLLECTION NO Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: MULTI-ESTIMATE NO Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: CALCSIZE NO Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: CLIENT-ESTIMATE YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: EXCLUDE-FILE YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: EXCLUDE-LIST YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: EXCLUDE-OPTIONAL YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: INCLUDE-FILE YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: INCLUDE-LIST YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: INCLUDE-OPTIONAL YES Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: support line: RECOVER-MODE SMB Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: Spawning "/usr/lib/amanda/application/amsamba amsamba selfcheck --message line --config a2g-5 --host localhost --disk / /192.168.0.248/service_svn2 --device //192.168.0.248/service_svn2 --index line --record --amandapass /etc/amandapass" in pipeline Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: Application 'amsamba': exited with status 1 Mon Jan 30 13:17:49 2017: thd-0x56311847e000: selfcheck: checking disk //192.168.0.248/service_svn Manual execution of amsamba shows this backup@chronos:/usr/lib/amanda/application$ /usr/lib/amanda/application/amsamba selfcheck --message line --config a2g-5 --host localhost --disk //192.168.0.248/service_svn2 --device //192.168.0.248/service_svn2 --index line --record --amandapass /etc/amandapass OK disk //192.168.0.248/service_svn2 OK amsamba version 3.3.9 OK amsamba smbclient-version 4.5.2-Debian OK /usr/bin/smbclient OK //192.168.0.248/service_svn2 OK //192.168.0.248/service_svn2 ERROR smbclient: protocol negotiation failed: NT_STATUS_INVALID_PARAMETER - Mounting the directory with mount -t cifs works without a problem. - Other (newer) network shares work too. Any idea what could be the problem? Still a 'compatibilty' problem in amsamba? Greetings and thanks Tobias
