Ich habe das Skript [1], das vom Postgres-Daemon (WAL-Archiver) ausgeführt wird und mit dem Exitcode 12 fehlschlägt; siehe [2]. Aber wenn ich dasselbe Skript in einer Terminal-/SSH-Sitzung ausführe, funktioniert es; siehe [3].
Der Benutzer BasketCase im Freenode IRC-Kanal #rsync versuchte, das Problem zu diagnostizieren, kam aber nicht weit. Die Unterhaltung finden Sie unter [4].
Dies passiert nicht auf allen Maschinen, auf denen es verwendet wird, aber dies ist das zweite Mal, dass ich dies erlebt habe.
Jede Hilfe wird sehr geschätzt.
Dank im Voraus.
[1] WAL-Archivierungsskript
#!/bin/bash
# $1 is the %p substituted by postgres in archive_command
# $2 is the %f substituted by postgres in archive_command
# This script backs up the WAL file to every replica, and
# exits with the last failure code, if any.
final_exit_code=0
replicas=$(grep REPLICA /some/file | sort | uniq | cut -d = -f 2-)
for replica_url in $replicas; do
echo Sending WAL file to $replica_url
rsync --timeout=10 -avz -e 'ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=10 -i /opt/PostgresPlus/CloudDB/data/cluster_ssh.key' "$1" root@$replica_url:/mnt/pcs/wal_archive/"$2"
exit_code=$?
if [ $exit_code -ne 0 ] ; then final_exit_code=$exit_code ; fi
done
exit $final_exit_code
[2] Senden einer WAL-Datei an 10.33.177.184 rsync: Verbindung unerwartet geschlossen (bisher 0 Bytes empfangen) [Absender] rsync-Fehler: Fehler im rsync-Protokolldatenstrom (Code 12) bei io.c(600) [Absender=3.0.6] LOG: Archivierungsbefehl ist mit Exitcode 12 fehlgeschlagen. DETAILS: Der fehlgeschlagene Archivierungsbefehl war: ./wal_archive.sh pg_xlog/0000000100000005000000EE 0000000100000005000000EE
[3] $ ./wal_archive.sh pg_xlog/0000000100000005000000EE 0000000100000005000000EE WAL-Datei wird an 10.33.177.184 gesendet. Warnung: „10.33.177.184“ (RSA) wurde dauerhaft zur Liste der bekannten Hosts hinzugefügt. Inkrementelle Dateiliste wird gesendet 0000000100000005000000EE
gesendet 5180930 Bytes empfangen 31 Bytes 941992,91 Bytes/Sek. Gesamtgröße ist 16777216 Beschleunigung ist 3,24
Antwort1
Das Problem war der LD_LIBRARY_PATHUnterschied zwischen dem Terminal und der Umgebung des Postgres-Daemons.
Wenn ich dasselbe LD_LIBRARY_PATHim Terminal verwende, schlägt auch das rsync im Terminal fehl:
$ export LD_LIBRARY_PATH=/opt/PostgresPlus/9.1AS/lib:
$ ./wal_archive.sh pg_xlog/0000000100000005000000EE 0000000100000005000000EE
Sending WAL file to 10.33.177.184
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(600) [sender=3.0.6]
sshverwendete die Bibliotheken von /opt/PostgresPlus/9.1AS/lib, die wahrscheinlich mit sshBinary nicht kompatibel sind.
Hier ist ldddie Ausgabe nach sshdem Festlegen dieses ExportsLD_LIBRARY_PATH
$ ldd `which ssh`
linux-vdso.so.1 => (0x00007fff3fa28000)
libfipscheck.so.1 => /lib64/libfipscheck.so.1 (0x00007fe726907000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fe7266e7000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007fe72634d000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fe72614a000)
libz.so.1 => /opt/PostgresPlus/9.1AS/lib/libz.so.1 (0x00007fe725f34000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fe725d1b000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fe725ae4000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fe7258c9000)
libgssapi_krb5.so.2 => /opt/PostgresPlus/9.1AS/lib/libgssapi_krb5.so.2 (0x00007fe725690000)
libkrb5.so.3 => /opt/PostgresPlus/9.1AS/lib/libkrb5.so.3 (0x00007fe7253d3000)
libk5crypto.so.3 => /opt/PostgresPlus/9.1AS/lib/libk5crypto.so.3 (0x00007fe7251aa000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fe724fa6000)
libnss3.so => /usr/lib64/libnss3.so (0x00007fe724c6a000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe7248d6000)
libplc4.so => /lib64/libplc4.so (0x00007fe7246d1000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe7244cd000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe726d76000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007fe72426a000)
libcom_err.so.3 => /opt/PostgresPlus/9.1AS/lib/libcom_err.so.3 (0x00007fe724067000)
libkrb5support.so.0 => /opt/PostgresPlus/9.1AS/lib/libkrb5support.so.0 (0x00007fe723e60000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe723c42000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007fe723a1c000)
libplds4.so => /lib64/libplds4.so (0x00007fe723818000)
libnspr4.so => /lib64/libnspr4.so (0x00007fe7235da000)
Und hier ist der gleiche Befehl ohne den LD_LIBRARY_PATHSatz
$ ldd `which ssh`
linux-vdso.so.1 => (0x00007fff941ff000)
libfipscheck.so.1 => /lib64/libfipscheck.so.1 (0x00007f93b2ab2000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f93b2893000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f93b24f8000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f93b22f5000)
libz.so.1 => /lib64/libz.so.1 (0x00007f93b20df000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f93b1ec5000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f93b1c8e000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f93b1a74000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f93b1831000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f93b1552000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f93b1326000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f93b1121000)
libnss3.so => /usr/lib64/libnss3.so (0x00007f93b0de5000)
libc.so.6 => /lib64/libc.so.6 (0x00007f93b0a52000)
libplc4.so => /lib64/libplc4.so (0x00007f93b084c000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f93b0648000)
/lib64/ld-linux-x86-64.so.2 (0x00007f93b2f21000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f93b03e6000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f93b01da000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f93affd7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f93afdba000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f93afb93000)
libplds4.so => /lib64/libplds4.so (0x00007f93af98f000)
libnspr4.so => /lib64/libnspr4.so (0x00007f93af752000)