Soplona

Actividad de esDebian en tiempo real

No es necesario recargar el navegador

Panko: Comentario añadido
  • Problemas con establecer el navegador predeterminado en xfce Jessie

    Enviado por Panko el 23 Noviembre, 2014 - 11:20.

    En estos casos, creo que debes buscar también cual está como predeterminado en la alternativa gnome-www-browser, ya que no siempre lo que escojas en x-www-browser va a ser el predeterminado para todo. x-www-browser es el navegador predeterminado, digamos, para "xorg", pero muchos entornos gráficos usan su propia configuración, y varios de ellos tiran de gnome-www-browser, sobre todo en sistemas que incluyen gnome/gtk como entorno predeterminado.

rockyiii: libro añadido
  • SysVinit


    Actualizar Debian Wheezy a Jessie, manteniendo SysVinit como proceso de arranque

    Antes de proceder a la actualización de la nueva versión estable de Debian impediremos que se instale el paquete systemd-sysv

    # nano /etc/apt/preferences.d/use-sysvinit

    Dentro de este archivo ponemos el siguiente texto

    Package: systemd-sysv
    Pin: release o=Debian
    Pin-Priority: -1

    * Para guardar los cambios CTRL + o
    * Para salir del editor CTRL + x

    * Nota: el paso siguiente es actualizar el sistema, se da por sobreentendido que el lector ya sabe como realizar dicha tarea

    Una vez terminado de actualizar el sistema a Debian Jessie tendrá instalados los paquetes sysvinit, sysvinit-core y sysvinit-utils. Dependiendo del tipo de instalación que tenia en wheezy, seguramente tendrá los paquetes libsystemd0, systemd, y systemd-shim

    * Nota: al tener instalado systemd-shim no es necesario seguir bloqueando el paquete systemd-sysv

    # rm /etc/apt/preferences.d/use-sysvinit

    Instalar SysVinit en Debian Jessie

    Al realizar una instalación desde 0 de Debian Jessie notaremos que el paquete sysvinit y sysvinit-utils no se encuentran instalados, así que el primer paso es el de proceder a instalar dichos paquetes

    # aptitude install sysvinit sysvinit-utils

    En Debian Jessie para que sysvinit gestione el proceso de arranque es necesario instalar el paquete sysvinit-core que es incompatible con el paquete systemd-sysv. Por lo tanto al tratar de instalar sysvinit-core, cuando ya contamos con una instalación completa con gnome, kde, xlde, mate, etc, Aptitude nos pedirá eliminar systemd-sysv y una gran cantidad de paquetes, por lo que deberemos instalar previamente el emulador systemd-shim para luego instalar sysvinit-core y desinstalar systemd-sysv sin mas problemas

    1. Procediendo a instalar systemd-shim
    2. # aptitude install systemd-shim
      Se instalarán los siguiente paquetes NUEVOS:    
        cgmanager{a} libcgmanager0{a} libnih-dbus1{a} libnih1{a} systemd-shim
      0 paquetes actualizados, 5 nuevos instalados, 0 para eliminar y 0 sin actualizar.
      Necesito descargar 360 kB de ficheros. Después de desempaquetar se usarán 1.011 kB.
      ¿Quiere continuar? [Y/n/?] y
    3. Instalando sysvinit-core y desinstalar systemd-sysv

    4. # aptitude install sysvinit-core
      Se instalarán los siguiente paquetes NUEVOS:    
        sysvinit-core{b}
      0 paquetes actualizados, 1 nuevos instalados, 0 para eliminar y 0 sin actualizar.
      Necesito descargar 132 kB de ficheros. Después de desempaquetar se usarán 255 kB.
      No se satisfacen las dependencias de los siguientes paquetes:
      sysvinit-core : Entra en conflicto: systemd-sysv pero está instalado 215-5+b1.
      systemd-sysv : Entra en conflicto: sysvinit-core pero se va a instalar 2.88dsf-58.
      Las acciones siguientes resolverán estas dependencias

           Eliminar los paquetes siguientes:
      1)     systemd-sysv                  

      ¿Acepta esta solución? [Y/n/q/?]y
      Se instalarán los siguiente paquetes NUEVOS:
        sysvinit-core
      Se ELIMINARÁN los siguientes paquetes:
        systemd-sysv{a}
      0 paquetes actualizados, 1 nuevos instalados, 1 para eliminar y 0 sin actualizar.
      Necesito descargar 132 kB de ficheros. Después de desempaquetar se usarán 181 kB.
      ¿Quiere continuar? [Y/n/?]y

      * Para eliminar cualquier configuración residual podría ser conveniente ejecutar aptitude purge

      # aptitude purge systemd-sysv

      * Nota: si se realizó una instalación mínima o base de Debian Jessie, se podrían eliminar sin conflictos de dependencias, los paquetes systemd y systemd-shim, y bloquearlos

      # nano /etc/apt/preferences.d/use-sysvinit

      Dentro de este archivo se pondría el siguiente texto:

      Package: systemd  systemd-sysv systemd-shim
      Pin: release o=Debian
      Pin-Priority: -1

      * Nota: Hay que tener presente que se estaría reduciendo la cantidad de paquetes posibles de instalar ya que muchos dependen de systemd.

    Al reiniciar nuestro sistema sysvinit gestionara proceso de arranque


    Fuentes de referencia

    http://es.wikipedia.org/wiki/System_V
    http://centrodeartigo.com/articulos-informativos/article_62517.html
    http://www.ibiblio.org/pub/linux/docs/LuCaS/Manuales-LuCAS/RHAT/rhl-ig-6...
    http://people.skolelinux.org/pere/blog/How_to_stay_with_sysvinit_in_Debi...

rockyiii: libro actualizado
  • Systemd

    Introducción

    ¿qué es Systemd?

    Systemd es un sistema y un gestor de servicios para Linux, compatible con los init script SysV y LSB, y puede funcionar como un reemplazo para sysvinit.

    Dentro de sus características, Systemd:
    * Proporciona capacidades de paralelización agresivas.
    * Utiliza la activación de socket y D-Bus para iniciar los servicios
    * Permite el inicio de demonios bajo demanda
    * Realiza el seguimiento de procesos utilizando Linux cgroups
    * Implementa la lógica de control de servicios basados ​​en la dependencia transaccional
    * Realiza un seguimiento de los procesos con el uso de los grupos de control de Linux (cgroups)
    * Soporta copia instantánea de volumen (snapshotting) y la restauración de estado del sistema
    * Mantiene puntos de montaje y servicios de automontaje implementando un elaborado sistema de gestión de dependencias basado en un control lógico de los servicios


    Funcionamiento

    Systemd inicia y supervisa todo el sistema basándose en la noción de unidades compuestas con un nombre y tipo en coincidencia con un archivo de configuración que lleva el mismo nombre y tipo.


    Secuencia de arranque con systemd

    Una vez iniciada la pc y llegado al punto donde la BIOS pasa el control al gestor de arranque (grub. lilo , ) éste carga el sistema, kernel y una imagen minima en memoria (initrd) el kernel busca el directorio raiz del sistema ,una vez ubicado y montado el archivo raiz , initrd pasa el control a systemd
    Systemd carga los controladores , monta el sistema de archivos e inicializa todos los servicios configurados.
    Systemd activa todas las unidades que tienen como despendencias default.target que tiene vinculos con multi-user.target o graphical-user.target según estén configurados systemd
    Se puede ver el arbol de dependencias de default.target con :

    $ systemctl  list-dependencies  default.target

    Unidades

    Systemd provee un sistema de dependencias entre varias entidades llamadas unidades.
    Las unidades encapsulan distintos objetos relevantes para el arranque y mantenimiento del sistema.
    La mayoría de estas unidades son configuradas en sus propios archivos de configuración. Sin embargo algunos se crean automáticamente a partir de otra configuración, o dinámicamente respondiendo a un estado del sistema, o programándolo durante la ejecución de otra unidad.
    Un archivo de configuración de unidad codifica información acerca de cualquiera de las distintas unidades disponibles.
    La sintaxis y opciones generales se encuentran en systemd.unit
    Opciones adicionales o especificas se encuentran indicadas en las referencias puntuales de cada unidad
    Las unidades pueden adquirir diferentes estados
    Active Que puede significar iniciada ,con destino, o conectada , dependiendo del tipo de unidad
    Inactive que puede significar detenida, sin destino o desconectada , dependiendo del tipo de unidad
    También una unidad puede adquirir un estado intermedio entre dos procesos a la espera de ser activada o desactivada , estos estados son llamados ,
    Activating y deactivating , respectivamente
    Un estado especial llamado failed esta disponible similar a inactive y se produce cuando el servicio ha fallado de algún modo ( el servicio envió un código de error, colapsó, o expiró el tiempo de espera )
    Si una unidad entra en este estado se guardara un registro para posterior consulta .
    Hay que tener en cuenta que diferentes unidades pueden adquirir distintos sub-estados adicionales a los cinco mencionados mas arriba .
    Existen doce tipos diferentes de unidades:

    • Service: Una unidad .service Controla demonios y los procesos relativos a ellos .
    • Socket: Codifica información respecto a un IPC network socket(inter-process communication socket), o un FIFO file system socket, controlado y supervisado por systemd, para una activación basada en sockets
      cada unidad .socket tiene su unidad .service correspondiente , y establece un canal de comunicación a pedido del cliente.
    • Target: Las unidades .target codifican información respecto a las unidades target del sistema ,que son utilizadas para agrupar unidades y lograr una buena sincronización entre ellas en el momento del arranque sirven exlusivamente para agrupar unidades via dependencias, establecer y sincronizar nombres que permitan relacionarlas entre si.
    • Device: Las unidades .device codifican informacion respecto a un dispostitivo incluido en sysfs/udev .
    • Mount: Las unidades .mount codifican información respecto a un punto de montaje controlado y supervisado por systemd.Permite montar o desmontar un sistema de archivos
    • Automount: las unidades .automount encapsulan las funcionalidades de automontaje de un sistema de archivos .cada unidad automount figura en una unidad .mount cuando un pedido de acceso ocurre esta unidad monta el sistema de archivos y da acceso .
    • Snapshot: Las unidades .Snapshot hacen referencia a una instantánea dinámica del estado de ejecución systemd. Son útiles para hacer retroceder a un estado definido después de iniciar/detener temporalmente servicios o similares.
    • Timer: Las unidades .timer codifican la información acerca de un temporizador, controlado y supervisado por systemd, para la activación basada en temporizador.
    • Swap: Las unidades .swap codifican la información acerca de un dispositivo móvil o el archivo de paginación de memoria controlada y supervisada por systemd.
    • Path: Las unidades .path codifican la información sobre la ruta supervisada por systemd, para la activación basada en rutas.
    • Slice: Las unidades ,silice gestionan los procesos ( Scope y unit), los que pueden ser asignados a un sector específico. Con la posibilidad de configurarse ciertos limites a los recursos que se aplican a todos los procesos de todas las unidades que figuran en ese sector.
    • Scope: Las unidades .scope gestionan un conjunto de procesos del sistema. A diferencia de las unidades service , las unidades scope gestionan procesos creados externamente, y no hacen una bifurcación de dichos procesos.

    Referencias


    Instalación de Systemd en Debian Wheezy

    Antes de explicar como hacer la instalación de systemd en Debian Wheezy debemos aclarar que el mismo fue incluido como una muestra de tecnología. Por lo tanto para su instalación, utilizaremos la versión de Systemd del repositorio de wheezy-backports la cual se asemeja a la de testing.

    Advertencia: Debido a que a la fecha Debian mantiene a systemd en una etapa de pruebas ya que todabia no ha sido incorporado como reemplazo de sysvinit. Se advierte que la instalación del mismo podría causar problemas de estabilidad del sistema, por lo que su instalación que da bajo la estricta responsabilidad del usuario.

    Agregar el repositorio de backports para debian wheezy

    # echo  deb http://ftp.de.debian.org/debian wheezy-backports main > /etc/apt/sources.list.d/wheezy-backports.list

    Nota: Antes de instalar el repositorio verifique de no tiene agregado wheezy-backports en su sources.list
    Nota: La ubicación del repositorio es un ejemplo, pero cada uno puede poner el repositorio que este mas serca de su pais o en el que confien más. Para mas información consulte la seccion: Introducción a los repositorios de Debian

    Instalación de systemd

    # apt-get update
    # apt-get -t wheezy-backports install systemd systemd-sysv

    Nota: Al instalar systemd-sysv nos pedirá eliminar sysvinit

    Recomendación: Antes de instalar systemd-sysv es aconsejable hacer una copia del archivo /sbin/init en caso que posteriormente se necesite iniciar el sistema con sysvint

    # cp -av /sbin/init /sbin/init.sysvinit

    Advertencia: Al instalar systemd-sysv se pierde la oportunidad de poder probar systemd sin tener que eliminar sysvinit como se explica en Prueba de systemd sin instalación systemd-sysv


    Instalación de systemd en Debian Jessie/sid

    Advertencia: Debido a que a la fecha Debian mantiene a systemd en una etapa de pruebas ya que todabia no ha sido incorporado como reemplazo de sysvinit. Se advierte que la instalación del mismo podría causar problemas de estabilidad del sistema, por lo que su instalación que da bajo la estricta responsabilidad del usuario.

    # apt-get update
    # apt-get  install systemd systemd-sysv

    Nota: Al instalar systemd-sysv nos pedirá eliminar sysvinit-core

    Recomendación: antes de instalar systemd-sysv es aconsejable hacer una copia del archivo /sbin/init en caso que posteriormente se necesite iniciar el sistema con sysvint

    # cp -av /sbin/init /sbin/init.sysvinit

    Advertencia: Al instalar systemd-sysv se pierde la oportunidad de poder probar systemd sin tener que eliminar sysvinit-core como se explica en “Prueba de systemd sin instalación systemd-sysv”


    Configuración de Systemd a modo de prueba

    Es posible probar Systemd sin necesidad de instalar el paquete systemd-sysv (quien se encarga de la configuración necesaria para que Systemd se inicie de forma persistente), indicando como parámetro de arranque del kernel a:

    init=/bin/systemd

    Configurar el Inicio con Systemd editando GRUB al iniciar el sistema (método temporal)

    Estos parámetros pueden introducirse temporalmente durante el inicio del sistema editando el menú de GRUB.

    Procedimiento:

    Al desplegarse la ventana de opciones de GRUB durante el booteo, se debe presionar la letra "e", esto mostrara una nueva ventana que permite pasar opciones (en forma no persistente) a la configuración de GRUB.

    Dicha ventana mostrara (entre otras cosas) una entrada similar a la siguiente :

    ...
    linux /vmlinuz-3.13-1-686-pae root=/dev/mapper/root-root ro quiet
    ...

    En la cual se deberá agregar los parámetros necesarios para que systemd inicie en el arranque del kernel (init=/bin/systemd), quedando de forma similar a:

    ...
    linux /vmlinuz-3.13-1-686-pae root=/dev/mapper/root-root init=/bin/systemd ro quiet
    ...

    Configurar el Inicio con Sysvinit editando GRUB al iniciar el sistema (método temporal)

    En este caso ya se tendría instalado y configurado el manejador de sistema y gestor de servicios para Linux Systemd para que se inicie en forma permanente y se quiere introducir los parámetros para el arranque del kernel con Sysvinit, introduciéndolos temporalmente durante el inicio del sistema al editar el menú de GRUB.

    Cabe aclarar que para realizar este procedimiento, previo a la instalación del paquete systemd-sysv se debe realizar la copia de /sbin/init ya que de lo contrario, el mismo no se podría llevar a cabo

    # cp -av /sbin/init /sbin/init.sysvinit

    Procedimiento:

    Al desplegarse la ventana de opciones de GRUB durante el booteo, se debe presionar la letra "e", esto mostrara una nueva ventana que permite pasar opciones (en forma no persistente) a la configuración de GRUB.

    Dicha ventana mostrara (entre otras cosas) una entrada similar a la siguiente :

    ...
    linux /vmlinuz-3.13-1-686-pae root=/dev/mapper/root-root ro quiet
    ...

    En la cual se deberá agregar los parámetros necesarios para que systemd inicie en el arranque del kernel (init=/sbin/init.sysvinit ), quedando de forma similar a:

    ...
    linux /vmlinuz-3.13-1-686-pae root=/dev/mapper/root-root init=/sbin/init.sysvinit  ro quiet
    ...

    Configurar el Inicio con Systemd editando /etc/default/grub (método permanente)

    Procedimiento:

    1 Desde un emulador de terminal instalar el paquete systemd

    # apt-get install systemd

    2 Editar el archivo grub que se encuentra en /etc/default

    # nano  /etc/default/grub

    3 Buscar el texto

    ….
    GRUB_CMDLINE_LINUX_DEFAULT="quiet "
    ….

    4 Agregar el texto

    ...
    GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/bin/systemd"
    ...

    5 Actualizar GRUB

    # update-grub2

    Journal el sistema de registro de systemd

    Introducción

    Journal es el sistema de registro de systemd , implementado en la unidad systemd-journal.service.


    configuración

    El archivo de configuración de systemd-journal.service ,se encuentra en /etc/systemd/journald.conf .
    este archivo contiene las distintas opciones para configurar entre otras cosas ,el modo, tipo y tamaño de los log de registro.

    Dentro de este archivo, "Storage " configura donde y como se guardaran los datos de registro , opciones como "volatile","persistent","auto", y"none". indican los posibles modos :

    • storage= volatile : Los datos de journal serán almacenados en memoria de forma volátil en /run/log/journal .
    • storage=persistent: Los datos serán almacenado preferentemente en el disco en /var/log/journal/ .(que se creara si hace falta)
    • storage=auto: Esta opción es similar a "persistent" pero el directorio /var/log/journal / no sera creado en forma automática .

    Por defecto "storage=auto" por lo tanto para lograr tener un registro persistente de los log es necesario crear el archivo en /var/log/journal/ previamente.

    # mkdir  /var/log/journal

    Existen múltiples opciones de configuración

    Mas información:


    Los target

    En systemd los distintos niveles de ejecucion estan asociados y definidos en unas unidades que permiten agrupar los niveles de dependencia de los servicios relacionándolos entre si durante el arranque o bajo demanda .Por ejemplo apagar, iniciar ,reiniciar , Mono-usuario, Multi-usuario ,multiusuario modo gráfico.
    Cada unidad iniciara los servicios asociados en ese nivel de ejecucion .
    Systemd engloba esto en los .target, existen distintos target con un nombre propio y que engloban objetivos similares .(ver
    systemd.special)
    Estos objetivos implican el inicio de los procesos y servicios necesarios para esa etapa en particular .
    Las asociaciones de servicios a sus correspondientes .target se definen en las [Unit] unidades.

    Ejemplo de configuracion de una unidad :

    [Unit]
    Description=Graphical Interface
    Requires=multi-user.target
    After=multi-user.target
    Conflicts=rescue.target
    AllowIsolate=yes

    [Install]
    Alias=default.target

    Un target pueden heredar los procesos del anterior y sumarle los propios
    Por ejemplo si listamos el árbol de dependencias de default.target

    #  systemctl  list-dependencies  default.target

    Nos mostrara:

    systemctl  list-dependencies  default.target
    default.target
    ├─autofs.service
    ├─bootlogs.service
    ├─cpufrequtils.service
    ├─cron.service
    ├─decnet.service
    ├─display-manager.service─smartmontools.service
    .......................................................................
    ...................................................................
    ├─systemd-update-utmp-runlevel.service
    ├─tor.service
    └─multi-user.target
      ├─anacron.service
      ├─atd.service
      ├─autofs.service
      ├─avahi-daemon.service
    ........................................................
    ...................................................................

    Como vemos multi-user.target heredo los objetivos de default.target y añadió los suyos
    Podemos listar todos los tipos de target disponibles con :

    $ systemctl list-units --type=target --all

    Que mostrara algo similar a:

    UNIT                     LOAD   ACTIVE   SUB    DESCRIPTION
    basic.target             loaded active   active Basic System
    cryptsetup.target        loaded active   active Encrypted Volumes
    emergency.target         loaded inactive dead   Emergency Mode
    final.target             loaded inactive dead   Final Step
    getty.target             loaded active   active Login Prompts
    graphical.target         loaded active   active Graphical Interface
    local-fs-pre.target      loaded active   active Local File Systems (Pre)
    local-fs.target          loaded active   active Local File Systems
    multi-user.target        loaded active   active Multi-User System
    network.target           loaded active   active Network
    ..................................................................................
    ................................................................................

    Tambien podemos ver los target actualmente en uso :

    $ systemctl list-units --type=target

    Existen target que imitan los runlevels usados en sysvinit .El siguiente listado muestra una relación aproximada con los mismos:

    • 0 runlevel0.target, poweroff.target ----------------------------------------Cierra y apaga
    • 1, s, single runlevel1.target, rescue.target---------------------------Modo mono usuario
    • 2, 4 runlevel2.target, runlevel4.target, multi-user.target------Similar al 3
    • 3 runlevel3.target, multi-user.target-------------------------------------- Multiusuario sin entorno grafico
    • 5 runlevel5.target, graphical.target----------------------------------------Todos los servicios del nivel 3 Mas entorno gráfico
    • 6 runlevel6.target, reboot.target--------------------------------------------Reinicio del sistema
    • emergency emergency.target----------------------------------------------Shell de emergencia

    Para cambiar el target en uso se utiliza el comando :

    # systemctl isolate  multi.user.target

    Esto cambia a multiusuario en la actual sesión, en el siguiente reinicio el sistema volverá al target configurado por defecto .
    Es posible cambiar el target durante el inicio pasando parámetros al kernel mediante comandos en grub por ejemplo:

    systemd.unit=multi-user.target   (equivalente a un runlevel 3)
    systemd.unit=rescue.target         (equivalente a un runlevel 1)

    Se pueden visualizar las dependencias de cada target con :

    systemctl  show -p " wants" graphical.target

    Donde " wants" puede ser sustituido por "ReqieredBy",Requires","WantedBy" "Conflists","ConflictedBy","Before","After"

    mas información :


    Comandos Básicos


    Herramientas de análisis y control

    Systemd-analyze

    Es la herramienta de systemd que permite analizar el proceso de arranque del sistema y medir los tiempos de carga

    systemd-analyze

    Mostrara en forma sencilla el tiempo empleado durante la carga del sistema ,dividido entre kernel y espacio de usuario.
    Ejemplo :

    Startup finished in 4.110s (kernel) + 32.181s (userspace) = 36.291s

    Podemos obtener un listado mas detallado de todo el proceso en orden decreciente de tiempo empleado

    systemd-analyze   blame

    Lo que mostrara :

    systemd-analyze blame
             13.832s networking.service
              6.268s kerneloops.service
              6.102s avahi-daemon.service
              6.100s systemd-logind.service
              6.088s exim4.service
              5.496s systemd-fsck-root.service
              4.106s autofs.service
              3.859s rsyslog.service
              3.749s loadcpufreq.service
              3.735s tor.service
             .................
             ........................

    Se puede hacer un análisis mas específico sobre una unidad , obteniendo los tiempos parciales de los procesos previos que demoran su inicio.

    systemd-analyze critical-chain  bla.service

    Tambien podemos obtener una representacion gráfica de todo el proceso

    systemd-analyze  plot >grafico.svg

    Crea y guarda un grafico en formato .svg en el directorio de usuario .


    systemd-cgls

    En los sistemas linux la cantidad de procesos que se ejecutan en forma predeterminada es sustancial.
    Saber que proceso hace que cosa y a su vez cuando generan supbrocesos ( procesos hijos ) puede ser complicado .
    Systemd pone cada proceso generado en un grupo de control cgroup con el nombre del servicio que lo genero .
    Los grupo de control en su mas básica expresión simplemente son grupos de procesos que se pueden organizar en una jerarquía y etiquetar individualmente.
    Cuando un proceso genera otros procesos, estos procesos hijos se hacen miembro automáticamente del grupo del proceso padre.
    Entonces cgroup puede ser utilizado en forma efectiva para etiquetar procesos generados luego que el proceso principal sea lanzado.asegurando de que queden dentro del mismo grupo de control aunque estos procesos hijos generen a su vez subprocesos en forma ramificada Y además es una forma segura de matar el proceso padre y toda la cadena de supbrocesos derivados sin que escape alguno .
    Systemd provee una herramienta para mostrar los grupos de control en un arbol jerárquico .

    $ systemd-cgls

    Lo que mostrará ( en el ejemplo en forma acotada ) algo similar a :

    systemd-cgls
    ├─user
    │ └─1000.user
    │   └─1.session
    │     ├─  726 /bin/login --   
    │     ├─ 1153 -bash
    │     ├─ 1303 /bin/sh /usr/bin/startx
    │     ├─ 1320 xinit /home/ale/.xinitrc -- /etc/X11/xinit/xserverrc :0 -auth /tmp/serverauth.qdRjY
    │     ├─ 1321 /usr/bin/X -nolisten tcp :0 -auth /tmp/serverauth.qdRjYJ71z2
    │     ├─ 1327 /usr/bin/fluxbox
    │     ├─ 1338 conky
    ...........................................
    ........................................│     └─22614 /usr/bin/kglobalaccel
    └─system
      ├─1 /sbin/init
      ├─anacron.service
      │ ├─5836 /usr/sbin/anacron -dsq
      │ ├─9135 /bin/sh -c run-parts --report /etc/cron.daily
      │ ├─9136 run-parts --report /etc/cron.daily
      │ ├─9└─systemd-journald.service
        └─130 /lib/systemd/systemd-journald
    ...skipping...     ├─ 1338 conky140 /bin/sh /etc/cron.daily/apt
    .............................................................
    ..............................................................
    └─1322 /usr/sbin/acpid
      ├─cron.service
      │ ├─1120 /usr/sbin/cron
      │ ├─1126 /USR/SBIN/CRON
      │ ├─1131 /bin/sh -c DISPLAY=":0" /home/ale/scripts/noip
      │ ├─1136 /bin/bash /home/ale/scripts/noip
      │ ├─1142 noip2
      │ └─3904 dwb http://www.no-ip.com/hostactive.php?host=bla&domain=myftp.org
    ..............................................

    Vemos los procesos mostrados mediantes su cgroup, las etiquetas puestas luego del servicio y los subprocesos generados .
    De este modo estando cada proceso identificado junto a sus procesos hijos se puede matar el conjunto en su totalidad, por ejemplo:

    #  systemctl  kill bla.service

    Esto asegura que se envie una señal SIGTERM al conjunto englobado en el cgroup bla.service. ( es posible enviar otras señales,ejemplo:SIGKILL)
    La diferencia respecto al modo habitual para detener un servicio

    systemctl  stop  bla.service

    Es que systemd kill envia directamente una señal a cada miembro del cgroup ;systemcl stop opera mediante el archivo de configuración de cada servicio y depende de que el demonio responda adecuadamente systemd kill resuelve drásticamente el asunto en el caso de no poder hacerlo de este modo.

    Mas información en
    http://0pointer.de/blog/projects/systemd-for-admins-2.html


    Systemctl

    Es la herramienta principal de systemd que permite verificar y controlar el estado de sus unidades de servicio

    $ systemctl  

    Pasado sin argumentos mostrará un listado de todos los servicios en uso ( activos o no ) y su estado .

    $ systemctl list-units

    Listará las unidades instaladas.
    Las unidades disponibles se encuentran en /lib/systemd/system/ y en /etc/systemd/system/ , las unidades de este ultimo directorio tienen prioridad respecto al anterior.
    Se pude obtener un listado de todas las unidades disponibles con :

    $ systemctl list-unit-files

    Listar por tipo de unidad

    $ systemctl  list-units --type=service

    Listara todas las unidades .service
    O pasandole argumentos especificos:

    $ systemctl --failed

    Listará las unidades que presentan alguna falla.


    Journalctl

    Journal permite indicar distintas opciones a la hora de visualizar el contenido, pudiendo ser filtrado por tamaño, antigüedad o por campos mucho más específicos y puntales

    Algunos comandos :

    journalctl

    Mostrara la totalidad del log guardado desde el más antiguo hacia adelante

    journalctl -f

    Mostrara las ultimas entradas quedando en espera para mostrar las siguientes que se vayan agregando

    journalctl -n5

    Mostrara 5 lineas

    journalctl -f -n

    Mostrara n lineas y quedara a la espera de las siguientes entradas

    journalctl -b

    Mostrara las entradas correspondiente al booteo actual

    journalctl -b -p err

    Es posible filtrar aun mas los datos mostrando solamente en los campos con errores

    journactl --since=yesterday

    Mostrara todo el registro desde ayer a partir de 00.00 hs.(o se puede indicar a partir de una hora:minuto ,especificos)

    journalctl --since=2014-05-01 --until=2014-05-02

    Mostrara el registro entre las fechas acotadas (por defecto desde 00:00 hs, o acotar hora:minuto )

    Más información:


    Manejo de las unidades de servicio

    Las unidades de servicio pueden ser iniciadas, detenidas ,reiniciadas, en el momento y/o ,habilitadas al inicio o deshabilitadas al inicio .

    # systemctl  start/stop/restart  bla.service

    Iniciará/detendrá/reiniciará bla.service

    # systemctl status  bla.service

    Mostrará el estado de bla.service

    systemctl  is-enabled  bla.service

    Mostrara si la unidad bla.service esta habilitada o no.


    Habilitar o deshabilitar servicios en forma permanente durante el arranque del sistema .

    # systemctl enable/disable  bla.service

    Habilitará/deshabilitará la carga de bla.service al inicio del sistema .

    # systemd  start  bla.service
    # systemd  enable bla.service

    Iniciará bla.service inmediatamente y lo habilitará para que cargue en el siquiente arranque del sistema en forma permanente .

    # systemctl daemon.reload

    Reiniciará systemd verificando nuevas configuraciones, unidades o unidades modificadas


    Detener, apagar, reiniciar, suspender, hibernar

    # systemctl halt

    Cerrará y detendrá el sistema

    # systemctl poweroff

    Cerrará ,detendrá y apagará el sistema

    # systemctl reboot

    Reiniciará el sistema

    # systemctl suspend

    Suspender

    # systemctl hibernate

    Hibernar


    Trucos y consejos

    Investigar un error con systemctl y journalctl

    Las opciones disponibles son amplias ,systemctl puede ser utilizada no solo para controlar el estado de un servicio si no además investigar el origen de un error.
    Ejemplo:
    Listar las unidades que presentan falla:

    $ systemctl --failed

    Resultado :

    UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
    systemd-modules-load.service loaded failed failed Load Kernel Modules

    LOAD   = Reflects whether the unit definition was properly loaded.
    ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
    SUB    = The low-level unit activation state, values depend on unit type.

    1 loaded units listed. Pass --all to see loaded but inactive units, too.
    To show all installed unit files use 'systemctl list-unit-files'.

    Comprobamos el estado del servicio que presenta error.

    $ systemctl  status systemd-modules-load.service

    Resultado:

    systemd-modules-load.service - Load Kernel Modules
       Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
       Active: failed (Result: exit-code) since mar 2002-01-01 09:48:10 ART; 12 years 3 months ago
         Docs: man:systemd-modules-load.service(8)
               man:modules-load.d(5)
      Process: 247 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)

    Obtenemos el numero de proceso (PID) lo que permite investigar un poco mas respecto al error .Ahora utilizamos la herramientas de registro journalctl

    journalctl  _PID=247

    Resultado:

    -- Logs begin at mar 2002-01-01 09:48:07 ART, end at vie 2014-05-02 17:20:43 ART. --
    ene 01 09:48:10 pcale systemd-modules-load[247]: Failed to insert 'w83627ehf': Device or resource busy

    Ahora hemos acotado mas el origen del error , falla al cargar un modulo, asi que :

    $ ls -Al /etc/modules-load.d/

    Resultado:

    total 4
    -rw-r--r-- 1 root root 119 feb 25 08:29 cups-filters.conf
    lrwxrwxrwx 1 root root  10 abr 27 08:41 modules.conf -> ../modules

    Y:

    $ cat /etc/modules-load.d/modules.conf

    Lo que muestra :

    # Generated by sensors-detect on Thu Apr  1 19:47:25 2010
    # Chip drivers
    coretemp
    w83627ehf

    Tenemos el modulo que causa el error .

    Mas información


    Diagnosticar problemas de arranque

    A veces Systemd tarda un tiempo muy largo, o parece colgarse en el arranque o en el reinicio/apagado. Como Systemd espera un tiempo para iniciar cada servicio antes de tratar de acabar con él, es necesario investigar cual es el servicio que esta causando el problema

    1. El primer método seria quitar "quiet" de la línea de comandos del núcleo (los llamados "cmdline" o "línea de grub")
    2. Procedimiento:

      # nano /etc/default/grub

      Buscar el texto:

      ….
      GRUB_CMDLINE_LINUX_DEFAULT="quiet "
      ….

      Quitar el texto quiet

      ...
      GRUB_CMDLINE_LINUX_DEFAULT=""
      ...

      Actualizar GRUB

      # update-grub2


    3. El segundo método consiste en aumentar el nivel de detalle través cmdline: Añadiendo "systemd.log_target = kmsg systemd.log_level = debug" a '/etc/default/grub'
    4. Procedimiento:

      # nano /etc/default/grub

      Buscar el texto:

      ….
      GRUB_CMDLINE_LINUX_DEFAULT="quiet "
      ….

      Agregar el texto

      ...
      GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug"
      ...

      Tambien se puede agreagar “systemd.sysv_console=1” (0: disabled, 1: enabled) y “log_buf_len=1M”

      ...
      GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug systemd.sysv_console=1 log_buf_len=1M"
      ...

      Actualizar GRUB

      # update-grub2


    5. El tercer método consiste en Incrementar el nivel de detalle a través del archivo de configuración system.conf
    6. Procedimiento:

      # nano  /etc/systemd/system.conf

      Agregar el texto

      LogLevel=debug
      LogTarget=syslog-or-kmsg
      SysVConsole=yes

    Más información:


    Journal permitir acceso a un usuario del sistema

    Por defecto journal guarda los registros en /var/log/journal/ , el acceso y lectura de dicho directorio es asignado al grupo systemd-journal creado por defecto.
    Si se quiere dar acceso a un usuario sin privilegios de root a dichos registros, hay que agregarlo al grupo systemd-journal .
    Se crea el directorio de registro :

    # mkdir  /var/log/journal

    Se agrega el usuario usuario al grupo systemd-journal

    # usermod  -a -G  systemd-journal   usuario

    Es posible dar acceso a estos registros a usuarios y grupos ver ( http://man7.org/linux/man-pages/man8/systemd-journald.8.html )


    Journal limitar su tamaño

    Si se ha agregado el directorio /var/log/journal haciendo que la información de los log de systemd se mantengan en forma permanente, puede que sea conveniente determinar el tamaño máximo en MB de dichos archivos para que no terminen ocupando un espacio desproporcionado en la partición /var editando el archivo /etc/systemd/journald.conf y estableciendo un límite de 50 o 100 MB. Cabe aclarar que estos valores son meramente ejemplificativos.

    # nano '/etc/systemd/journald.conf'

    y agregar el texto

    SystemMaxUse=100M

    Scripts al inicio

    Para conseguir que un script sea cargado al inicio ( o en alguna otra instancia ) se debe crear una unidad de servicio .service
    Un archivo de texto con las configuraciones y directivas en /etc/systemd/system/.
    Por ejemplo :

    # nano /etc/systemd/system/miservicio.service

    El contenido básico de dicho archivo puede ser similar a :

    [Unit]
    Description=Mi script

    [Service]
    ExecStart=/ruta/completa/miscript

    [Install]
    WantedBy=multi-user.target

    Esta configuración es un ejemplo, cada sección en este archivo [Unit] ; [Service] ; [Install], tienen multiples opciones según el comportamiento requerido para la unidad y el servicio
    De este modo y en el ejemplo se asume que el servicio sera habilitado en el target multi-user .
    Si lo que se quiere lanzar al inicio es un shell script ,como miscript es necesario que el encabezado del mismo incluya el shebang , ejemplo:

    #!/bin/bash 
    ...................
    ..................

    Arrancar Debian con Num Lock activada en las TTYs

    Creamos el servicio numlock.service:

    # editor /etc/systemd/system/numlock.service

    Su contenido es:

    [Unit]
    Description=Activar el teclado numérico en las TTYs

    [Service]
    ExecStart=/bin/bash -c 'for tty in /dev/tty{1..6}; do /usr/bin/setleds -D +num < \"$tty\"; done'

    [Install]
    WantedBy=multi-user.target

    Lo configuramos en el arranque:

    systemctl enable numlock.service

    Más información:


    Fuentes y referencias

PabliNet: Comentario añadido
marcelunix: Comentario actualizado
  • ¿Qué estás haciendo?

    Enviado por marcelunix el 22 Noviembre, 2014 - 20:45.

    boxing con la forma de conectarme a un UNIX sco con telnet desde Debian Wheezy.
    Ya, dicho así parecería cata3
    Para resumir: No obtengo el resultado que quiero. smash
    Estoy intentando aprender contrato GNU/screen

    https://www.gnu.org/software/screen/

    Y haciendo diferentes pruebas.
    Tengo muchas dudas y estoy preparando una especie de bitácora para abrir un hilo y explicar lo que necesito y lo que obtengo.
    Ya os anticipo que

    http://www.eslinux.com/foro/3083/terminal-sco-linux

    no me ha funcionado todo lo bien que deseo. cry
    ¡Hasta pronto!

marcelunix: Comentario añadido
  • ¿Qué estás haciendo?

    Enviado por marcelunix el 22 Noviembre, 2014 - 20:45.

    boxing con la forma de conectarme a un UNIX sco con telnet desde Debian Wheezy.
    Ya, dicho así parecería cata3
    Para resumir: No obtengo el resultado que quiero. smash
    Estoy intentando aprender contrato GNU/screen

    https://www.gnu.org/software/screen/

    Y haciendo diferentes pruebas.
    Tengo muchas dudas y estoy preparando una especie de bitácora para abrir un hilo y explicar lo que necesito y lo que obtengo.
    Ya os anticipo que

    http://www.eslinux.com/foro/3083/terminal-sco-linux

    no me ha funcionado todo lo bien que deseo. cry
    ¡Hasta pronto!

alexpolifacetico: Comentario añadido
rockyiii: Comentario añadido
PabliNet: Comentario añadido
  • ¿Qué estás haciendo?

    Enviado por PabliNet el 21 Noviembre, 2014 - 17:33.

    Estoy con un problema que lo veo muy incoherente. Tengo instalado Debian y lo quiero reinstalar, pero no me deja porque me pide módulos y no me detecta el disco rígido donde tengo instalado Debian...
    Quiero aclarar que la última que instalé Debian tenía otra placa madre y otro micro.

jesusguevarautomotriz: Comentario añadido
rockyiii: Comentario actualizado
  • ¿Qué estás haciendo?

    Enviado por rockyiii el 21 Noviembre, 2014 - 15:46.

    muchas veces el sentido de una frase se interpreta en un su contexto, yo creo que en este caso la expresión "ojala que te pise un autobús" o "cuidate que te puede pisar un autobús" etc etc se puede interpretar como una amenaza de muerte.y la amenaza se torna personal, por mas que no este formulada a un individuo en concreto, cuando esta dirigido a un colectivo determinado de personas, como en este caso el comité técnico de Debian
    lo cierto es que amenazas de muerte o no, u presiones externas, fueron lo suficientemente fuertes para asustar a Tollef Fog Heen y causar, en forma directa, la decisión de retirarse del proyecto o del tc.

    en fin...

rockyiii: Comentario actualizado
  • ¿Qué estás haciendo?

    Enviado por rockyiii el 21 Noviembre, 2014 - 15:46.

    muchas veces el sentido de una frase se interpreta en un su contexto, yo creo que en este caso la expresión "ojala que te pise un autobús" o "cuidate que te puede pisar un autobús" etc etc se puede interpretar como una amenaza de muerte.y la amenaza se torna personal, por mas que no este formulada a un individuo en concreto, cuando esta dirigido a un colectivo determinado de personas, como en este caso el comité técnico de Debian
    lo cierto es que amenazas de muerte o no, u presiones externas, fueron lo suficientemente fuertes para asustar a Tollef Fog Heen y causar, en forma directa, la decisión de retirarse del proyecto o del tc.

    en fin...

rockyiii: Comentario actualizado
  • ¿Qué estás haciendo?

    Enviado por rockyiii el 21 Noviembre, 2014 - 15:46.

    muchas veces el sentido de una frase se interpreta en un su contexto, yo creo que en este caso la expresión "ojala que te pise un autobús" o "cuidate que te puede pisar un autobús" etc etc se puede interpretar como una amenaza de muerte.y la amenaza se torna personal, por mas que no este formulada a un individuo en concreto, cuando esta dirigido a un colectivo determinado de personas, como en este caso el comité técnico de Debian
    lo cierto es que amenazas de muerte o no, u presiones externas, fueron lo suficientemente fuertes para asustar a Tollef Fog Heen y causar, en forma directa, la decisión de retirarse del proyecto o del tc.

    en fin...

rockyiii: Comentario actualizado
  • ¿Qué estás haciendo?

    Enviado por rockyiii el 21 Noviembre, 2014 - 15:46.

    muchas veces el sentido de una frase se interpreta en un su contexto, yo creo que en este caso la expresión "ojala que te pise un autobús" o "cuidate que te puede pisar un autobús" etc etc se puede interpretar como una amenaza de muerte.y la amenaza se torna personal, por mas que no este formulada a un individuo en concreto, cuando esta dirigido a un colectivo determinado de personas, como en este caso el comité técnico de Debian
    lo cierto es que amenazas de muerte o no, u presiones externas, fueron lo suficientemente fuertes para asustar a Tollef Fog Heen y causar, en forma directa, la decisión de retirarse del proyecto o del tc.

    en fin...

rockyiii: Comentario actualizado
  • ¿Qué estás haciendo?

    Enviado por rockyiii el 21 Noviembre, 2014 - 15:46.

    muchas veces el sentido de una frase se interpreta en un su contexto, yo creo que en este caso la expresión "ojala que te pise un autobús" o "cuidate que te puede pisar un autobús" etc etc se puede interpretar como una amenaza de muerte.y la amenaza se torna personal, por mas que no este formulada a un individuo en concreto, cuando esta dirigido a un colectivo determinado de personas, como en este caso el comité técnico de Debian
    lo cierto es que amenazas de muerte o no, u presiones externas, fueron lo suficientemente fuertes para asustar a Tollef Fog Heen y causar, en forma directa, la decisión de retirarse del proyecto o del tc.

    en fin...

rockyiii: Comentario añadido
  • ¿Qué estás haciendo?

    Enviado por rockyiii el 21 Noviembre, 2014 - 15:46.

    muchas veces el sentido de una frase se interpreta en un su contexto, yo creo que en este caso la expresión "ojala que te pise un autobús" o "cuidate que te puede pisar un autobús" etc etc se puede interpretar como una amenaza de muerte.y la amenaza se torna personal, por mas que no este formulada a un individuo en concreto, cuando esta dirigido a un colectivo determinado de personas, como en este caso el comité técnico de Debian
    lo cierto es que amenazas de muerte o no, u presiones externas, fueron lo suficientemente fuertes para asustar a Tollef Fog Heen y causar, en forma directa, la decisión de retirarse del proyecto o del tc.

    en fin...

Julius-Caesar: Comentario añadido
  • ¿Qué estás haciendo?

    Enviado por Julius-Caesar el 21 Noviembre, 2014 - 14:43.

    rioport escribió:

    Mi pregunta fue porque no veo en donde Tollef dice que lo amenazaron y menos de muerte (¿en dplinux.net las bolas de cristal funcionan?). De hecho lo de las "amenazas" (no de muerte) tendría más sentido con estos últimos enlaces que has puesto (aunque no es tan especifico qué tipo de ataques) y no lo primero.

    Es que NO existen esas amenazas mientras no se demuestre lo contrario. A no ser que esto se interprete como una amenaza de muerte:

    Tollef Fog Heen:
    "There's a constant drum about this all being some sort of conspiracy and there are sometimes flares where people wish people involved in systemd would be run over by a bus or just accusations of incompetence."

    rioport escribió:

    ¿Dudo que el preguntar me convierte en anti-systemd? relájate.

    No te sorprendas, tras systemd solo hay politiqueo, nada más. Todo es un engaño bien perpetrado: Red Hat quiere el CONTROL y punto.

Panko: Comentario añadido
marcelunix: Comentario añadido