¿Copia lenta de archivos a memorias USB?

Algo que me encanta de ArchLinux es que cada vez que me enfrento a un problema, siempre encuentro información al respecto en la wiki y/o en los foros; desde el primer día en que empecé a utilizar esta maravillosa distro, todos los días he aprendido algo nuevo… y esta ocasión no es la excepción.

El problema: Pobre desempeño al copiar o mover archivos (en particular los “pesados”, pero no es exclusivo) a una memoria USB o pendrive, en especial al usar KDE (de nuevo, el Desktop Environment tampoco es exclusivo).

La solución: En la wiki se menciona un procedimiento, pero editando el archivo /etc/rc.local, el cual sabemos ya no existe con la llegada de systemd, así que tuve que “modernizarlo” basándome en un par de guías. El resultado a continuación.

Paso 0

No usen sudo para crear/editar los archivos de los pasos siguiente, mejor entren al usuario root con el comando su -:

[gespadas@localhost ~]$ su -
Contraseña: ******
[root@localhost ~]#

Ahora si, pueden seguir leyendo.

Paso 1

Vamos a crear el archivo /etc/tmpfiles.d/disable-hugepage.conf (realmente puede llamarse como gusten). Para ello usaré:

vim /etc/tmpfiles.d/disable-hugepage.conf

¿No les gusta vim? ¡Muy mal! Ok ok, pueden usar el editor que deseen ;-)

Ahí, el contenido del archivo será el siguiente:

w /sys/kernel/mm/transparent_hugepage/enabled - - - - madvise
w /sys/kernel/mm/transparent_hugepage/defrag - - - - madvise
w /sys/kernel/mm/transparent_hugepage/khugepaged/defrag - - - - 0

Las primeras dos líneas están escribiendo el valor madvise al archivo indicado (algo como hacer un echo madvise > /sys/.../archivo), y la última línea hace lo mismo, pero escribiendo el valor 0.

No quiero profundizar en lo que significa lo anterior (¡lean las referencias que pongo!), pero brevemente les comento que estamos estableciendo durante el booteo (por eso usamos tmpfiles) los parámetros transparent hugepages y hugepage defragmentation del kernel.

Paso 2

Adicionalmente, editen el archivo /etc/sysctl.conf (ese si existe, su función es la de establecer parámetros del kernel en tiempo de ejecúción):

vim /etc/sysctl.conf

Y al final pongan lo siguiente:

kernel.shmmax=134217728
vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 4194304

¿Por qué esos números? 134,217,728 bytes = 128 MB y 4,194,304 bytes = 4 MB.

¿Y por qué esos parámetros? Ayudan a reducir el efecto freeze en KDE.

¿Les da miedo editar un archivo que se mete directamente con el kernel? ¡Deberían! Es por eso que una solución más elegante, más acorde a la filosofía de systemd, es crear un archivo .conf dentro de la carpeta /etc/sysctl.d/ (similar a lo que hicimos en el paso 1). Por ejemplo, el archivo podría llamarse /etc/sysctl.d/disable-freeze.conf, cuyo contenido serían las tres líneas antes descritas.

Paso Extra

Si el desempeño mejoró, pero no lo suficiente, repitan el paso 1, pero usando el valor never en vez de madvise. ¡Atención! Hay efectos colaterales, y el más molesto es que la hibernación del sistema ya no funcionará.

Share

ConsoleKit es reemplazado por systemd-logind en ArchLinux

¡Más cambios en ArchLinux! Hoy amanecimos con la tremenda noticia de que ConsoleKit ha sido eliminado de los repositorios oficiales, y que toda su funcionalidad ahora es responsabilidad de systemd-logind.

¡El pánico se apodera de todos los archeros del mundo! ¡Es el apocalipsis que los mayas predijeron! … Jajaja, nada más alejado de la realidad. Sin embargo, el anuncio es demasiado escueto y no proporciona mayores detalles sobre las implicaciones de este cambio, así que me puse a investigar de inmediato y a hacer varias pruebas. Aquí el resultado.

¿Qué rayos es eso de ConsoleKit y systemd-logind?

Por si no lo sabías, ConsoleKit era utilizado para dos cosas principalmente: Permitir a usuarios normales (no root) montar dispositivos removibles (como pendrives o memorias USB), así como permitir suspender, reiniciar y apagar el sistema. Incluso, es muy probable que en tu archivo ~/.xinitrc tengas algo como ésto:

exec ck-launch-session openbox-session

El “ck-launch-session” era lo que permitía que tu usuario pudiera hacer lo que mencioné previamente. Ahora el encargado de hacerlo es systemd-logind, y aunque este detalle no se menciona en el anuncio oficial, si podemos encontrarlo en una reciente modificación en la wiki de Arch, y cito textualmente:

All PolicyKit actions like suspending the system or mounting external drives will work out of the box.

¡Así que no hay nada que temer! Sólo hay un “pequeño” requisito… ¡ya estar usando systemd!

Como observación adicional, con logind las X (el entorno gráfico) se ejecutan en el mismo tty donde se inició sesión, mientras que con ck-launch-session se creaba una nueva sesión.

¿Qué implica que ConsoleKit ya no esté en los repositorios?

En instalaciones existentes, al actualizar el sistema no se eliminará ConsoleKit, o sea, que aún puede seguirse usando, aunque ya no tiene sentido.

En instalaciones nuevas, ya no podrá instalarse ConsoleKit (aunque parece que pronto estará disponible desde AUR, pero repito, no tiene sentido), lo cual implícitamente nos estará obligando a realizar una instalación basada en systemd.

¿Qué cambios debo hacer en mi sistema?

No mucho. Primero, ¡actualiza!

sudo pacman -Syu

Es muy importante actualizar, para que los últimos cambios se apliquen, pues incluyen paquetes a los cuales se les ha eliminado su respectiva dependencia con ConsoleKit.

Ahora, ya puedes eliminar ConsoleKit, no debes tener problemas de dependencias.

sudo pacman -R consolekit

En caso de ser necesario, no olvides eliminar “ck-launch-session” de tu archivo ~/.xinitrc.

Eso es todo, ya puedes reiniciar y verificar que todo funcione bien.

Adicionalmente, les recomiendo usar el siguiente comando para ver información sobre la sesión actual.

loginctl

Para información más detallada, pueden usar lo siguiente.

loginctl show-session $XDG_SESSION_ID

¿Eso es todo?

¡Si! Bye bye ConsoleKit :-)

Share

Instalación y configuración del entorno LAMP (Apache + PHP + MySQL) en ArchLinux con systemd

ArchLinux systemd LAMP

Ahora que las nuevas instalaciones de ArchLinux usan systemd de manera predeterminada, algunas cosas han cambiado, entre ellas, ciertos detalles en la instalación y configuración del entorno LAMP (Linux + Apache + MySQL + PHP).

Aprovechando que hace unos días realicé una instalación limpia en mi equipo de producción, también lo hice con dicha instalación y configuración, misma que comparto con ustedes en el presente tutorial.

[Actualización 2014-03-10] ¡Ha llegado Apache 2.4 a ArchLinux! Es un cambio importante y requiere nuestra intervención manual para hacer que nuestro servidor LAMP vuelva a funcionar sin problemas.

Paso 1. Instalación de los paquetes necesarios

Antes que nada, instalemos los paquetes básicos que necesitaremos.

sudo pacman -S apache php php-apache mysql

Paso 2. Ejecutando Apache

Ejecutemos (vía systemd) nuestro servidor web Apache con las configuraciones predeterminadas:

sudo systemctl start httpd.service

Adicionalmente, para que Apache se ejecute de manera automática en los siguientes booteos, usa:

sudo systemctl enable httpd.service

Ahora bien, ¿cómo se llama tu servidor? Eso lo tienes establecido en dos archivos: /etc/hostname y /etc/hosts. Lo más común es que en ambos tengas localhost. Si no es así, reemplaza “localhost” por tu nombre de servidor en el resto del tutorial.

En tu navegador web favorito, entra a http://localhost/ o http://127.0.0.1/ donde veremos algo similar a la siguiente captura de pantalla.

Apache corriendo en ArchLinux con systemd

¡Muy feo! ¿verdad? Es porque localhost no tiene ningún contenido, ¡así que vamos a solucionarlo!.

Paso 3. Creando nuestro index.html

Antes de crear nuestro index.html, debemos tener en cuenta dos detalles que se encuentran establecidos en /etc/httpd/conf/httpd.conf (el archivo de configuración principal de Apache en ArchLinux):

  • Durante el booteo del sistema, el encargado de ejecutar Apache es root, pero por motivos de seguridad, de inmediato se cambia al usuario http (que a su vez pertenece al grupo http).

  • La carpeta predeterminada para el contenido de localhost es /srv/http, cuyo propietario es root de manera predeterminada.

Debido a lo anterior, debemos realizar algunas acciones para poder empezar a crear contenido en nuestro servidor web local.

  1. Primero, debemos agregar nuestro usuario al grupo http.

    sudo gpasswd -a miusuario http

    Debemos cerrar nuestra sesión actual y volver a loguearnos para que el cambio sea aplicado.

  2. Ahora, debemos ceder la propiedad de root a http (tanto para el usuario como para el grupo) de manera recursiva para /srv/http.

    sudo chown -R http:http /srv/http
  3. Debemos establecer permisos de escritura para el grupo http (al cual nos hemos agregado) para la misma carpeta (y todo su contenido).

    sudo chmod -R g+w /srv/http

Ahora si, ya podemos crear nuestro index.html, el cual puede ser desde una simple línea de texto …

echo 'Hola Mundo!' > /srv/http/index.html

… hasta algo más elaborado (usa tu editor preferido y guardalo como index.html en /srv/http/).

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="utf-8">
    <title>¡Bienvenidos a ArchLinux!</title>
    <style>
        body { margin: 0; font-family: Helvetica, Arial, sans-serif; }
        h1 { background: #ccc; margin: 0; padding: 10px; }
        #contenido { margin: 10px auto; padding: 10px; width: 500px; }
    </style>
</head>
<body>
<div id="contenido">
    <h1>¡Bienvenido!</h1>
    <p><strong>Apache</strong> corriendo bajo <strong>ArchLinux</strong> con <strong>systemd</strong>.</p>
</div>
</body>
</html>

index.html en funcionamiento

Paso 4. Configurando PHP

Este paso es el típico de siempre. Vamos a configurar Apache para que reconozca a PHP.

Primero, como root, abre el archivo /etc/httpd/conf/httpd.conf con tu editor favorito. Por ejemplo:

sudo vim /etc/httpd/conf/httpd.conf

Ahí, realiza los siguientes cambios:

  1. En la lista que tiene todos los “LoadModule“, y después de LoadModule dir_module modules/mod_dir.so, agrega la línea:

    LoadModule php5_module modules/libphp5.so
  2. Al final de la lista de todos los “Include“, agrega la línea:

    Include conf/extra/php5_module.conf
  3. Asegúrate que la siguiente línea no esté comentada (que no tenga “#” al inicio) en la sección :

    TypesConfig conf/mime.types
  4. Descomenta (elimina el “#” del inicio) la siguiente línea:

    MIMEMagicFile conf/magic

Ahora, como root, abre el archivo /etc/httpd/conf/mime.types con tu editor preferido (¡seguro que es vim!). Por ejemplo:

sudo vim /etc/httpd/conf/mime.types

Al final de dicho archivo agrega la línea:

application/x-httpd-php5            php php5

¡Listo! Reiniciemos Apache para aplicar los cambios:

sudo systemctl restart httpd.service

Para probar que Apache ya reconoce a PHP, vamos a crear el típico archivo de ejemplo:

echo '<?php phpinfo(); ?>' > /srv/http/info.php

Y finalmente, para verlo entra a tu navegador web, y entra a http://localhost/info.php

PHP reconocido por Apache

Paso 5. Configurando MySQL

Primero, vamos a ejecutar de inmediato el servidor de base de datos MySQL con:

sudo systemctl start mysqld.service

Para que se ejecute en cada booteo, usamos:

sudo systemctl enable mysqld.service

Y antes de que hagamos cualquier otra cosa, debemos establecer la contraseña del usuario “root” de MySQL (no es el mismo que el root del sistema). La forma más sencilla de hacerlo, es ejecutar la siguiente utilería:

mysql_secure_installation

Lo anterior nos preguntará primero la contraseña actual de root, la cual no existe, así que debemos dar [Enter], y entonces escribir (y confirmar) la nueva contraseña. Adicionalmente, la utilería nos preguntará algunos detalles adicionales, a los cuales se sugiere responder las opciones predeterminadas.

Ahora, tenemos que decirle a PHP de la existencia de MySQL. Vamos a abrir el archivo /etc/php/php.ini con tu editor favorito …

sudo vim /etc/php/php.ini

… y descomentar (eliminar el “;” al inicio) las siguientes líneas:

 extension=mysqli.so
 extension=mysql.so

Si deseas realizar alguna modificación en los parámetros de MySQL debes hacerlo editando el archivo /etc/mysql/my.cnf.

Finalmente, reiniciemos Apache y MySQL para aplicar los cambios realizados.

sudo systemctl restart httpd.service
sudo systemctl restart mysqld.service

Comentarios Adicionales

Aunque ya los mencioné, no olviden que los archivos de configuración son:

  • Apache: /etc/httpd/conf/httpd.conf
  • PHP: /etc/php/php.ini
  • MySQL: /etc/mysql/my.cnf

Tampoco olviden que bajo systemd, se utilizan los comandos:

  • Habilitar para cada booteo: sudo systemctl enable <servicio>
  • Ejecutar de inmediato: sudo systemctl start <servicio>
  • Detener de inmediato: sudo systemctl stop <servicio>
  • Reiniciar de inmediato: sudo systemctl restart <servicio>
  • Ver el estado del servicio: sudo systemctl status <servicio>

Donde <servicio> puede ser alguno de los siguientes:

  • Apache: httpd.service
  • MySQL: mysqld.service

Por último, no olviden consultar la documentación oficial para más información:

Share

Migrando a systemd en ArchLinux

Aunque ya son meses de planes y avisos, hace apenas un par de semanas se dió a conocer que ArchLinux reemplazará sysvinit (así como initscripts) por systemd, lo cual ha causado mucha polémica. El cambio ha sido gradual: Hace tres meses, udev fue reemplazado por (fusionado en) el paquete systemd-tools, y hace apenas unas horas este último, al igual que libsystemd, acaban de ser reemplazados por el mismísimo paquete systemd. La migración definitiva está muy próxima, ¡debes estar preparado!

Si eres usuario de ArchLinux seguro te estás preguntando: ¿Debemos migrar en este momento?, ¿qué implica usar systemd?, ¿qué ventajas me ofrece con respecto a sysvinit?, o peor aún, ¿qué rayos es eso de systemd y sysvinit?

Luego de haber leído bastante documentación (referencias al final de este post) y de haber realizado varias pruebas (primero en una máquina virtual y luego en mi sistema principal), trataré de responder a cada una de esas preguntas.

Un poco de historia

En los sistemas operativos basados en UNIX (Linux, FreeBSD, MacOS X, etc) existe un proceso especial, el primero generado por el kernel y en ejecutarse durante el booteo, conocido como init (el cual obviamente tiene el PID número 1), el cual se encarga de ejecutar el resto de los procesos del sistema, e incluso sigue activo como daemon (comunicándose constantemente con el kernel) hasta que el usuario apaga o reinicia el equipo, momento en que dicho proceso ejecuta todo lo necesario para cerrar el sistema.

Desde sus inicios, y hasta la fecha, la mayoría de las distros de Linux utilizan sysvinit. A primera vista podemos darnos cuenta que su nombre proviene de SysV init, o UNIX System V init system, con lo cual nos damos una idea de lo veterano que es este proceso de inicialización (por no decir viejo y obsoleto).

¿Qué alternativas modernas existen?

  • Existe launchd, pero es exclusivo del sistema MacOS X.

  • En 2006 fue liberado Upstart, desarrollado por Scott James Remnant (ex empleado de Canonical, ahora trabaja en Google). Este proceso es usado principalmente por Ubuntu y Chrome OS. Algunas otras distros, como Fedora, lo implementaron en algunas de sus versiones, pero han optado por una mejor opción (sigue leyendo).

  • ¡Y llegó systemd!, liberado apenas en 2010. Su desarrollador principal es Lennart Poettering, creador del conocido PulseAudio (actualmente labora para RedHat). Debido a sus fantásticas características, hoy día es usado de manera predeterminada en distros populares como Fedora y OpenSUSE, por lo que podemos inferir que, a pesar de su corta vida, systemd ya está listo para nivel producción.

Beneficios de systemd

Los principales beneficios de systemd comparado con sysvinit / initscripts son:

  • Tiene capacidades “hotplug”, o sea, systemd asume que todos los recursos del sistema pueden aparecer o desaparecer en cualquier momento. Si conectamos un disco duro externo después de que systemd ha iniciado, se encargará de aplicarle fsck y montarlo correctamente, a diferencia de initscripts que necesita que todos los discos se encuentren enumerados y listos cuando ejecuta fsck para luego montarlos.

  • Podemos saber el estado del sistema en cualquier momento, ya que systemd lleva un registro (journal) mediante cgroups (ya no más PIDs) de todos los daemons y procesos que ha iniciado, quién es el dueño, cuál ha fallado, etc.

  • Es modular. Todo el contenido ejecutado por initscripts en /etc/rc.sysinit ahora es dividido en varios servicios independientes, cada uno de ellos bien documentado y de fácil comprensión. ¡Puedes crear tus propios servicios!

  • Actualmente udev (que incluso ha sido fusionado en systemd) y dbus son usados (inapropiadamente) para iniciar daemons y servicios sobre demanda. Con systemd todo ese trabajo está cubierto, pues es una de sus funciones principales.

  • Actualmente debemos especificar y tener mucho cuidado en el orden de los daemons en la sección DAEMONS del archivo /etc/rc.config. Con systemd se utiliza la activación de daemons por medio de sockets, aportando capacidades de paralelización.

  • Actualmente es bastante complicado implementar seguridad vía sandboxing a cada script rc (/etc/rc.sysinit,/etc/rc.single,/etc/rc.multi, etc). Con systemd sólo necesitamos agregar unas simples opciones de configuración a los archivos de cada unit (de las cuales hablaré más adelante) para aislarlas del sistema de diversas maneras.

  • Los archivos de servicio de systemd pueden ser escritos y distribuidos por cualquier usuario, en vez de los scripts rc escritos específicamente para cada distro. De esta manera, la colaboración entre usuarios y desarrolladores de systemd puede lograr la creación de servicios “perfectos”, que deberían funcionar en cualquier distro.

  • Por origen, systemd es un proyecto “cross-distro“, donde colaboran desarrolladores de todas las grandes y muchas pequeñas distros.

  • Y como ya se lo pueden imaginar, ¡systemd es muy rápido!. Es notable la reducción del tiempo al momento del booteo, incluso al cerrar el sistema es mucho, ¡pero mucho más rápido! (comparado con sysvinit/initscripts, por supuesto). Toda esta velocidad es básicamente un “efecto secundario” de todas las bondades descritas en los puntos anteriores.

La lista anterior no es exhaustiva, ¡hay más beneficios al usar systemd!

Preparando nuestro ArchLinux para systemd

Seguro que después de haber leído la lista anterior quieres salir corriendo para instalar systemd… ¡no lo hagas! Antes necesitas preparar tu sistema antes de la migración.

Lo primero que debemos hacer, es revisar nuestro querido y viejo archivo /etc/rc.conf (el cual es usado por initscripts), pues prácticamente ya no será utilizado con systemd, por lo que debemos migrar toda las configuraciones ahí contenidas por el nuevo esquema de configuración:

  • El valor de HOSTNAME ahora se establece en el archivo /etc/hostname (el nombre de nuestro hostname, por ejemplo localhost, es lo único que debe tener dicho archivo). También hay que ajustar el archivo /etc/hosts para que coincidan.

  • El valor de TIMEZONE ahora se establece por medio de un symlink de /etc/localtime a /usr/share/zoneinfo/<ZONA>/<SUBZONA> (reemplaza <ZONA> y <SUBZONA> según tu ubicación geográfica). Por ejemplo, para México:

    ln -s /usr/share/zoneinfo/America/Mexico_City /etc/localtime
  • Los valores de KEYMAP, CONSOLEFONT y CONSOLEMAP ahora se establecen en el archivo /etc/vconsole.conf (el cual debes crear).

    • KEYMAP especifica la distribución del teclado. Las opciones disponibles se encuentran en /usr/share/kbd/keymaps.

    • CONSOLEFONT especifica la fuente (tipo de letra) a usar en la consola (el programa setfont toma este valor durante el booteo). Las opciones disponibles se encuentran en /usr/share/kbd/consolefonts. También puede usarse FONT. Esta configuración es opcional.

    • CONSOLEMAP especifica el mapa de consola correspondiente, que también es leído por setfont. Las opciones disponibles se encuentran en /usr/share/kbd/consoletrans. También puede usarse FONT_MAP. Esta configuración es opcional.

    Por ejemplo:

    KEYMAP=es
    CONSOLEFONT=lat9w-16
    CONSOLEMAP=8859-1_to_uni
  • El valor de LOCALE (el cual especifica el idioma del sistema y de la mayoría de las aplicaciones) ahora se establece en el archivo /etc/locale.gen, donde debemos descomentar (eliminar el “#” al inicio de la línea) la localización deseada. Por ejemplo, para soporte UTF-8 en Español para México:

    ...
    #es_HN ISO-8859-1
    es_MX.UTF-8 UTF-8
    #es_MX ISO-8859-1
    ...

    Para aplicar los cambios realizados, debemos ejecutar el comando locale-gen.

    También es buena idea establecer dicho valor con la variable LANG en el archivo /etc/locale.conf, donde también podemos establecer otros valores interesantes, como LC_COLLATE, que especifica cómo se ordenan los archivos al ejecutar el comando ls. Ejemplo:

    LANG="es_MX.UTF-8"
    LC_COLLATE="C"
  • Los valores (lista separada por espacios) de MODULES ahora deben establecerse en uno o más archivos del tipo <MODULO>.conf: En el directorio /etc/modules-load.d/ los módulos para ser cargados incondicionalmente durante el booteo, y en /etc/modprobe.d/ (normalmente usado por udev para cargar módulos sobre demanda) los módulos que no se auto ejecutarán (anteponiendo la palabra blacklist). Ejemplos:

    # /etc/modules-load.d/virtualbox.conf
    vboxdrv
    # /etc/modprobe.d/nobeep.conf
    blacklist pcspkr

Puedes poner varios módulos en un sólo archivo .conf, pero cada uno en una línea aparte.

¿Y los valores de DAEMONS? Esos no los cambiaremos por el momento (es lo único que debemos dejar habilitado en /etc/rc.conf). Lo que si haremos es tener muy presente qué daemons son los que ahí se encuentran. Posteriormente (luego de instalar systemd), migraremos cada daemon a su respectiva unidad de servicio (no se desesperen, ya llegaremos a este punto).

Instalación de systemd en ArchLinux

¡Por fin! Luego de tanta introducción y preparación, hemos llegado al punto clave, ¡instalemos systemd en nuestro querido ArchLinux!

  1. Antes que nada, ¡actualiza tu sistema!

    sudo pacman -Syu
  2. Ya debes tener instalado el paquete systemd (vuelve a leer el primer párrafo de este post). De todas formas, lo puedes instalar con el comando:

    sudo pacman -S systemd
  3. A pesar de que ya instalamos systemd, si reiniciamos nuestro equipo, de nuevo sysvinit e initscripts se ejecutarán, ya que aún estamos en un “esquema mixto” (para ver que todo funciona bien). Lo que haremos entonces, es agregar init=/bin/systemd a los parámetros del kernel del bootloader que utilices.

    • Si usas Grub Legacy, edita el archivo /boot/grub/menu.lst y modifica la línea que inicia con kernel.

      title Arch Linux
      root (hd0,0)
      kernel /vmlinuz-linux root=/dev/sda3 ro quiet init=/bin/systemd
      initrd /initramfs-linux.img
    • Si usas Grub2, edita el archivo /etc/default/grub y modifica la línea que inicia con GRUB_CMDLINE_LINUX_DEFAULT.

      GRUB_DISTRIBUTOR="Arch Linux"
      GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/bin/systemd"
      GRUB_CMDLINE_LINUX=""

      Es necesario actualizar Grub2 con el comando

      sudo grub-mkconfig -o /boot/grub/grub.cfg
    • Si usas syslinux, edita el archivo /boot/syslinux/syslinux.cfg y modifica la línea que inicia con APPEND.

      LABEL arch
      MENU LABEL Arch Linux
      LINUX ../vmlinuz-linux
      APPEND root=/dev/sda3 ro quiet init=/bin/systemd
      INITRD ../initramfs-linux.img

    ¡Nota! A pesar de que en los ejemplos incluí el parámetro quiet, es recomendable no incluirlo las primeras veces que iniciamos el sistema con systemd, para poder verificar que todo esté funcionando adecuadamente.

  4. ¡Reinicia el sistema! Ahora el proceso de booteo estará a cargo de systemd. ¿Algún problema? Ya que seguimos en un esquema mixto, puedes eliminar init=/bin/systemd de los parámetros del kernel para bootear nuevamente con sysvinit e initscripts, y así puedas corregir algún error.

    ¿Todo bien? ¡Sigue leyendo!

  5. ¿Recuerdas que mencioné que no olvidaras qué daemons teníamos en /etc/rc.conf? ¡Ahora es momento de migrarlos a systemd! Cada daemon debe tener su correspondiente unidad de servicio (las que explicaré a fondo en la siguiente sección), y cada una de ellas debemos habilitarlas (para que se ejecuten automáticamente al momento del booteo) por medio del comando:

    sudo systemctl enable <NOMBRE_DEL_SERVICIO>.service

    Algunos ejemplos (daemons con sus respectivas unidades de servicio):

    • network (Conexión ethernet por DHCP)

      sudo systemctl enable dhcpcd@eth0.service
    • networkmanager (Reemplazo de network)

      sudo systemctl enable NetworkManager.service
    • wicd (Reemplazo de network, más ligero que networkmanager)

      sudo systemctl enable wicd.service
    • crond (Programación de eventos)

      sudo systemctl enable cronie.service
    • cupsd (Common UNIX Printing System)

      sudo systemctl enable cupsd.service
    • ntpd (Cliente y servidor del Network Time Protocol)

      sudo systemctl enable ntpd.service
    • samba (Servicios de archivos e impresión para clientes de Microsoft Windows)

      sudo systemctl enable smbd.service
    • nginx (Servidor Web Nginx)

      sudo systemctl enable nginx.service
    • mysqld (Servidor de Base de Datos MySQL)

      sudo systemctl enable mysqld.service
    • postgresql (Servidor de Base de Datos PostgreSQL)

      sudo systemctl enable postgresql.service
    • gdm (Gnome Display Manager)

      sudo systemctl enable gdm.service
    • kdm (KDE Display Manager)

      sudo systemctl enable kdm.service
    • slim (Simple Login Manager, ¡mi preferido!)

      sudo systemctl enable slim.service

    Algunas observaciones muy importantes:

    • Algunos daemons no tenemos que habilitarlos explícitamente, como es el caso de dbus y netfs.

    • Algunos daemons desgraciadamente aún no tienen unidades de servicio (como dropboxd y httpd). Si no puedes prescindir de ellos, te recomiendo continúes con el esquema mixto (para que sigan siendo llamados desde la línea DAEMONS del archivo /etc/rc.conf), hasta que hayan sido implementados, lo cual no debe demorar mucho tiempo… ¡hay que ser pacientes!

    • El daemon syslog-ng (que normalmente es el primero en la línea DAEMONS del archivo /etc/rc.conf), causa conflictos con el nuevo syslog.socket, por lo que es necesario eliminarlo de la lista si planeamos seguir con el esquema mixto.

    Cuando estés seguro que ya no ejecutas ningún daemon especificado en el archivo /etc/rc.conf, entonces éste deja de tener utilidad. Te recomiendo hacerle un respaldo para recordar a nuestro viejo amigo, que tantos años nos acompañó.

  6. ¿Tienes personalizados los archivos /etc/rc.local y/o /etc/rc.local.shutdown? ¡Debes convertirlos a unidades de servicio! Pero ya que aún no sabemos cómo hacer eso, podemos darles soporte usando unas unidades de servicio especiales que llaman a ambos archivos.

    cp /usr/lib/systemd/system/rc-local{,-shutdown}.service /etc/systemd/system/
  7. Reinicia el sistema nuevamente. Si hay algún error, verifica de nuevo los pasos previos. ¿Todo bien? ¡Sigue leyendo!

  8. Cuando ya todo funcione perfectamente, ya podemos dar el paso definitivo del esquema mixto a un sistema systemd puro, y eso lo logramos instalando el paquete systemd-sysvcompat, el cual al mismo tiempo eliminará sysvinit e initscripts (éste último es probable que previamente tengas que eliminarlo manualmente con pacman -R), y le aplicará un pacsave a rc.conf, rc.local and rc.local.shutdown.

    sudo pacman -S systemd-sysvcompat
  9. Ya podemos eliminar init=/bin/systemd de nuestro parámetro del kernel (lo que hicimos en el paso 4), ya que ahora /sbin/init es un symlink a systemd.

¡Eso es todo! Si gustas puedes reiniciar nuevamente, para disfrutar al 100% de systemd en tu ArchLinux.

¡Ya tengo systemd! ¿Y ahora qué?

¡Ahora muchas cosas han cambiado! Acciones como ejecutar daemons, cambiar de runlevel, revisar el log del sistema o usar pm-utils para suspender o hibernar, ahora tienen un enfoque diferente, básicamente nos estamos enfrentando a un nuevo paradigma. En la presente sección les mencionaré los conceptos básicos para que empiecen a familiarizarse con systemd.

Previamente he mencionado el término “unidades de servicio“, pero no había explicado de qué se trataban exactamente. Una unidad o unit, no es más que un archivo de configuración que contiene información no sólo de servicios (.service, los más comunes, nuestros conocidos daemons), si no también de sockets (.socket), dispositivos (.device), puntos de montaje (.mount), puntos de auto-montaje (.automount), e incluso grupos de otras unidades (.target).

Como dato adicional, es interesante saber que la sintaxis de la información contenida en los archivos de las unidades está inspirada en los archivos .desktop de la especificación XDG Desktop Entry, que a su vez estuvo inspirada por… wait for it… ¡los archivos .ini de Microsoft Windows!, ironías de la vida.

Los archivos de unidades disponibles en nuestro sistema podemos encontrarlos en /usr/lib/systemd/system/ y /etc/systemd/system/ (éste último directorio toma precedencia en caso de duplicados).

Básicamente estaremos trabajando con el comando systemctl para interactuar con las diversas unidades de systemd. Algunos comandos de uso común son:

  • Listar las unidades que se estén ejecutando actualmente.

    systemctl

    o bien,

    systemctl list-units
  • Listar las unidades con errores.

    systemctl --failed
  • Listar las unidades instaladas.

    systemctl list-unit-files
  • Activar una unidad inmediatamente.

    systemctl start <unit>
  • Desactivar una unidad inmediatamente.

    systemctl stop <unit>
  • Reiniciar una unidad.

    systemctl restart <unit>
  • Recargar la configuración de una unidad.

    systemctl reload <unit>
  • Mostrar el estado de una unidad, esté o no en ejecución.

    systemctl status <unit>
  • Verificar si una unidad está habilitada.

    systemctl is-enabled <unit>
  • Habilitar una unidad para ejecutarse en cada booteo.

    systemctl enable <unit>
  • Deshabilitar una unidad para que no se ejecute en cada booteo.

    systemctl disable <unit>
  • Mostrar la ayuda asociada a una unidad (si se encuentra disponible).

    systemctl help <unit>

En el caso de la administración de energía del sistema, también debemos usar el comando systemctl. Si nos encontramos en una sesión de usuario de ConsoleKit, podemos ejecutar los siguientes comandos sin necesidad de privilegios de root (a no ser que haya otra sesión activa):

  • Cerrar y reiniciar el sistema.

    systemctl reboot
  • Cerrar y apagar el sistema.

    systemctl poweroff
  • Cerrar y detener el sistema.

    systemctl halt
  • Suspender el sistema.

    systemctl suspend
  • Hibernar el sistema.

    systemctl hibernate

Ahora bien, los clásicos runlevels son un concepto de sysvinit, quien examinaba el archivo /etc/inittab (ahora obsoleto) para saber el valor de :initdefault:. El paradigma correspondiente en systemd son las unidades .target, que básicamente tienen el mismo propósito, pero con algunas diferencias, por ejemplo, cada target tiene un nombre, en vez de la clásica numeración de los runlevels:

  • Runlevel 0 = poweroff.target

  • Runlevel 1 = rescue.target

  • Runlevels 2, 3 y 4 = multi-user.target

  • Runlevel 5 = graphical.target

  • Runlevel 6 = reboot.target

Ejemplos de uso:

  • Para cambiarnos a otro target en la sesión actual (no afecta al siguiente booteo).

    systemctl isolate graphical.target
  • Para establecer un nuevo target predeterminado (el usado en cada booteo).

    systemctl enable multi-user.target

Por último, quisiera mencionarles un poco acerca del nuevo log del sistema, conocido como journal. Para revisarlo, basta usar el comando:

journalctl

El journal escribe en los archivos contenidos en el directorio /run/systemd/journal/, y por lo mismo, se pierden al reiniciar el sistema. Si deseamos logs persistentes, sólo debemos crear el directorio /var/log/journal/:

mkdir /var/log/journal/

¡Aclaración! En todos los comandos de esta sección omití el uso de sudo para facilitar la lectura de los comandos; no olviden incluirlo al inicio de ellos cuando sea necesario.

Referencias

Es importante que tomes en cuenta que todo lo expuesto en el presente post es meramente un resumen (si, ¡por largo que se vea!), y sólo describe los pasos generales al instalar y usar systemd en ArchLinux. Siempre habrán excepciones o casos especiales, por lo que les recomiendo leer, investigar y documentarse a fondo sobre el tema. Aquí les dejo una lista de referencias, que son las que usé para elaborar este tutorial.

Share