Linux Problema con ldd debian 7

whiplashh

Capo
Se incorporó
30 Marzo 2015
Mensajes
345
La semana pasada me encontraba programando una tarea de respaldo para una base de datos en PostgreSQL, la cual debía tomar la base de datos de producción, hacer un dump y llevarla al servidor de desarrollo donde esta base se cargaría y se le realizarían algunas modificaciones del tipo UPDATE, nada de otro mundo. Cuando desarrollé el scrip en el servidor de desarrollo (Debian 8.5) este funcionó a la perfección, el problema fue cuando pasé el script a producción (Debian 7.11), al generar el .gz del respaldo arrojaba un extraño error que no lograba encontrar, ni corriendo el script con el clásico bash -x script.sh, la línea que presentaba el problema era:
"
PGPASSWORD="$PASS" /usr/bin/pg_dump -U$USER $DB|/bin/gzip --to-stdout > $DESARROLLOBKP/$DB-$(/bin/date +%Y%m%d).gz
"
Este error solo se presentaba ejecutando el script, si corría la misma línea (reemplazando las variables jejeje) el .gz se generaba sin ningún problema, intenté cambiando la compresión, pero este persistía.

Después de mucho tiempo verificando el script, descubrí el problema... el comando ldd tenía un """"error""" en su programación, la línea 118 estaba escita de la siguiente forma:
eval $add_env '"$@"' | cat
la cual cambié por:
eval $add_env '"$@"' | /bin/cat

y paaaafffff nació chocapic. Este mismo problema se me presentaba en un monitoreo de Nagios a otro servidor PostgreSQL, que también solucioné de esta forma.

Si me preguntan es algo bien rebuscado, pero considero importante comentar, a más de uno le podría servir.

saludos
 

Miguelwill

I am online
Miembro del Equipo
MOD
Se incorporó
23 Febrero 2004
Mensajes
12.402
La semana pasada me encontraba programando una tarea de respaldo para una base de datos en PostgreSQL, la cual debía tomar la base de datos de producción, hacer un dump y llevarla al servidor de desarrollo donde esta base se cargaría y se le realizarían algunas modificaciones del tipo UPDATE, nada de otro mundo. Cuando desarrollé el scrip en el servidor de desarrollo (Debian 8.5) este funcionó a la perfección, el problema fue cuando pasé el script a producción (Debian 7.11), al generar el .gz del respaldo arrojaba un extraño error que no lograba encontrar, ni corriendo el script con el clásico bash -x script.sh, la línea que presentaba el problema era:
"
PGPASSWORD="$PASS" /usr/bin/pg_dump -U$USER $DB|/bin/gzip --to-stdout > $DESARROLLOBKP/$DB-$(/bin/date +%Y%m%d).gz
"
Este error solo se presentaba ejecutando el script, si corría la misma línea (reemplazando las variables jejeje) el .gz se generaba sin ningún problema, intenté cambiando la compresión, pero este persistía.

Después de mucho tiempo verificando el script, descubrí el problema... el comando ldd tenía un """"error""" en su programación, la línea 118 estaba escita de la siguiente forma:
eval $add_env '"$@"' | cat
la cual cambié por:
eval $add_env '"$@"' | /bin/cat

y paaaafffff nació chocapic. Este mismo problema se me presentaba en un monitoreo de Nagios a otro servidor PostgreSQL, que también solucioné de esta forma.

Si me preguntan es algo bien rebuscado, pero considero importante comentar, a más de uno le podría servir.

saludos

probaste cambiando el motor de interprete de comandos de dash por bash ?
dkg-reconfigure bash
 
Upvote 0

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.601
me suena a que /bin/ no está dentro del $PATH, yo miraría pq no está incluido en .bashrc o .bash_profile, ya que te puede producir más de un problema, ya mencionas lo del server de monitoreo.

Revisa si Debian no hace dos cosas distintas para cuando allocas el tty vs cuando no, lo ideal es que en el modo no-interactivo tb dispongas de todas tus rutas, para que no te pasen cosas como ésta.

Lo otro a lo que podrías echarle un vistazo es a /usr/bin/env [comando], éste debería ser igual en cualquier sistema más menos moderno (hasta ahí llegó Debian xD) y te devuelve la ruta completa hacia el ejecutable, listo para ser ocupado.

Saludos.
 
Upvote 0

whiplashh

Capo
Se incorporó
30 Marzo 2015
Mensajes
345
me suena a que /bin/ no está dentro del $PATH, yo miraría pq no está incluido en .bashrc o .bash_profile, ya que te puede producir más de un problema, ya mencionas lo del server de monitoreo.

Revisa si Debian no hace dos cosas distintas para cuando allocas el tty vs cuando no, lo ideal es que en el modo no-interactivo tb dispongas de todas tus rutas, para que no te pasen cosas como ésta.

Lo otro a lo que podrías echarle un vistazo es a /usr/bin/env [comando], éste debería ser igual en cualquier sistema más menos moderno (hasta ahí llegó Debian xD) y te devuelve la ruta completa hacia el ejecutable, listo para ser ocupado.

Saludos.

El directorio /bin/ si estaba definido en $PATH y voy a verificar los de "/usr/bin/env"

Saludos
 
Upvote 0

unreal4u

I solve problems.
Miembro del Equipo
ADMIN
Se incorporó
2 Octubre 2005
Mensajes
13.601
El directorio /bin/ si estaba definido en $PATH y voy a verificar los de "/usr/bin/env"

Saludos
Pero probaste en una terminal con y sin interacción? Ojo que ambos pueden diferir en lo que incluyen, eso (en parte) se determina en /etc/ssh/sshd_config y otros valores se determinan al compilar y por ende son distintos en distintos sistemas operativos.

Saludos.


Sent from my iPhone using Tapatalk
 
Upvote 0

whiplashh

Capo
Se incorporó
30 Marzo 2015
Mensajes
345
Pero probaste en una terminal con y sin interacción? Ojo que ambos pueden diferir en lo que incluyen, eso (en parte) se determina en /etc/ssh/sshd_config y otros valores se determinan al compilar y por ende son distintos en distintos sistemas operativos.

Saludos.


Sent from my iPhone using Tapatalk

Efectivamente eran distintos, y el error se produjo igual.

Saludos
 
Upvote 0

yakko

pingüino mal genio
Se incorporó
24 Agosto 2004
Mensajes
16.883
eso es simplemente un problema de path, si vas a usar path relativos asegúrate que esté exportada la variable path igual que la del usuario que va a ejecutar ese script.
 
Upvote 0
Subir