LPIC-1 Capítulo 2

EN ESTE CAPÍTULO SE ABARCAN LOS SIGUIENTES OBJETIVOS DEL EXAMEN:

• 102.3: Administrar bibliotecas compartidas (1)
• 102.4: Usar los administradores de paquetes Debian (3)
• 102.5: Utilizar los administradores de paquetes RPM y Yum (3)
• 103.5: Crear, monitorizar y destruir procesos (4)
• 103.6: Modificar las prioridades de ejecución de procesos (2)

---

 

 

Herramientas de administración del software: RPM y Debian

Las herramientas principales para la administración de paquetes Linux son: RPM y YUM (Red Hat) y DPKG, DSELECT y APT-GET (entre otros, para Debian). La mayoría de las distribuciones instalan un solo sistema de paquetes, aunque es posible instalar mas de uno (incluso algunos programas como alien, requieren ambos, para una funcionalidad completa), pero se desaconseja esta práctica, debido a que las bases de datos de cada gestor de herramientas son disyuntas, pudiendo producir esto, como mínimo errores en versiones de paquetes y dependencias.

Dejar claro que alien podrá producir estos errores, si intentamos instalar software que previamente estaba instalado ya con su gestor de paquetes, ya sea RPM o Debian.

 

RPM (Red Hat Package Manager)

RPM es el administrador de paquetes mas popular, creado por Red Hat. Algunas distribuciones hacen uso de ese gestor como Fedora y CentOS (derivados de RH), Mandriva, Yellow Dog (Power PC) y SUSE. RPM es compatible con arquitecturas x86, x86_64, PowerPC, IA-64, Alpha y SPARC.

 

Convención para nombrar paquetes RPM:

nombre_paquete-a.b.c-x.arq.rpm

samba-client.3.6.5-86.fc17.1.x86_64.rpm

• samba-client : Nombre de paquete
• 3.6.5 : Nº de versión
• 86.fc17.1 : El número de compilación o release.
• x86_64 : Indica que es una versión adaptada a la arquitectura x86_64

Nota:Hemos puesto un ejemplo en el que además se ha añadido un nombre que distingue para que distribución está compilado el paquete, en este caso indica que es la compilación 86.fc17.1 de Fedora.

RPM es un sistema de administración de paquetes muy flexible, es comparable al administrador de paquetes Debian y ofrece muchas mas funcionalidades que los tarball. Existen dos herramientas principales para la gestión de paquetes RPM.

• rpm que instala paquetes/archivos
• yum que es un meta-empaquetador que instala de forma cómoda los paquetes y sus dependencias.

El archivo de configuración de RPM se encuentra en: /usr/lib/rpm/rpmrc. La mayoría de las opciones de este archivo son relativas a la optimización de la CPU a la hora de compilar un paquete fuente. Cuando se quieren realizar cambios, no se modifica este archivo directamente si no que se modifica /etc/rpmrc (para efectos globales) o ~/.rpmrc para realizar cambios en función del usuario.

¿Como obtener archivos individuales de un paquete RPM? existen al menos 2 posibilidades, bien con el comando alien (el cual convierte un paquete RPM en paquete Debian o tarball) o bien utilizando el comando rpm2cpio para convertir un paquete rpm en un archivo cpio y posteriormente obtener archivos individuales de ese paquete con el comando cpio, pero ¿Que es un archivo cpio?, Un archivo cpio es un tipo de archivo principalmente creado para el almacenamiento de copias de seguridad en cintas magnéticas de una forma contigua y tiene un funcionamiento parecido al formato tar, a diferencia que se forma por una serie de archivos y/o directorios tanto con los encabezados usados por GNU CPIO para extraer el archivo, como con encabezados extras que sirven para identificar el nombre, fecha de creación, permisos y propietarios de cada archivo y/o directorio.

Nota: Cuando descomprimimos un archivo cpio, lo ideal es usar un directorio vacío a modo de contenedor, para que no modifiquemos o reemplacemos ningún archivo del sistema.

Los sitios webs http://rpmfind.net y http://freshrpms.net incluyen enlaces a RPM compilados por los autores de los programas, RPMs de distribuciones específicas o los compilados por terceros.

YUM (Yellow dog Updater Modified) es un meta-empaquetador que nos permite instalar con facilidad un paquete y todas sus dependencias desde un único comando. yum busca estos paquetes en unos repositorios que se encuentran configurado en el sistema (/etc/yum.repos.d/) que son «cajones en Internet» donde hay paquetes disponibles para su descarga e instalación, selecciona la versión mas actualizada y la descarga e instala, por el contrario si solo quiere descargar el paquete para posteriormente instalarlo en un OS que no se encuentra conectado a Internet puedes usar el comando yumdownloader. No todas las distribuciones que usan RPM utilizan YUM, SUSE y Mandriva utilizan su propio meta-empaquetador, a diferencia de las distribuciones basadas en Debian que si que utilizan el meta-empaquetador apt-get.

El archivo de configuración de yum se encuentra en /etc/yum.conf, además de otros archivos de configuración adicional, localizados en /etc/yum.repos.d/ (equivalen a la configuración de los repositorios mencionados anteriormente), o /etc/yum.repos.d/.yum.conf que especifica varias acciones a realizar por yum a la hora de ser ejecutado.

Existen alternativas de yum para entornos gráficos como: kyum y yumex

 

DEBIAN

Al igual que en RPM, los paquetes Debian son utilizados por diferentes distribuciones que derivan de Debian, como pueden ser Ubuntu, Linux Mint o Xandros e igualmente funcionan en diferentes arquitecturas. Prácticamente igual que en RPM, los paquetes Debian siguen una convención de nomenclatura para sus paquetes, estos incluyen información de dependencias, archivos y utilidades, además, igualmente se usa una herramienta para la instalación de estos (dpkg), o otras mas cómodas que tiene el efecto de yum en RPM (la de instalar paquetes y dependencias de forma cómoda) como APT-GET, dselect, aptitude o Synaptic (GUI).

Dentro del sistema de paquetes Debian podemos distinguir entre cinco tipos de paquetes según su grado de dependencia con el propio sistema:

• Required: Se trata de paquetes indispensables para el correcto funcionamiento del sistema.
• Important: Se trata de paquetes que deberían de estar presentes en cualquier sistema tipo UNIX.
• Standard: Paquetes que comúnmente se encuentran en un sistema GNU/Linux. No son indispensables para el correcto funcionamiento del sistema.
• Optional: Paquetes que pueden o no estar en un sistema GNU/Linux, como por ejemplo los referentes al sistema gráfico (en el caso de que vayamos a usar el sistema en modo servidor (minimalista).
• Extra: Paquetes no integrados como optional debido a que puedan surgir conflictos con paquetes de mayor prioridad o requiere un tipo de configuración especial.

Nota: Podemos ver la prioridad de un determinado paquete mediante el comando apt-cache show <paquete> | grep Priority o aptitude show samba |grep Priority

A diferencia de YUM, APT usa el archivo /etc/apt/source.list para especificar las ubicaciones desde las que se pueden obtener los paquetes, ya sean directorios de ubicaciones en CD-ROM, sitios FTP o webs.

/etc/apt/source.list Es el archivo de texto en el que añadiremos los PPA (Personal Package Archives), es decir las direcciones desde las que queremos obtener paquetes. Estas direcciones pueden tener un un formato tipo «deb http://packages.linuxmint.com rebecca main upstream import #id:linuxmint_main» si se trata de un repositorio de paquetes web, o cambiando http por ftp, smb, file o cdrom (dependiendo de que fuente de paquetes se trate).

Nota: Si la dirección pertenece a una URL donde se encuentra código fuente en vez de paquetes binarios, será deb-src lo que aparezca en lugar de deb

También es posible que cuando hayamos añadido un repositorio este se encuentre en /etc/apt/source.list.d/nombrerepo.list y dentro de este archivo la URL del repositorio. Existen programas específicos para ciertas distribuciones como es el caso de Ubuntu que añaden o eliminan de forma automática tanto el repositorio como la clave pública (GPG).

Instalar un nuevo PPA de forma automática en Ubuntu:

$ sudo add-apt-respository ppa:nombrerepo/ppa

Para eliminarlo:

$ sudo add-apt-repository --remove ppa:nombrerepo/ppa

En Debian podremos añadir un CD-ROM como fuente mediante el siguiente comando:

$ sudo apt-CD-ROM add

Si no tenemos la posibilidad de utilizar estas herramientas en nuestra distribución, deberemos de añadir los ppa a mano y eliminarlos mediante la edición del archivo source.list o con rm si se trata de un archivo en /etc/apt/source.list.d/

Ya hayamos realizado cambios (instalar, editar o eliminar un ppa) de forma automática o manual, deberemos de actualizar la información mediante el comando apt-get update. A partir de este momento dispondremos del nuevo ppa desde el que poder instalar un nuevo software que no encontrábamos en nuestros antiguos repositorios utilizando por ejemplo apt-get install <nombre_programa>.

dpkg hace la función de rpm en sistemas basados en RPM, es decir, instalador de paquetes. Sus archivos principales se encuentran en /var/lib/dpkg y el archivo de configuración en: /etc/dpkg/dpkg.cfg

apt-get es una herramienta de línea de comandos y es semejante a la herramienta yum, utilizada en sistemas RPM para la instalación de paquetes y sus dependencias. apt tiene su archivo de configuración el cual también afecta a la herramienta dselect: /etc/apt/apt.conf. Si quisiéramos ver algunos ejemplos de configuración podemos acceder al archivo de ejemplo: /user/share/doc/apt/examples/apt.conf

apt-cache es una herramienta que nos permite mantener actualizada y saneada la base de datos de paquetes para APT

dselect es una herramienta potente con una gran cantidad de opciones nada obvias y que posee una interfaz de usuario interactiva en modo texto. Para usarla basta con escribir el comando dselect en la línea de comandos y aparecerá un menú de tipo texto. dselect funciona como una interfaz de dpkg. También es posible pasarle opciones y comandos con la siguiente sintaxis:

dselect [opciones] [comandos]

El archivo de configuración principal se encuentra en: /etc/dpkg/dselect.cfg

aptitude es bastante similar a dselect por su formato interactivo , aunque aptitude incorpora menús por los que nos podemos mover usando Control-T. Aptitude también permite que se le pasen comandos por la línea de comandos.

Synaptic es una herramienta de entorno gráfico similar en muchos aspectos a dselect y aptitude, pero de fácil manejo.

Nota: Por lo general dselect, aptitude y synaptic son herramientas para encontrar software de los que desconoce su nombre exacto.

APT también puede funcionar en sistemas basados en RPM (http://www.apt4rpm.sourceforge.net).

Estudiaremos mas sobre los comandos de paquetes deb en su respectivo apartado de comandos al final del tema.

 

Convirtiendo paquetes RPM y Debian en tarball

Como vimos con el gestor de paquetes RPM, es posible convertir paquetes rpm en paquetes tarball y debian, pues para Debian pasa lo mismo, una buena solución para convertir paquetes rpm o tarball en paquetes Debian es mediante el software Alien, que como ya comentamos, es obligatorio tener el sistema de paquetes RPM y de Debian instalados en el mismo sistema. Una pega es que alien no convierte toda la información de las dependencias de manera totalmente correcta. Cuando convierte desde un tarball, alien copia los archivos exactamente igual que se encontraba en el paquete tarball, por lo que es primordial asegurarnos de que el paquete tarball contiene una ruta de directorios correcta, es decir, o descomprimimos el paquete en un directorio contenedor y luego creamos enlaces, copiamos o sustituimos los archivos originales, o bien desempaquetamos el contenido, creamos una estructura acorde, lo volvemos a empaquetar y cuando descomprimamos, cada archivo se situará en su directorio.

Para conocer los comandos de conversión, vaya a la página de comandos LPIC-1 Convertir paquetes

 

Soluciones para problemas de dependencias

Forzar la instalación: Una solución es ignorar el problema, esto no es lo adecuado pero dependiendo de donde se dé la dependencia sabremos si es buena opción o no. Por ejemplo:

Si hemos compilado un paquete y a la hora de instalarlo nos diese problemas de dependencias, podríamos en principio ignorarlo.

• RPM: Opciones —nodeps y –force (rpm -i nombrepaquete.rpm –force/–nodeps)
• DPKG: Opciones –ignore-depends=paquete, –force-depends ó —force-conflicts

Actualizar o reemplazar el paquete del que se depende: Es una buena forma de solucionar conflictos de dependencias, pero a veces engordamos el problema si el paquete que necesitamos no es el adecuado para nuestra distribución, en este caso, quizás nos aparezcan otros errores de dependencias en otros software que dependen de ese paquete, de su versión antigua (la instalada anteriormente) o bien que a la hora de volver a actualizar el programa o el sistema, no nos reconozca ese paquete, esto sucede porque interpretará las dependencias de forma que lo hace su distribución y no en la que la hemos instalado.

Recompilar el paquete problemático: Algunas dependencias surgen de bibliotecas u otras herramientas instaladas en el ordenador que compiló el paquete y no del código fuente del programa, por lo tanto, si volvemos a compilar el paquete en otro ordenador que tiene otras herramientas y software instalado, algunas dependencias cambiarán. En el caso de distribuciones basadas en Debian es raro que tenga que compilar un paquete a partir de su paquete fuente, pero para RPM, podremos usar el comando rpmbuild con la opción –rebuild y el paquete fuente. Esto nos puede generar uno o mas paquetes binarios en /usr/src/nom_distro/RPMS/tipo_arq

Localizar otra versión del software a instalar: Podemos volver a una versión anterior o posterior, siempre y cuando esto no produzca errores de seguridad o simplemente esa versión no satisfaga nuestras necesidades por tener implementaciones nuevas o bugs no corregidos. Esto es común cuando queremos instalar un software que además necesita actualizar bibliotecas compartidas y no queremos, ya que otros programas necesitan de esas, en este caso, una versión anterior podría solucionar esto.

 

Bibliotecas compartidas o dinámicas

Son «fragmentos» de los programas mas utilizados, referenciadas por el ejecutable principal de un programa, el cual omite la mayoría de las rutinas de bibliotecas.

Las bibliotecas compartidas son identificadas por su extensión .so o .so.versión, a diferencia de las estáticas que son incluidas dentro del mismo programa, y tienen la extensión .a.

Ventajas del uso de las bibliotecas compartidas o dinámicas:

• Le facilita la vida al programador.
• El programa final tiene un tamaño mucho menor, lo que significa que necesita menos espacio en disco y consume menos RAM y si encima son utilizadas por muchos programas de forma paralela, el uso de RAM o el espacio en discos no es redundante.
• Como regla general, los programas que dependen de bibliotecas compartidas se benefician de la actualización de estas de forma inmediata. No se necesita una actualización del programa ni volver a compilarlo, referenciando a una nueva biblioteca.

Inconvenientes del uso de las bibliotecas compartidas o dinámicas:

• Los cambios en una biblioteca pueden ser incompatibles con uno o todos los programas que hacen uso de ella. Para esto, Linux utiliza sistemas de numeración, para que se puedan mantener varias versiones de una misma biblioteca.
• Para que un programa se ejecute bien, necesita encontrar las bibliotecas, esto se hace mediante archivos de configuración y variables. El archivo de configuración general es /etc/ld.so.conf, este a su vez puede contener una línea como «include /etc/ld.so.conf.d/*.conf» que indica que cargue también los archivos de configuración de dicho directorio, ya que esos archivos pueden contener rutas de otras bibliotecas referenciadas.
• Al existir multitud de bibliotecas compartidas, esto puede producir una maraña de referencias a bibliotecas que puede resultar tedioso.
• El sobre-escribir, eliminar, o cualquier otra razón por la que una biblioteca quede inaccesible, puede producir desde que un programa no inicie, hasta que el mismo sistema no arranque.

Nota: Algunas distribuciones, como por ejemplo Gentoo, poseen características diferentes. Para modificar ld.so.conf, habría que añadir o editar los archivos del directorio /etc/env.d y luego utilizar la herramienta env-update, que lee los archivos de este directorio creando una «ruta final» para referenciar las bibliotecas. Estos métodos cambian las referencias a las bibliotecas de forma permanente y global.

Podemos configurar de forma no global, rutas de referencias a bibliotecas gracias a la variable de entorno LD_LIBRARY_PATH, por ejemplo, si quisiéramos probar el efecto de unas nuevas bibliotecas sin tener que definirlas de forma global, las almacenaríamos en un directorio y añadiríamos dicha ruta a esta variable, de forma que para esa sesión o futuras sesiones (en caso de que la configurásemos en un script de inicio de usuario) el sistema busque en determinado path archivos de configuración de bibliotecas.

$export LD_LIBRARY_PATH=/usr/local/pruebas:/opt/otraslib 

Puede ocurrir que al ejecutar un programa nos muestre un mensaje de error, en el que se informa de que la biblioteca no se ha encontrado. Lo mas normal es que la biblioteca no esté instalada, o bien el nombre o ruta de esta, difiera con el que el binario del programa pide. Para solucionar estos problemas lo normal es seguir el rastro del paquete y comprobar que librería está pidiendo y luego comprobar si está instalada en otro directorio no referenciado, o tiene otro nombre. Si directamente no está instalada, la buscaremos por la web, repositorios, etc… si está instalada con otro nombre o en otro directorio, bastará con crear un enlace simbólico desde la que tenemos hacia la que pide.

Linux posee un par de programas para la administración de bibliotecas.

• ldd : Muestra las bibliotecas de las que depende un programa, si le pasamos el nombre de una biblioteca, entonces mostrará la(s) biblioteca(s) de las que esta depende.
• ldconfig : Lee los archivos de configuración (/etc/ld.so.conf) e implementa todos los nuevos cambios (actualiza la caché) y como trabajo secundario actualiza todos los enlaces simbólicos de librerías.

Nota: Los programas ld.so y ld-linux.so son los que gestionan la carga de bibliotecas, y estos no leen los archivos de configuración, leen directamente el archivo /etc/ld.so.cache que es un binario que contiene toda las rutas de directorios y archivos (un formato mucho mas eficaz que en texto plano). El inconveniente es que cada vez que se añade un archivo o ruta hay que refrescar esta caché, para eso el comando ldconfig.

 

Compilación de paquetes

Lo primero que podemos preguntarnos si somos usuarios nóveles en GNU/Linux es ¿Que es compilar?, pues bien, la definición de compilar podría ser algo como «reunir una serie de objetos necesarios en una misma unidad con el fin de poder hacer que esta sea totalmente funcional«. En GNU/Linux cuando hablemos de compilar un paquete nos estaremos refiriendo a la transformación de un programa escrito en código fuente (el cual es legible por nosotros, los humanos) en código máquina, de manera que pueda ser interpretado por el sistema haciéndolo este funcionar.

Vamos a explicar el procedimiento de compilación mediante un ejemplo: Supongamos que queremos instalar un programa/paquete para el cual no encontramos el respectivo .rpm o .deb de nuestra distribución o sistema específico (hardware, arquitectura, etc..) pero en cambio si tenemos la opción de bajar el código fuente del mismo. Lo primero que deberemos de hacer será descargarlo a nuestra máquina. Una vez descargado comprobaremos que se trata de un archivo .tar, .tar.gz o tar.bz2 (aunque es posible igualmente encontrarlos en .zip o en otros sistemas de compresión).

Una vez tengamos el código fuente (archivo .tar, .tar.bzp2, etc..) en nuestra máquina deberemos de comprobar si tenemos algún compilador instalado en el sistema. En GNU/Linux es común utilizar GCC (compilador para C, C++, Java, Fortran y otros códigos de programación que se distribuye como software gratuito bajo licencia GPL (General Public License)) que podremos comprobar mediante la siguiente orden en consola:

# gcc --version

Si no obtenemos resultados deberemos de proceder a su instalación mediante alguna de las herramientas de instalación de paquetes anteriormente estudiadas.

Ahora que ya tenemos instalado gcc, vamos a descomprimir el código fuente. Dependiendo de la extensión del paquete deberemos de utilizar una u otra herramienta, por ejemplo si es un .zip utilizaremos:

# unzip nombre_paquete.zip

Si es un tar.gz o tar.bz2 utilizaremos la herramienta tar (esto lo veremos en capítulos posteriores, no obstante vamos a indicar como descomprimir exclusivamente este paquete) tal que así:

# tar -zvxf nombre_paquete.tar.gz

o

# tar -jxvf nombre_paquete.tar.bz2

Esto nos creará un nuevo directorio donde se almacenarán los archivos que contenía el paquete antes de ser descomprimido. Accederemos a este directorio mediante el comando cd. Dentro de este directorio buscaremos los archivos README e INSTALL donde se nos presentará una serie de instrucciones para la instalación y requisitos necesarios que deberemos de instalar en caso de no encontrarse instalados en nuestro sistema.

Ahora con «todos» los requisitos supuestamente instalados y una idea de lo que vamos a realizar para instalar el paquete o haber obtenido información sobre este mediante los archivos anteriormente citados, ejecutaremos el comando «./configure» con el que procederemos a verificar los requisitos (nos alertará si faltase alguno) y preparar la compilación.

Nota: Aunque por regla general «todos» los paquetes suelen llevar una ruta predefinida válida (la cual suele estar definida bajo el directorio /usr), podremos utilizar el parámetro –prefix=/ruta/de/instalación para especificar una ruta alternativa en la que instalar el nuevo programa. Es importante que esta ruta este en nuestra variable PATH de manera que podamos ejecutar el nuevo programa sea cual sea nuestro directorio de trabajo.

Con todo listo y todos los requisitos cumplidos procederemos a compilar. Para ello utilizaremos el comando make. Esto producirá una salida en la que iremos comprobando el proceso de compilación. Esta tarea podrá tardar desde segundos a horas (depende de numerosos factores).

Nota: Si tenemos un procesador con mas de un núcleo podremos utilizar la opción -j <num> para especificar el número de hilo (thread) a utilizar durante el proceso de compilación.

Bueno ya tenemos compilado nuestro programa ahora queda instalarlo. Es importante saber si tenemos permisos en el directorio de instalación, bien en el que viene por defecto (que se puede determinar dependiendo del paquete que estemos compilando e instalando) o en el que hayamos prefijado nosotros mediante la opción –prefix= de ./configure. De no tener los permisos suficientes deberemos de ingresar como root (su –), para lo que necesitaremos conocer su password o bien utilizar sudo (si es que el archivo /etc/sudoers, algo que veremos en otros capítulos, no lo permite). Sin más ejecutamos el comando make install.

Si todo ha ido bien, ya tendremos nuestra aplicación instalada la cual podremos ejecutar desde cualquier directorio (recordemos que el directorio en el que se encuentra el binario de la aplicación debe estar añadido como valor a nuestra variable PATH). Para finalizar no estaría de mas hacer un poco de limpieza, algo que hará fácilmente el comando make clean.

Nota: Este comando es necesario ejecutarlo, si tras la compilación obtuvimos errores y queremos volver a compilar. Antes de continuar deberemos de ejecutar make clean.

Si por cualquier motivo queremos desinstalar la aplicación, utilizaremos el comando make unistall, pero antes deberemos de movernos al directorio en el que se encuentran los archivos de compilación y el código fuente (sí, el que se creo cuando descomprimimos al principio el paquete comprimido del código fuente) y autentificarnos como root.

 

Controlando los procesos

Para controlar los procesos antes, deberemos de saber algunas características básicas sobre estos, como por ejemplo los estados que un proceso puede adoptar.

Los procesos pueden encontrarse en diferentes estados, por ejemplo, D se identifica con un proceso que se encuentra en estado ininterrumpible (proceso Input/Output), S referencia a un proceso dormido (sleep), R que se encuentra ejecutándose (running), T parado, X muerto y con Z se indica que un proceso se encuentra en estado ‘zombie‘ o ‘defunct‘ (en proceso de defunción).

Nota: Un proceso en estado zombie es un proceso que ha completado su ejecución pero aún tiene una entrada en la tabla de procesos, permitiendo al proceso que lo ha creado (su proceso padre) leer el estado de su salida. Al padre se le envía una señal SIGCHLD indicando que el proceso ha muerto, esta señal ejecuta la llamada al sistema wait, que lee el estado de salida y elimina el proceso zombie. Los procesos zombie pueden existir por un corto período de tiempo, que típicamente significa un error en el programa padre. La presencia de muchos procesos zombie puede indicar problemas en el sistema, y puede acarrear una alta carga del sistema, lentitud y respuestas lentas. Con la opción ‘-Z‘ del comando ps (comentado en breves) podremos localizar procesos zombie en nuestro sistema.

Aclaración: Un proceso zombie no es lo mismo que un proceso huérfano. Los procesos huérfanos no se convierten en procesos zombies, sino que son adoptados por init (PID 1)

Una de las herramientas mas importantes para la administración de procesos es ps, que muestra el estado de los procesos, por lo que es útil para la monitorización del sistema. Aparentemente ps es un programa de fácil uso, su sintaxis es:

$ ps -opciones

La complejidad llega cuando descubrimos que las opciones de ps son en realidad un grupo de otras opciones, es decir, ps admite opciones de tipo Unix98, las cuales van precedidas de (–), son de un único carácter, pero se pueden agrupar (ps -e-f = ps -ef), admite opciones de BSD, opciones de un único carácter que también se pueden agrupar, no van precedidas del caracter (-) y por último las opciones GNU largas, precedidas por (—) y son multicaracter. Podemos cambiar el comportamiento de ps a través de la variable PS_PERSONALITY con los valores posix, old, linux, bsd, sun, digital, entre otros.

ps genera una salida separada en columnas, cuyo encabezado define el significado de cada una de ellas, como por ejemplo:

• El nombre de usuario
• ID del proceso (PID)
• ID del proceso principal (PPID)
• El teletipo TTY (código que se utiliza para identificar una terminal o acceso remoto, los programas GUI no tienen ese número)
• El tiempo de CPU (TIME=cantidad total de tiempo consumido de CPU y %CPU=porcentaje de tiempo de CPU que utiliza el proceso cuando se ejecuta ps)
• Prioridad de la CPU (NI muestra el código de prioridad, números + para prioridad reducida y números – para prioridad aumentada)
• Uso de memoria (RSS=memoria utilizada por un programa y sus datos, %MEM=porcentaje de memoria que utiliza el programa y SHARE=memoria compartida con otros procesos (como las bibliotecas compartidas)
• La columna Comando muestra el comando ejecutado

Nota: Podemos usar el comando pstree para mostrar una salida de ps en árbol

En ocasiones usamos grep junto a ps para imprimir solo aquellos procesos que coinciden con un patrón. Existe una herramienta con la que poder realizar la misma acción y es pgrep. Programa que se escribió originalmente para Solaris 7. Posteriormente fue implementado para Linux y OpenBSD. La función principal de pgrep es devolver el número de ID de los procesos cuyos nombres coinciden con lo del patrón pasado por una expresión regular.

Nota: Podemos decir que $ps ax | grep mate | grep -v grep | awk ‘{print $1}’ es igual que $pgrep mate, de hecho el segundo es mas preciso que el primero.

Otro comando útil relacionado con los procesos es fuser. El comando fuser nos permite identificar que procesos están usando un cierto archivo, socket o directorio, y si queremos, podremos matarlos. Usar fuser por ejemplo para ver que proceso está usando nuestro directorio actual:

$ fuser .

Veremos una salida en la que se mostrará un número de proceso acompañado del caracter ‘c‘ (es posible que en vez de un solo proceso, veamos una serie de procesos, significará entonces que varios procesos están haciendo uso de nuestro directorio). El caracter ‘c‘ tras el número de proceso representa que es el directorio actual de trabajo (Current Directory) por lo que dependiendo del archivo que usemos podremos ver una ‘c‘ o ‘e‘ si es un ejecutable en activo, ‘f‘ para un fichero abierto, ‘F‘ si el fichero está abierto para escritura, ‘r‘ para el directorio raíz o incluso ‘m‘ si se trata de una biblioteca compartida o archivo mapeado.

Podemos ejecutar fuser contra un servicio simplemente pasando el nombre del servicio como parámetro y opcionalmente -v para obetener mas información:

$ fuser -v httpd

Si se trata de un socket usamos la opción -n (con -v si queremos) el nombre del protocolo (por ejemplo tcp) y el puerto. Podemos hacer que fuser sea interactivo con la opción -i útil si estamos matando procesos con -k

Para hacer un seguimiento de los procesos activos en el sistemas, comentamos antes una buena forma de hacerlo con el comando ps, pero también contamos con el utilitario top. top es una herramienta de línea de comandos, aunque también posee su equivalente gráfico como kpm o gnome-system-monitor, útil sobre todo para saber cuanto tiempo de CPU consumen unos procesos con respecto a otros. Por defecto top ordena su salida en función de aquellos programas que consumen mas tiempo de CPU. Uno de los datos importantes que proporciona top es la carga media (load average : x.xx y.yy z.zz, donde x.xx es la carga media actual, y.yy la carga media desde hace 5 minutos y z.zz la carga media desde hace 15 minutos) que indica cuantos programas están compitiendo por tiempo de CPU (también se puede averiguar la carga media con el comando uptime).

Un sistema que tiene un programa que hace uso intensivo de CPU tendrá una carga media de 1 (suponiendo que tenga un solo núcleo o CPU, ya que de tener 4 la medía podría ser 4.00).

Un programa puede crear una carga media de 1.0, sin embargo programas con múltiples procesos pueden generar cargas mas elevadas.

El comando top, puede recibir opciones como parámetros e incluso nos permite interaccionar con él, una vez ejecutado.

Al igual que comprobamos la carga media del sistema, podemos comprobar la memoria RAM disponible o utilizada por el conjunto de procesos que corren en el sistema. Un comando útil para tal fin es free. Las opciones de free son pocas y sencillas, pero las veremos en el apartado de comandos para el manejo de procesos.

Si queremos imprimir una información mínima sobre los procesos asociados con la sesión actual, podemos usar el comando jobs (su demonio jobd). jobs muestra el ID de las tareas, útil si queremos conocer cuantos programas continúan abierto antes de cerrar sesión, etc…

Al existir procesos en primer y segundo plano, jobs puede ser una buena alternativa para manejar esto.

Ejemplo:

Imaginemos que estamos trabajando con una terminal y ejecutamos un solo comando el cual nos va a bloquear el uso de la terminal debido a la ejecución de un programa, si pulsamos Control-Z suspenderemos ese programa retomando el control de la terminal, ahora para volver a tener el control del programa escribimos fg (foreground, primer plano) o bien si queremos que el programa siga ejecutándose pero en segundo planos escribiremos bg (background, segundo plano).

Ahora es cuando hacemos uso de jobs, imaginemos en que vez de 1 programas ya tenemos 2 (el anterior que ahora corre en segundo plano y uno nuevo que hemos mandado a segundo plano también), supongamos que deseamos enviar a primer plano el primer programa, bastaría con escribir fg, pero al tener 2 programas necesitamos conocer su ID, para ello $jobs nos mostrará el ID y el nombre del programa (empezando desde 1), suponiendo que es 1 el ID, escribimos fg 1 (también $fg %1), ahora con el control de ese programa en primer plano, escribimos Control-C si queremos finalizarlo.

El uso del metacaracter ‘%‘ es importante, ya que permite enviar/reanudar un trabajo concreto. Suponiendo que tenemos 2 programas con IDs 1 y 2 en segundo plano y detenidos, podríamos reanudar por ejemplo uno de ellos con:

$bg %2

Otra forma de iniciar un programa en segundo plano es mediante el uso de &:

 $nedit archivo.txt &

Nota: inicia el editor en segundo plano, permitiéndote el uso de la terminal.

Si quisiéramos esperar a que todos los trabajos en background terminaran para retomar el control de la terminal, podríamos usar el comando wait si ningún parámetro, esperar a que termine el trabajo con ID 2 (pasandole el parámetro %2) o bien, en vez de pasar un ID de job, podemos pasar directamente el PID de un proceso.

Si lo que queremos es ejecutar un programa desde una terminal (ya sea en primer o segundo plano) pero que siga ejecutándose una vez cerrada esta, podemos usar los comandos nohup o screen.

El comando nohup lo que hace es ignorar la señal SIGHUP, es decir la producida al cerrar la terminal, por lo que el comando/programa se mantiene en ejecución una vez cerrada esta. Su uso es básico, se le pasa como argumento el comando/programa que queremos ejecutar.

Screen trabaja de forma diferente a nohup pero igualmente nos permite ejecutar programas aun habiendo «cerrado» la terminal. Esto no es del todo cierto, pues en realidad la terminal desde la que lanzamos el comando no se cierra o mejor dicho su proceso no se mata. Supongamos que estamos trabajando en un servidor Linux, desde un equipo remoto (ya sea a través de putty en un equipo Windows o una terminal en un cliente Linux) o desde una terminal del mismo servidor, y queremos realizar una copia de seguridad de una parte pesada del servidor (lo que llevará horas…) el problema es que no queda mas de 30 minutos para terminar nuestro día laboral, es el momento de crear una terminal virtual con screen, por lo que en la terminal que tenemos abierta tecleamos screen y esto producirá un leve parpadeo, emitirá un mensaje o simplemente no hará nada, pero tenemos que saber que desde ese momento tenemos abierta una terminal virtual. Ahora lanzamos el respaldo contra el servidor y llega el momento de irse a casa, pues nada, cerramos nuestra terminal (no con exit, si no simplemente cerramos las ventanas), apagamos nuestra máquina cliente y nos marchamos a casa. A la mañana siguiente nos conectamos a una terminal del servidor, bien de forma remota o local y tecleamos $screen -ls, lo que nos mostrará cuantas terminales virtuales tenemos abiertas y sus id, para conectarnos a una en concreto escribimos $screen -r la_ID y accederemos a la terminal virtual que abrimos el día anterior para lanzar la copia de seguridad. Si sabemos que solamente tenemos una terminal abierta bastará con escribir $screen -r e igualmente tomaremos el control de la terminal en la que ejecutamos nuestro respaldo, ahora tendremos el control sobre esa terminal, de modo que podemos comprobar como ha ido la copia de seguridad. Una vez finalizado nuestro trabajo con la terminal virtual escribiremos exit y cerraremos así la terminal de forma definitiva.

 

Prioridad de los procesos

• Para tener un control sobre la prioridad de los procesos en cuanto a la demanda de tiempo en CPU usamos los comandos nice y renice.
• El comando nice permite ejecutar un programa con una prioridad especificada, mientras que renice permite la modificación de esa prioridad mientras el programa se encuentra en ejecución.
• La prioridad de los programas va desde el -20 al 19, siendo los números negativos los de mayor prioridad o prioridad incrementada (solo root puede usar la prioridad incrementada) y los positivos para una prioridad baja.
• La prioridad de ejecución de un programa por defecto es 0 y la prioridad por defecto utilizando nice (en caso de no pasar ningún valor de regulación) es 10, por el contrario si renice no recibe ningún argumento de prioridad asume que el número es un PID.

renice además puede recibir como parámetros un número de PIDs (-p), varios GIDs de grupos (-g) o varios UIDs (-u), solo root puede alterar la prioridad para los grupos y usuarios.

 

Destruir procesos.

A veces, no solo basta con reducir la prioridad de un programa, si no que necesitamos pararlo, por ejemplo por que se haya quedado bloqueado. Para tal fin podremos usar algunas herramientas como: kill, killall o pkill.

Antes de entrar en detalle con las herramientas, vamos a comentar el funcionamiento de «matar un proceso».

Linux utiliza una serie de señales para comunicarse con los procesos (SIGKILL, SIGHUP, SIGTERM…), siendo el kernel, el usuario o el propio programa el encargado de enviar algunas de estas señales.

Para finalizar un proceso será kill el programa que envíe esa señal, señal que podremos pasar como parámetro, bien por su nombre largo (-s señal), por su nombre pero sin «SIG» (–señal, -KILL) o directamente por su número (–num). Si no especificamos una señal, kill envía la señal por defecto SIGTERM (15) que permite cerrar el programa de la forma mas limpia, esto es, cerrando sus archivos, cerrando conexiones, limpiando su búfer,etc…

Vamos a ver algunas de estas señales:

$kill -l 

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5)SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10)SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15)SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20)SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25)SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30)SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37)SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42)SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47)SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52)SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57)SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62)SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX

1) SIGHUP: Cierra los programas interactivos y hace que muchos demonios vuelvan a leer su archivo de configuración. Es la que se genera por ejemplo cuando cerramos la terminal.

2) SIGINT: Interrupción. Se produce cuando el usuario pulsa la combinación de teclas Control-C, Puede ser ignorada por un manejador de señales.

3) SIGQUIT: Igual a SIGINT, pero se produce al pulsar Control-\ y además se crea un archivo .core (volcado).

7) SIGBUS: Se produce cuando se intenta acceder de forma errónea a una zona de memoria o dirección inexistente. Su acción es terminar el proceso que la recibe.

9) SIGKILL: No puede ser ignorada por el manejador de señales, y ni su rutina puede ser modificada. Provoca irremediablemente la terminación del proceso sin realizar las tareas de finalización de rutinas.

13) SIGPIPE: Intento de escritura en una tubería en la que nadie está leyendo. Suele ocurrir cuando un proceso de lectura termina de forma anormal. Su acción es terminar el proceso.

15) SIGTERM: Terminar un proceso de forma «limpia», es decir cerrando conexiones, archivos, limpiado búfer…

18) SIGCONT: Continúa un proceso

19) SIGSTOP: Para un proceso

31) SIGSYS: Se envía cuando se produce un argumento erróneo en una llamada al sistema.

Ahora que conocemos algunas de las señales, vamos a nombrar alguna de las herramientas útiles:

• kill : Envía una señal de finalización de proceso
• pkill: Es idéntico al comando pgrep (busca PIDs de procesos según patrón) y además una vez encontrado los mata. Es posible pasarle señales como argumento, al igual que se hace con kill.
• killall: Este comando destruye un programa en función de su nombre y no de su PID. Se le puede pasar una señal a través de la opción -s o –signal. Existe una variante de killall en versiones de Unix, que lo que hacen es matar todos los procesos iniciados por un determinado usuario. $killall alberto

Nota: Como siempre, para ampliar la información sobre los comandos acuda a la página de comandos LPIC-1

 

Notas para el exámen

• Comandos para la gestión de paquetes (rpm, yum, dpkg, apt-get, apt-cache, dselect y aptitude)
• Compilación de paquetes: Uso, compilación en diferentes arquitecturas, compatibilidades entre arquitecturas y distribuciones…
• Gestión de librerías: instalar, eliminar, añadir nuevas rutas de  librerías…

---

 Comandos Capítulo 2

• Comandos para la administración de paquetes y dependencias
• Comandos para la administración de librerías
• Comandos para la compilación de paquetes
• Comandos para la conversión de paquetes RPM, Debian, stampede y tarball
• Comandos para la administración de procesos del sistema

 

Curso LPIC-1 400 Capítulo 2 por nebul4ck se distribuye bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.