¿Está interesado en corregir esos errores de biblioteca y errores que observa al instalar un programa nuevo y genial en Linux? Consulte este artículo que muestra cómo utilizar ltrace y le proporciona la herramienta necesaria para depurar las llamadas a la biblioteca.
Que es un Biblioteca?
La mayoría de la gente está familiarizada con .dll/.DLL archivos (bibliotecas de vínculos dinámicos) en Windows. El idéntico de Linux es un .so archivo, un objeto compartido, a menudo denominado simplemente biblioteca.
Una biblioteca puede ser utilizada por una aplicación que posibilita que ese programa utilice funcionalidades externas a su código de programa. A modo de ejemplo, un servidor web puede querer utilizar una biblioteca de E / S de disco escrita por el proveedor del sistema operativo u otro tercero. Es una forma de compartir bienes e intereses comunes en la mayoría, si no en todos, los sistemas operativos.
Las bibliotecas se pueden cargar dinámicamente en tiempo de ejecución (cuando el programa que realiza la llamada se está iniciando, a modo de ejemplo) o se pueden compilar en una aplicación de destino / binario. Es por ello que, siempre se cargarán (ya sea que se utilicen o no), como parte de y siempre que se inicie la aplicación que los tiene compilados / integrados.
Para obtener más información sobre las bibliotecas, sus dependencias y la ldd herramienta, es posible que desee leer con relación a cómo trabajar con dependencias de objetos compartidos en linux. los ldd es otra herramienta útil para tener en cualquier caja de herramientas de usuario de Linux más avanzada.
que es trazar?
Hay varias utilidades de rastreo en Linux, como strace para rastrear las llamadas y señales del sistema y el traceroute para rastrear el enrutamiento de la red. los ltrace La utilidad / herramienta rastrea todas las llamadas a la biblioteca.
Si ha leído nuestro trabajo con dependencias de objetos compartidos (biblioteca) en el artículo de Linux (vinculado arriba), ya habrá visto cómo puede averiguar a qué bibliotecas está vinculado un binario en particular usando el ldd herramienta. El propósito y la funcionalidad de ltrace es algo distinto; muy en línea con strace, los ltrace El comando rastrea todas las llamadas a la biblioteca que hace un programa en particular mientras se ejecuta.
Igual a strace, podemos iniciar un programa debajo (piénsalo como una jerarquía) ltrace. Simplemente especificamos el programa que ltrace debería comenzar como la primera opción para ltrace, y ltrace iniciará ese programa por nosotros e inmediatamente comenzará (en un nivel superior) a rastrear todas las llamadas a cualquier biblioteca (del sistema operativo o de un tercero instalado).
Lo hace interceptando y registrando el dinámica llamadas a la biblioteca hechas por el programa que se está ejecutando. Al mismo tiempo rastreará cualquier señal enviada al programa que se está ejecutando, muy idéntico a strace (y, si así lo desea, esta funcionalidad se puede desactivar especificando el -b o idéntico --no-signals opción a ltrace).
Tenga en cuenta que el término dinámica es de gran importancia aquí; ltrace rastreará las llamadas a externo bibliotecas (bajo la forma de .so o .a archivos), dicho de otra manera, bibliotecas no compiladas de forma directa en un programa; dinámica Bibliotecas. Es por ello que, si tiene un binario con bibliotecas estáticamente (compiladas), ltrace no podrá ver / rastrear dichas llamadas internas.
Instalando trazar
Instalar trazar en su distribución de Linux basada en Debian / Apt (como Ubuntu y Mint), ejecute el siguiente comando en su terminal:
sudo apt install ltrace
Instalar trazar en su distribución de Linux basada en RedHat / Yum (como RHEL, Centos y Fedora), ejecute el siguiente comando en su terminal:
sudo yum install ltrace
Usando ltrace
Configuremos un pequeño entorno de prueba:
sudo apt install tar xz-utils mkdir ~/workspace && cd ~/workspace touch a b c
Aquí instalamos tar y xz instalando xz-utils (puedes usar sudo yum install tar xz en su lugar, si está usando Centos / RHEL / Fedora). A continuación creamos un directorio ~/workspace y saltó a él. Posteriormente hicimos tres archivos vacíos usando el touch comando, a saber, archivos a, b y c.
Comencemos comprimiendo nuestros tres archivos en un (alquitrán combinado y xz comprimido) archive.tar.xz archivo, mientras se ejecuta el mismo bajo ltrace, y observando el ltrace producción:
ltrace tar -hcf --xz archive.tar.xz *
Solo vemos una pequeña cantidad de salida. Podemos ver que nuestro programa terminó con éxito (se creó el archivo de almacenamiento), dicho de otra manera, status 0: un código de salida de 0 siempre significa éxito en Linux (aún cuando el programa necesita tener códigos de salida implementados correctamente).
Esto no es muy útil hasta ahora. Razonar unos segundos con relación a cómo tar operará aquí revelará rápidamente nuestro próximo enfoque. El lector ávido al mismo tiempo puede haber entendido que el tar El comando internamente llamaría al xz mando. los --xz opción pasada a nuestro tar línea de comando se asegurará de que el xz El programa se utiliza para la compresión.
El procedimiento secundario (o el tercero en la jerarquía general) dicho de otra manera xz (jerarquía: ltrace > tar > xz) será iniciado por tar cuando sea necesario. Como tal, necesitamos rastrear los procesos secundarios del programa que se ejecuta bajo ltrace, dicho de otra manera tar. Podemos hacer esto especificando lo siguiente (-f) opción a ltrace:
ltrace -f tar -hcf --xz archive.tar.xz *
Tenga en cuenta que es esencial especificar el -f opción de forma directa detrás ltrace y no más tarde en la línea de comando después tar a modo de ejemplo. El motivo es que queremos especificar esta opción para ltrace y no al tar mando. Todas las alternativas después de tar comando son tar opciones específicas mientras que -f es una alternativa específica para ltrace.
El resultado es un poco más interesante. Aún no observamos ninguna llamada a la biblioteca (de ninguna forma), pero al menos vemos que dos subprocesos están bifurcados (nota exec()) y que ambos subprocesos terminan con status 0. Práctico y todo bien.
Entonces, ¿dónde están las llamadas de nuestra biblioteca? Comprobación tar y xz (los dos programas que utilizará el comando para crear el archivo de almacenamiento) con ldd, nos damos cuenta rápidamente de que la mayoría de las bibliotecas que usan ambos programas son bibliotecas del sistema:
whereis tar whereis xz ldd /bin/tar ldd /usr/bin/xz
Es por ello que, debemos ir un paso más allá y habilitar el seguimiento de las llamadas a la biblioteca del sistema especificando el -S opción a ltrace. Esta opción se encuentra deshabilitada / apagada de forma predeterminada, dado que la salida se volvería un poco detallada, y es probable que se asuma que las bibliotecas del sistema son de forma general mucho más estables y, como tal, no es necesario rastrearlas para comenzar. Echemos un vistazo.
ltrace -fS tar -hcf --xz archive.tar.xz *
O, con fines de prueba:
ltrace -fS tar -hcf --xz archive.tar.xz * 2>&1 | head -n10 ltrace -fS tar -hcf --xz archive.tar.xz * 2>&1 | tail -n10
Como el resultado fue sustancial, tuvimos que capturar la primera y las últimas diez líneas usando un head y tail mando. Para poder usar estos comandos tuvimos que redirigir stderr para stdout usando el 2>&1 redirección como ltrace informará de forma predeterminada sobre stderr. Si está interesado en obtener más información sobre la redirección, consulte Bash Automation and Scripting Basics (Parte 3).
Ahora que agregamos el -S opción, podemos ver todas las bibliotecas a las que se accede. A modo de ejemplo, vemos /etc/ld.so.preload siendo accedido. La salida es secuencial (de arriba a abajo), por lo que si hay otros eventos (subprocesamiento que se bifurca, etc.) en el medio, estos se mostrarán en línea en el momento en que tengan lugar. Al mismo tiempo podríamos agregar el -t opción para salida basada en tiempo:
Terminando
En este artículo, presentamos y discutimos el versátil ltrace program, que es una gran herramienta que posibilita rastrear todas las llamadas de biblioteca dinámicas que hace un programa dado. Nosotros instalamos ltrace, configuró un entorno de prueba y ejecutó algunos ltrace comandos con las alternativas más utilizadas.
