Solaris 11.4 issues for Amanda 3.6.0.pre2
Hi I'm testing the release on Solaris 11.4 and the good news is that autogen/configure and build works with the gcc tools provided with the system it builds the 64 binaries with native Perl. Only one Perl module was missing Encode-Locale. Still there is an issues with ambind se debug listings below. I can provide more truss debugging if needed. I guess it has never been tested on Solaris 11 ? Thanks GG Amrecover Fri May 27 18:19:56.346914960 2022: pid 7819: amrecover- [..d1ed]: security_getdriver(name=bsdtcp) returns 77994368 Fri May 27 18:19:56.347518100 2022: pid 7819: amrecover- [..d7e9]: security_handleinit(handle=10017d5e0, driver=77994368 (BSDTCP)) Fri May 27 18:19:56.348500480 2022: pid 7819: amrecover- [..d7e9]: security_streaminit(stream=1001804d0, driver=77994368 (BSDTCP)) Fri May 27 18:19:56.348663580 2022: pid 7819: amrecover- [..d7e9]: connect_port: Skip port 512: owned by exec. Fri May 27 18:19:56.348716800 2022: pid 7819: amrecover- [..d7e9]: connect_port: Skip port 513: owned by login. Fri May 27 18:19:56.348766780 2022: pid 7819: amrecover- [..d7e9]: connect_port: Skip port 514: owned by shell. Fri May 27 18:19:56.348816170 2022: pid 7819: amrecover- [..d7e9]: connect_port: Skip port 515: owned by printer. Fri May 27 18:19:56.348975230 2022: pid 7819: amrecover- [..d7e9]: make_socket opening socket with family 2 Fri May 27 18:19:56.349004870 2022: pid 7819: amrecover- [..d7e9]: make_socket opening socket with family 2: 4 Fri May 27 18:19:56.350090030 2022: pid 7819: amrecover- [..d7e9]: ambind failed: sendmsg failed A: Message too long Fri May 27 18:19:56.350158680 2022: pid 7819: amrecover- [..d7e9]: stream_client: Could not bind to port in range 512-1023. Fri May 27 18:19:56.350193430 2022: pid 7819: amrecover- [..d7e9]: security_seterror(handle=10017d5e0, driver=77994368 (BSDTCP) error=sendmsg failed A: Message too long amcheck -c daily iodomd / Amanda Backup Client Hosts Check ERROR: iodomd: selfcheck request failed: sendmsg failed A: Message too long Client check: 1 host checked in 13.007 seconds. 1 problem found. (brought to you by) Fri May 27 20:47:26.760841910 2022: pid 9701: amcheck-clients- [..edef]: security_getdriver(name=bsdtcp) returns 77994368 Fri May 27 20:47:26.761782860 2022: pid 9701: amcheck-clients- [..b3ba]: security_handleinit(handle=10046c700, driver=77994368 (BSDTCP)) Fri May 27 20:47:26.762759830 2022: pid 9701: amcheck-clients- [..b3ba]: security_streaminit(stream=100471be0, driver=77994368 (BSDTCP)) Fri May 27 20:47:26.762905150 2022: pid 9701: amcheck-clients- [..b3ba]: connect_port: Skip port 512: owned by exec. Fri May 27 20:47:26.762956770 2022: pid 9701: amcheck-clients- [..b3ba]: connect_port: Skip port 513: owned by login. Fri May 27 20:47:26.763006350 2022: pid 9701: amcheck-clients- [..b3ba]: connect_port: Skip port 514: owned by shell. Fri May 27 20:47:26.763055780 2022: pid 9701: amcheck-clients- [..b3ba]: connect_port: Skip port 515: owned by printer. Fri May 27 20:47:26.763219520 2022: pid 9701: amcheck-clients- [..b3ba]: make_socket opening socket with family 2 Fri May 27 20:47:26.763250810 2022: pid 9701: amcheck-clients- [..b3ba]: make_socket opening socket with family 2: 4 Fri May 27 20:47:26.764355740 2022: pid 9701: amcheck-clients- [..b3ba]: ambind failed: sendmsg failed A: Message too long Fri May 27 20:47:26.764433720 2022: pid 9701: amcheck-clients- [..b3ba]: stream_client: Could not bind to port in range 512-1023. Fri May 27 20:47:26.764510810 2022: pid 9701: amcheck-clients- [..b3ba]: security_seterror(handle=10046c700, driver=77994368 (BSDTCP) error=sendmsg failed A: Message too long
Re: amrecover usage with chg-robot
On Fri, May 27, 2022 at 15:54:50 +0200, Stefan G. Weichinger wrote:
>
>
> forgot pstree:
>
> -tmux: server-+-bash---amrecover-+-amandad-+-amandad
>
>| | `-amindexd
>
>| |-amandad-+-amandad
>
>| |
> `-amidxtaped-+-exuvo_crypt---openssl
>
>| | `-2*[{amidxtaped}]
>
>| |-gzip
>
>| |-tar
>
>| `-{amrecover}
Ah, so euxvo_crypt is run by the amidxtaped process rather than by the
amrecover process itself.
What does strace show amrecover is doing during this period?
And "ps -ef" shows that the openssl process is still alive (i.e. not
defunct). What does "strace" show on that process. If you manually
kill it, does the change of processes up through amidxtaped unwind and
amrecover resume normal processing?
Nathan
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amrecover usage with chg-robot
forgot pstree:
-tmux: server-+-bash---amrecover-+-amandad-+-amandad
| | `-amindexd
| |-amandad-+-amandad
| |
`-amidxtaped-+-exuvo_crypt---openssl
| |
`-2*[{amidxtaped}]
| |-gzip
| |-tar
| `-{amrecover}
Re: amrecover usage with chg-robot
Am 27.05.22 um 14:28 schrieb Stefan G. Weichinger: Am 27.05.22 um 14:05 schrieb Nathan Stratton Treadway: On Fri, May 27, 2022 at 10:28:09 +0200, Stefan G. Weichinger wrote: After that both tar and gzip.binary are shown as in ps, whatever that means. Okay, that's a little progress in the investigation. "" means that the process has exited, but the return code from the process has not been read by the parent process yet. So in this case, whatever process spawned the tar and gzip subprocesses is not "noticing" when the subprocesses finish... the question is why (and what is it stuck doing instead of cleaning up)? Are the "openssl enc" and/or encription-wrapper-script processes still out there at this time (and what state are they in)? You should be able to use pstree or "ps -ef" to determine which process is the parent (PPID column) of the defunct subprocesses. Yes, that parent process was still visible. I will retry that later, currently I am updating stuff on that server etc The parent is the amrecover process: root 2154598 2096066 15 15:25 pts/200:01:26 amrecover abt -o auth=local -s localhost amanda 2154601 2154598 0 15:25 pts/200:00:00 /usr/libexec/amanda/amandad -auth=local amanda 2154604 2154601 0 15:25 pts/200:00:00 /usr/libexec/amanda/amindexd amandad local amanda 2154605 2154601 0 15:25 pts/200:00:00 [amandad] amanda 2154632 2154598 6 15:25 pts/200:00:35 /usr/libexec/amanda/amandad -auth=local amanda 2154633 2154632 6 15:26 pts/200:00:32 /usr/bin/perl /usr/libexec/amanda/amidxtaped amandad local amanda 2154634 2154632 0 15:26 pts/200:00:00 [amandad] amanda 2154701 2154633 0 15:26 pts/200:00:00 /bin/bash /usr/sbin/exuvo_crypt -d root 2154703 2154598 49 15:26 pts/200:04:11 [gzip] root 2154705 2154598 2 15:26 pts/200:00:13 [tar] amanda 2154708 2154701 41 15:26 pts/200:03:31 /usr/bin/openssl enc -pbkdf2 -d -aes-256-ctr -salt -pass fd:3 This is while this is logged: # tail -f amidxtaped.20220527152600.debug Fri May 27 15:33:38.443013672 2022: pid 2154633: thd-0x556460b31400: amidxtaped: /usr/lib64/perl5/vendor_perl/5.34/Amanda/Restore.pm:1719:info:490 12472320 kb Fri May 27 15:33:53.454973643 2022: pid 2154633: thd-0x556460b31400: amidxtaped: /usr/lib64/perl5/vendor_perl/5.34/Amanda/Restore.pm:1719:info:490 12472320 kb Fri May 27 15:34:08.466959610 2022: pid 2154633: thd-0x556460b31400: amidxtaped: /usr/lib64/perl5/vendor_perl/5.34/Amanda/Restore.pm:1719:info:490 12472320 kb PID 2154633 -> /usr/bin/perl /usr/libexec/amanda/amidxtaped amandad local
Re: amrecover usage with chg-robot
Am 27.05.22 um 14:05 schrieb Nathan Stratton Treadway: On Fri, May 27, 2022 at 10:28:09 +0200, Stefan G. Weichinger wrote: After that both tar and gzip.binary are shown as in ps, whatever that means. Okay, that's a little progress in the investigation. "" means that the process has exited, but the return code from the process has not been read by the parent process yet. So in this case, whatever process spawned the tar and gzip subprocesses is not "noticing" when the subprocesses finish... the question is why (and what is it stuck doing instead of cleaning up)? Are the "openssl enc" and/or encription-wrapper-script processes still out there at this time (and what state are they in)? You should be able to use pstree or "ps -ef" to determine which process is the parent (PPID column) of the defunct subprocesses. Yes, that parent process was still visible. I will retry that later, currently I am updating stuff on that server etc to add complexity: this is a rather old server with gentoo linux on it, a bit neglected because it should have been replaced long ago)
Re: amrecover usage with chg-robot
On Fri, May 27, 2022 at 10:28:09 +0200, Stefan G. Weichinger wrote: > After that both tar and gzip.binary are shown as in ps, > whatever that means. Okay, that's a little progress in the investigation. "" means that the process has exited, but the return code from the process has not been read by the parent process yet. So in this case, whatever process spawned the tar and gzip subprocesses is not "noticing" when the subprocesses finish... the question is why (and what is it stuck doing instead of cleaning up)? Are the "openssl enc" and/or encription-wrapper-script processes still out there at this time (and what state are they in)? You should be able to use pstree or "ps -ef" to determine which process is the parent (PPID column) of the defunct subprocesses. Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: amrecover usage with chg-robot
Am 26.05.22 um 12:05 schrieb Stefan G. Weichinger: Am 26.05.22 um 12:01 schrieb Stefan G. Weichinger: Am 26.05.22 um 04:10 schrieb Exuvo: I think i had "/bin/gzip: gzip: stdin: decompression OK, trailing garbage ignored" before i used -q to zstd which suppresses warnings and interactivity. Maybe I could edit to "gzip -d" somewhere in the code to also suppress this? sorry, correction: "gzip -d -q" Trying this by: * moved gzip to gzip.binary * copied gunzip to gzip * edited gzip to call "gzip.binary -q" and rerunning my amrecover test with 2 tapes and device "robot" First tape is extracted OK That ugly "trailing garbage" message is gone now, as intended. The strace on tar shows that it exits with exit code 0. After that both tar and gzip.binary are shown as in ps, whatever that means. And amidxtaped.xx.debug shows the same Fri May 27 10:26:40.042894830 2022: pid 737966: thd-0x563359eb2800: amidxtaped: /usr/lib64/perl5/vendor_perl/5.32/Amanda/Restore.pm:1719:info:490 12472320 kb as before. Maybe I have to wait ...
