Error de SVN al realizar el pago mediante script

Estoy obteniendo el error por debajo al realizar el pago desde svn usando un script.

**[Test] $ /bin/sh -xe /tmp/hudson8576425899836211909.sh + sh /cvsrx/rxapp/build_dir/Jenkins_Scripts/test.sh Could not load program svn: Could not load module /opt/freeware/lib/libssl.so. Dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.1) could not be loaded. Member libcrypto.so.1.0.1 is not found in archive Could not load module svn. Dependent module /opt/freeware/lib/libssl.so could not be loaded. Could not load module . Build step 'Execute shell' marked build as failure Finished: FAILURE** 

En test.sh he escrito una sola línea svn co / path a svn branch / Estoy en medio de alguna testing así que no preguntes por qué no estoy usando jenkins en el plugin svn de compilation. aquí, puedo tomar el pago en el símbolo del sistema usando svn co / path a svn branch / Pero no si escribo esta línea de command en script y lo ejecuto en el shell de ejecución de jenkins. ¿Alguna ayuda, por favor?

Estoy usando jenkins en la plataforma AIX 7.

Tenía softlinks de / usr / bin / svn a /opt/freeware/bin/svn.SVN instalados en / opt / freeware / bin / svn ….. Por defecto cuando hago qué svn muestra /usr/bin/svn Pero cuando eliminé esos softlinks y la ruta exportada, Jenkins no reconoció SVN en absoluto. Y which svn command which svn muestra ningún svn instalado. Registros PFB de jenkins: `

 /bin/sh -xe /tmp/hudson5607872610124977868.sh + export PATH=/opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin:/ + echo /opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin:/opt/freeware/bin/svn/:/opt/freeware/bin/svnversion:/opt/freeware/bin/svn:/opt/freeware/bin/svnversion/:/usr/java5/lib:/opt/freeware/bin/svnversion/bin:/usr/local/bin:/usr/bin:/usr/X11R7/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/mit/bin:/sbin + cd /usr/local/apps/Jenkins_new/scripts + ./test.sh Could not load program /opt/freeware/bin/svn: Could not load module /opt/freeware/lib/libssl.so. Dependent module /usr/lib/libcrypto.a(libcrypto.so.1.0.1) could not be loaded. Member libcrypto.so.1.0.1 is not found in archive Could not load module svn. Dependent module /opt/freeware/lib/libssl.so could not be loaded. Could not load module . ./test.sh[3]: svn: not found Build step 'Execute shell' marked build as failure Finished: FAILURE` 

¡Reinstalar a Jenkins resolvió mi problema! Fue debido a un plugin corrupto que sucedió debido al reinicio del server. Gracias a todos

No he visto el command exacto de svn que usaste en test.sh, pero te aconsejaría que proporciones la ruta completa de SVN en tu línea de llamada, por ejemplo, / usr / bin / svn co ….. Y si es posible, hazlo una input en su test.sh para exportar PATH y exportar LD_LIBRARY_PATH configurándolos a valores que son routes de acceso de los files .so mencionados.

Veo que estás usando Hudson / Jenkins. Hudson y Jenkins usan SVNKit internamente cuando revisan cosas dentro y fuera de Subversion. Esto significa que el cliente svn línea de command puede no estar instalado en su sistema o que puede tener otros problemas.

También es posible que haya múltiples clientes svn en su sistema. Por ejemplo, puede tener uno en /usr/bin/svn y otro en /usr/local/bin/svn . Si Subversion está trabajando desde la command-line, pero no en el script, es posible que tenga una configuration de $PATH diferente cuando esté ejecutando desde la línea de command contra el script de Hudson / Jenkins. Puede agregar a su script (si es BASH) el type svn línea type svn para ver desde dónde está ejecutando el svn . Puede ser diferente de lo que está usando desde la línea de command. También puede ser bueno imprimir $PATH como parte de su script.

También sería útil ver el command svn que está ejecutando su script, y díganos qué está tratando de hacer. También puede agregar a su script las siguientes líneas:

 PS4="\$LINE: " set -xv 

Estas líneas activarán la debugging del script de shell y lo ayudarán a ubicar el lugar donde su script tiene problemas.

Esto le dará algunas pistas sobre qué está mal en su secuencia de commands.

Respuesta

Gracias David. Aquí solo existe una ruta de svn (usr / bin / svn) pero creada como un enlace de networking vea -> cd / usr / bin / svn lrwxrwxrwx 1 sistema raíz 26 Jul 1 14:34 svn -> ../../opt/ freeware / bin / svn. También se crea el soflink de libs.so see -> lrwxrwxrwx 1 root system 15 Sep 13 18:15 libssl.so -> libssl.so.1.0.1 ………. ¿Es posible que el softlink sea creando estos problemas ?? Antes de solicitar eliminar estos softlinks, necesito la confirmación de que estos softlinks están creando problemas.

Softlinking no es inusual para Unix. Por ejemplo, tengo Ant, Grails, Maven, Subversion y muchos otros packages instalados en /opt en mi Mac. Para no tener que include todos y cada uno de estos en mi path, enlace todos los binarys para esos progtwigs en /usr/local/bin . Alnetworkingedor del 80% de los progtwigs en /usr/local/bin son meramente enlaces suaves en otros lugares.

Los enlaces suaves de la biblioteca también son muy comunes. Esto generalmente tiene que ver con la numeración de versiones. Cuando un progtwig solicita una biblioteca, puede include o no el número de versión de la biblioteca. Entonces, tienes libfoo-2.0.3.so en tu disco. Esta es la versión real de foo . Sin embargo, pocos progtwigs solicitarán esa versión particular. En su lugar, pueden simplemente solicitar que necesiten la versión 2 de foo o simplemente decir que necesitan un enlace a foo.

Para manejar esto, tendrá libfoo2.0.3.so vinculado de forma suave a libfoo-2.so para progtwigs que especifiquen que necesitan la versión 2 de foo . Luego, libfoo-2.so tendrá un libfoo-2.so suave a libfoo.so . De esta forma, libfoo se llamará sin importar qué. Si instalo, libfoo2.0.4.so , puedo cambiar el enlace a libfoo-2.so para que apunte a la versión 2.0.4 en lugar de la versión 2.0.3, y todo lo que dependa de Foo elegirá la versión correcta.

En cambio, veamos el post de error:

No se pudo cargar el module /opt/freeware/lib/libssl.so.
El module dependiente /usr/lib/libcrypto.a(libcrypto.so.1.0.1) no se pudo cargar.
El miembro libcrypto.so.1.0.1 no se encuentra en el file

Por algún motivo, no pudo acceder al file /usr/lib/libcryto.a . ¿Este file está en tu máquina? ¿Está en /usr/lib ? Si no, ¿dónde está ubicado?

Entonces, ¿de dónde sacaste esta versión de Subversion? ¿Por qué el enlace al directory /opt/freeware/bin/ ? ¿Era esto parte de tu sistema?

Podría ser que Subversion en su sistema no esté completo y nunca funcionó. En Jenkins, el repository de Subversion es accedido por SVNKit Jarfile que está integrado dentro de Jenkins / Hudson, por lo que no sería realmente una sorpresa encontrar que el binary de Subversion no funcionó.

¿Eres capaz de hacer algo con Subversion desde la línea de command? Si no es así, puede que tenga que instalar una nueva versión de Subversion desde Perzl, que es donde señala CollabNet para una versión AIX de Subversion. (Al less está actualizado en la versión 1.8.4).

Incluso puede querer cambiar el enlace suave en /usr/bin/svn para apuntar a la versión más nueva y funcional de Subversion.