One place for hosting & domains

      para

      Cómo usar ps, kill y nice para administrar procesos en Linux


      Introducción


      Un servidor Linux, como cualquier otro equipo con el que pueda estar familiarizado, ejecuta aplicaciones. Para el equipo, estos se consideran “procesos”.

      Mientras que Linux se encargará de la administración de bajo nivel, entre bastidores, en el ciclo de vida de un proceso, se necesitará una forma de interactuar con el sistema operativo para administrarlo desde un nivel superior.

      En esta guía, explicaremos algunos aspectos sencillos de la administración de procesos. Linux proporciona una amplia colección de herramientas para este propósito.

      Exploraremos estas ideas en un VPS de Ubuntu 12.04, pero cualquier distribución moderna de Linux funcionará de manera similar.

      Cómo ver los procesos en ejecución en Linux


      top


      La forma más sencilla de averiguar qué procesos se están ejecutando en su servidor es ejecutar el comando top:

      top***
      
      top - 15:14:40 up 46 min,  1 user,  load average: 0.00, 0.01, 0.05 Tasks:  56 total,   1 running,  55 sleeping,   0 stopped,   0 zombie Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   1019600k total,   316576k used,   703024k free,     7652k buffers Swap:        0k total,        0k used,        0k free,   258976k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND               1 root      20   0 24188 2120 1300 S  0.0  0.2   0:00.56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/0            6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0            7 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 watchdog/0             8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset                 9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper               10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs
      

      La parte superior de la información ofrece estadísticas del sistema, como la carga del sistema y el número total de tareas.

      Se puede ver fácilmente que hay 1 proceso en ejecución y 55 procesos en reposo (es decir, inactivos/que no usan los recursos de la CPU).

      La parte inferior tiene los procesos en ejecución y las estadísticas de uso.

      htop


      Una versión mejorada de top, llamada htop, está disponible en los repositorios. Instálelo con este comando:

      sudo apt-get install htop
      

      Si ejecutamos el comando htop, veremos que hay una pantalla más fácil de usar:

      htop***
      
        Mem[|||||||||||           49/995MB]     Load average: 0.00 0.03 0.05   CPU[                          0.0%]     Tasks: 21, 3 thr; 1 running   Swp[                         0/0MB]     Uptime: 00:58:11   PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command  1259 root       20   0 25660  1880  1368 R  0.0  0.2  0:00.06 htop     1 root       20   0 24188  2120  1300 S  0.0  0.2  0:00.56 /sbin/init   311 root       20   0 17224   636   440 S  0.0  0.1  0:00.07 upstart-udev-brid   314 root       20   0 21592  1280   760 S  0.0  0.1  0:00.06 /sbin/udevd --dae   389 messagebu  20   0 23808   688   444 S  0.0  0.1  0:00.01 dbus-daemon --sys   407 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.02 rsyslogd -c5   408 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   409 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   406 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.04 rsyslogd -c5   553 root       20   0 15180   400   204 S  0.0  0.0  0:00.01 upstart-socket-br
      

      Puede aprender más sobre cómo usar top y htop aquí.

      Cómo usar ps para realizar una lista de procesos


      top y htop proporcionan una buena interfaz para ver los procesos en ejecución, similar a la de un administrador de tareas gráfico.

      Sin embargo, estas herramientas no siempre son lo suficientemente flexibles para cubrir adecuadamente todos los escenarios. Un poderoso comando llamado ps generalmente es la respuesta a estos problemas.

      Cuando se invoca sin argumentos, el resultado puede ser un poco escaso:

      ps***
      
        PID TTY          TIME CMD  1017 pts/0    00:00:00 bash  1262 pts/0    00:00:00 ps
      

      Este resultado muestra todos los procesos asociados con el usuario actual y la sesión de terminal. Eso tiene sentido porque, actualmente, solo estamos ejecutando bash y ps con este terminal.

      Para obtener un panorama más completo de los procesos en este sistema, podemos ejecutar lo siguiente:

      ps aux***
      
      USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND root         1  0.0  0.2  24188  2120 ?        Ss   14:28   0:00 /sbin/init root         2  0.0  0.0      0     0 ?        S    14:28   0:00 [kthreadd] root         3  0.0  0.0      0     0 ?        S    14:28   0:00 [ksoftirqd/0] root         6  0.0  0.0      0     0 ?        S    14:28   0:00 [migration/0] root         7  0.0  0.0      0     0 ?        S    14:28   0:00 [watchdog/0] root         8  0.0  0.0      0     0 ?        S<   14:28   0:00 [cpuset] root         9  0.0  0.0      0     0 ?        S<   14:28   0:00 [khelper] . . .
      

      Estas opciones ordenan a ps que muestre los procesos de propiedad de todos los usuarios (independientemente de su asociación con el terminal) en un formato fácil de usar.

      Para ver una vista de estructura jerárquica, en la que se ilustran las relaciones jerárquicas, podemos ejecutar el comando con las siguientes opciones:

      ps axjf***
      
       PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND     0     2     0     0 ?           -1 S        0   0:00 [kthreadd]     2     3     0     0 ?           -1 S        0   0:00  _ [ksoftirqd/0]     2     6     0     0 ?           -1 S        0   0:00  _ [migration/0]     2     7     0     0 ?           -1 S        0   0:00  _ [watchdog/0]     2     8     0     0 ?           -1 S<       0   0:00  _ [cpuset]     2     9     0     0 ?           -1 S<       0   0:00  _ [khelper]     2    10     0     0 ?           -1 S        0   0:00  _ [kdevtmpfs]     2    11     0     0 ?           -1 S<       0   0:00  _ [netns] . . .
      

      Como puede ver, el proceso kthreadd se muestra como proceso principal de kstadd/0 y los demás.

      Una nota sobre las ID de procesos


      En Linux y sistemas tipo Unix, a cada proceso se le asigna un ID de proceso o PID. Esta es la forma en que el sistema operativo identifica y realiza un seguimiento de los procesos.

      Una forma rápida de obtener el PID de un proceso es con el comando pgrep:

      pgrep bash***
      
      1017
      

      Esto simplemente consultará el ID del proceso y lo mostrará en el resultado.

      El primer proceso que se generó en el arranque, llamado init, recibe el PID “1”.

      pgrep init***
      
      1
      

      Entonces, este proceso es responsable de engendrar todos los demás procesos del sistema. Los procesos posteriores reciben números PID mayores.

      Un proceso principal es el proceso que se encargó de generarlo. Los procesos principales tienen un PPID, que puede ver en los encabezados de las columnas en muchas aplicaciones de administración de procesos, incluidos top, htop y ps.

      Cualquier comunicación entre el usuario y el sistema operativo sobre los procesos implica traducir entre los nombres de procesos y los PID en algún momento durante la operación. Este es el motivo por el que las utilidades le indican el PID.

      Las relaciones principal-secundario


      Para crear un proceso secundario se deben seguir dos pasos: fork(), que crea un nuevo espacio de direcciones y copia los recursos propiedad del principal mediante copy-on-write para que estén disponibles para el proceso secundario; y exec(), que carga un ejecutable en el espacio de direcciones y lo ejecuta.

      En caso de que un proceso secundario muera antes que su proceso principal, el proceso secundario se convierte en un zombi hasta que el principal haya recopilado información sobre él o haya indicado al núcleo que no necesita esa información. Luego, los recursos del proceso secundario se liberarán. Sin embargo, si el proceso principal muere antes que el secundario, init adoptará el secundario, aunque también puede reasignarse a otro proceso.

      Cómo enviar señales a los procesos en Linux


      Todos los procesos en Linux responden a señales. Las señales son una forma de decirle a los programas que terminen o modifiquen su comportamiento.

      Cómo enviar señales a los procesos por PID


      La forma más común de pasar señales a un programa es con el comando kill.

      Como es de esperar, la funcionalidad predeterminada de esta utilidad es intentar matar un proceso:

      kill PID_of_target_process

      Esto envía la señal TERM al proceso. La señal TERM indica al proceso debe terminar. Esto permite que el programa realice operaciones de limpieza y cierre sin problemas.

      Si el programa tiene un mal comportamiento y no se cierra cuando se le da la señal TERM, podemos escalar la señal pasando la señal KILL:

      kill -KILL PID_of_target_process

      Esta es una señal especial que no se envía al programa.

      En su lugar, se envía al núcleo del sistema operativo, que cierra el proceso. Eso se utiliza para eludir los programas que ignoran las señales que se les envían.

      Cada señal tiene un número asociado que puede pasar en vez del nombre. Por ejemplo, puede pasar “-15” en lugar de “-TERM” y “-9” en lugar de “-KILL”.

      Cómo usar señales para otros fines


      Las señales no solo se utilizan para cerrar programas. También pueden usarse para realizar otras acciones.

      Por ejemplo, muchos demonios se reinician cuando reciben la señal HUP o la señal de colgar. Apache es un programa que funciona así.

      sudo kill -HUP pid_of_apache

      El comando anterior hará que Apache vuelva a cargar su archivo de configuración y reanude sirviendo contenidos.

      Puede enumerar todas las señales que puede enviar con kill escribiendo lo siguiente:

      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 . . .
      

      Cómo enviar señales a los procesos por nombre


      Aunque la forma convencional de enviar señales es mediante el uso de PID, también hay métodos para hacerlo con nombres de procesos regulares.

      El comando pkill funciona casi exactamente igual que kill, pero funciona con un nombre de proceso en su lugar:

      pkill -9 ping
      

      El comando anterior es el equivalente a:

      kill -9 `pgrep ping`
      

      Si quiere enviar una señal a todas las instancias de un determinado proceso, puede utilizar el comando killall:

      killall firefox
      

      El comando anterior enviará la señal TERM a todas las instancias de firefox que se estén ejecutando en el equipo.

      Cómo ajustar las prioridades de los procesos


      A menudo, querrá ajustar qué procesos reciben prioridad en un entorno de servidor.

      Algunos procesos pueden considerarse como una misión crítica para su situación, mientras que otros pueden ejecutarse siempre que haya recursos sobrantes.

      Linux controla la prioridad a través de un valor llamado niceness.

      Las tareas de alta prioridad se consideran menos buenas porque no comparten los recursos tan bien. Por otro lado, los procesos de baja prioridad son buenos porque insisten en tomar solo los recursos mínimos.

      Cuando ejecutamos top al principio del artículo, había una columna marcada como “NI”. Este es el valor bueno del proceso:

      top***
      
      Tasks: 56 total, 1 running, 55 sleeping, 0 stopped, 0 zombie Cpu(s):  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   1019600k total,   324496k used,   695104k free,     8512k buffers Swap:        0k total,        0k used,        0k free,   264812k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            1635 root      20   0 17300 1200  920 R  0.3  0.1   0:00.01 top                    1 root      20   0 24188 2120 1300 S  0.0  0.2   0:00.56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.11 ksoftirqd/0
      

      Los valores buenos pueden oscilar entre “-19/-20” (máxima prioridad) y “19/20” (mínima prioridad) dependiendo del sistema.

      Para ejecutar un programa con un determinado valor bueno, podemos usar el comando nice:

      nice -n 15 command_to_execute

      Esto solo funciona cuando se inicia un nuevo programa.

      Para alterar el valor bueno de un programa que ya se está ejecutando, usamos una herramienta llamada renice:

      renice 0 PID_to_prioritize

      Nota: Mientras que nice funciona necesariamente con un nombre de comando, renice funciona invocando al PID del proceso

      Conclusión


      La administración de procesos es un tema que a veces resulta difícil de entender para los nuevos usuarios, debido a que las herramientas utilizadas son diferentes a sus contrapartes gráficas.

      Sin embargo, las ideas son familiares e intuitivas, y, con un poco de práctica, se convertirá en algo natural. Dado que los procesos interviene en todo lo que se hace con un sistema informático, aprender a controlarlos de forma eficaz es una habilidad esencial.

      Por Justin Ellingwood



      Source link

      Como usar o ps, kill e nice para gerenciar processos no Linux


      Introdução


      Um servidor Linux, assim como qualquer outro computador que você conheça, executa aplicativos. Para o computador, eles são considerados “processos”.

      Embora o Linux lide nos bastidores com o gerenciamento de baixo nível no ciclo de vida de um processo, você precisará de uma maneira de interagir com o sistema operacional para gerenciá-lo de um nível superior.

      Neste guia, vamos discutir alguns aspectos simples do gerenciamento de processos. O Linux oferece uma coleção abundante de ferramentas para esse propósito.

      Vamos explorar essas ideias em um VPS Ubuntu 12.04, mas qualquer distribuição moderna do Linux funcionará de maneira similar.

      Como visualizar processos em execução no Linux


      top


      A maneira mais fácil de descobrir quais processos estão sendo executados no seu servidor é executando o comando top:

      top***
      
      top - 15:14:40 up 46 min,  1 user,  load average: 0.00, 0.01, 0.05 Tasks:  56 total,   1 running,  55 sleeping,   0 stopped,   0 zombie Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   1019600k total,   316576k used,   703024k free,     7652k buffers Swap:        0k total,        0k used,        0k free,   258976k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND               1 root      20   0 24188 2120 1300 S  0.0  0.2   0:00.56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/0            6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0            7 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 watchdog/0             8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset                 9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper               10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs          
      

      A porção superior de informações mostra estatísticas do sistema, como a carga do sistema e o número total de tarefas.

      É possível ver facilmente que há 1 processo em execução e 55 processos estão suspensos (ou seja, ociosos/sem utilizar recursos da CPU).

      A parte inferior mostra os processos em execução e suas estatísticas de uso.

      htop


      Uma versão melhorada de top, chamada htop, está disponível nos repositórios. Instale-o com este comando:

      sudo apt-get install htop
      

      Se executarmos o comando htop, veremos que as informação são exibidas de uma maneira mais inteligível:

      htop***
      
        Mem[|||||||||||           49/995MB]     Load average: 0.00 0.03 0.05   CPU[                          0.0%]     Tasks: 21, 3 thr; 1 running   Swp[                         0/0MB]     Uptime: 00:58:11   PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command  1259 root       20   0 25660  1880  1368 R  0.0  0.2  0:00.06 htop     1 root       20   0 24188  2120  1300 S  0.0  0.2  0:00.56 /sbin/init   311 root       20   0 17224   636   440 S  0.0  0.1  0:00.07 upstart-udev-brid   314 root       20   0 21592  1280   760 S  0.0  0.1  0:00.06 /sbin/udevd --dae   389 messagebu  20   0 23808   688   444 S  0.0  0.1  0:00.01 dbus-daemon --sys   407 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.02 rsyslogd -c5   408 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   409 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   406 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.04 rsyslogd -c5   553 root       20   0 15180   400   204 S  0.0  0.0  0:00.01 upstart-socket-br
      

      Aprenda mais sobre como usar o top e htop aqui.

      Como usar o ps para listar processos


      Tanto o top quanto o htop fornecem uma interface agradável para visualizar processos em execução, de maneira semelhante a um gerenciador de tarefas gráfico.

      No entanto, essas ferramentas nem sempre são flexíveis o suficiente para abranger adequadamente todos os cenários. Um comando poderoso chamado ps é geralmente a resposta para esses problemas.

      Quando chamado sem argumentos, o resultado pode ser um pouco confuso:

      ps***
      
        PID TTY          TIME CMD  1017 pts/0    00:00:00 bash  1262 pts/0    00:00:00 ps
      

      Esse resultado mostra todos os processos associados ao usuário e sessão de terminal atuais. Isso faz sentido porque estamos executando apenas o bash e ps com esse terminal atualmente.

      Para conseguirmos uma visão mais completa dos processos neste sistema, podemos executar o seguinte:

      ps aux***
      
      USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND root         1  0.0  0.2  24188  2120 ?        Ss   14:28   0:00 /sbin/init root         2  0.0  0.0      0     0 ?        S    14:28   0:00 [kthreadd] root         3  0.0  0.0      0     0 ?        S    14:28   0:00 [ksoftirqd/0] root         6  0.0  0.0      0     0 ?        S    14:28   0:00 [migration/0] root         7  0.0  0.0      0     0 ?        S    14:28   0:00 [watchdog/0] root         8  0.0  0.0      0     0 ?        S<   14:28   0:00 [cpuset] root         9  0.0  0.0      0     0 ?        S<   14:28   0:00 [khelper] . . .
      

      Essas opções dizem ao ps para mostrar processos de propriedade de todos os usuários (independentemente da sua associação de terminais) em um formato facilmente inteligível.

      Para ver um modo de exibição em árvore, onde relações hierárquicas são mostradas, executamos o comando com essas opções:

      ps axjf***
      
       PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND     0     2     0     0 ?           -1 S        0   0:00 [kthreadd]     2     3     0     0 ?           -1 S        0   0:00  _ [ksoftirqd/0]     2     6     0     0 ?           -1 S        0   0:00  _ [migration/0]     2     7     0     0 ?           -1 S        0   0:00  _ [watchdog/0]     2     8     0     0 ?           -1 S<       0   0:00  _ [cpuset]     2     9     0     0 ?           -1 S<       0   0:00  _ [khelper]     2    10     0     0 ?           -1 S        0   0:00  _ [kdevtmpfs]     2    11     0     0 ?           -1 S<       0   0:00  _ [netns] . . .
      

      Como se vê, o processo kthreadd é mostrado como um pai do processo ksoftirqd/0 e de outros.

      Uma nota sobre IDs de processo


      No Linux e em sistemas do tipo Unix, cada processo é atribuído a um ID de processo, ou PID. É assim que o sistema operacional identifica e mantém o controle dos processos.

      Uma maneira rápida de obter o PID de um processo é com o comando pgrep:

      pgrep bash***
      
      1017
      

      Isso irá simplesmente consultar o ID do processo e retorná-lo.

      Ao primeiro processo gerado na inicialização do sistema, chamado init, é atribuído o PID de “1″.

      pgrep init***
      
      1
      

      Esse processo é então responsável por gerar todos os processos no sistema. Os processos posteriores recebem números PID maiores.

      O pai de um processo é o processo que foi responsável por gerá-lo. Os processos pais possuem um PPID, que pode ser visto no cabeçalho da coluna correspondente em muitos aplicativos de gerenciamento de processos, incluindo o top, htop e ps.

      Qualquer comunicação entre o usuário e o sistema operacional em relação aos processos envolve a tradução entre os nomes de processos e PIDs em algum ponto durante a operação. É por isso que os utilitários informam o PID.

      Relacionamentos pai/filho


      A criação de um processo filho acontece em dois passos: fork(), que cria espaços de endereço e copia os recursos de propriedade do pai via copia em gravação para que fique disponível ao processo filho; e exec(), que carrega um executável no espaço de endereço e o executa.

      Caso um processo filho morra antes do seu pai, o filho torna-se um zumbi até que o pai tenha coletado informações sobre ele ou indicado ao kernel que ele não precisa dessas informações. Os recursos do processo filho serão então libertados. No entanto, se o processo pai morrer antes do filho, o filho será adotado pelo init, embora também possa ser reatribuído a outro processo.

      Como enviar sinais de processos no Linux


      Todos os processos no Linux respondem a sinais. Os sinais são uma maneira ao nível de SO de dizer aos programas para terminarem ou modificarem seu comportamento.

      Como enviar sinais de processos por PID


      A maneira mais comum de passar sinais para um programa é com o comando kill.

      Como se espera, a funcionalidade padrão desse utilitário é tentar encerrar um processo:

      <pre>kill <span class=“highlight”>PIDoftarget_process</span></pre>

      Isso envia o sinal TERM ao processo. O sinal TERM pede ao processo para encerrar. Isso permite que o programa execute operações de limpeza e seja finalizado sem problemas.

      Se o programa estiver se comportando incorretamente e não se encerrar quando um sinal TERM for passado, podemos escalar o sinal passando o sinal KILL:

      <pre>kill -KILL <span class=“highlight”>PIDoftarget_process</span></pre>

      Esse é um sinal especial que não é enviado ao programa.

      Ao invés disso, ele é dado ao kernel do sistema operacional, que encerra o processo. Isso é usado para passar por cima de programas que ignoram os sinais que lhe são enviados.

      Cada sinal possui um número associado que pode ser passado ao invés de seu nome. Por exemplo, é possível passar “-15″ ao invés de ”-TERM” e ”-9″ ao invés de ”-KILL”.

      Como usar sinais para outros fins


      Os sinais não são usados apenas para encerrar programas. Eles também podem ser usados para realizar outras ações.

      Por exemplo, muitos daemons são reiniciados quando recebem o HUP, ou sinal de desligamento. O Apache é um programa que funciona dessa forma.

      <pre>sudo kill -HUP <span class=“highlight”>pidofapache</span></pre>

      O comando acima fará com que o Apache recarregue seu arquivo de configuração e retome o serviço de conteúdo.

      Liste todos os sinais que podem ser enviados com o kill digitando:

      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 . . .
      

      Como enviar sinais de processos pelo nome


      Embora a maneira convencional de enviar sinais seja através do uso de PIDs, também existem métodos para fazer isso com os nomes regulares dos processos.

      O comando pkill funciona de maneira bastante similar ao kill, com a diferença de operar com um nome de processo:

      pkill -9 ping
      

      O comando acima é equivalente a:

      kill -9 `pgrep ping`
      

      Se quiser enviar um sinal para todas as instâncias de um determinado processo, utilize o comando killall:

      killall firefox
      

      O comando acima enviará o sinal TERM para todas as instâncias do firefox em execução no computador.

      Como ajustar prioridades de processos


      Geralmente, é desejável ajustar quais processos recebem prioridade em um ambiente de servidor.

      Alguns processos podem ser considerados críticos para sua situação, enquanto outros podem ser executados sempre que houver recursos sobrando no sistema.

      O Linux controla a prioridade através de um valor chamado niceness (gentileza).

      As tarefas de alta prioridade são consideradas menos nice (gentis), porque não compartilham recursos tão bem. Por outro lado, os processos de baixa prioridade são nice, porque insistem em utilizar apenas a menor quantidade de recursos.

      Quando executamos o top no início do artigo, havia uma coluna marcada “NI”. Esse é o valor de gentileza do processo:

      top***
      
       Tasks:  56 total,   1 running,  55 sleeping,   0 stopped,   0 zombie Cpu(s):  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   1019600k total,   324496k used,   695104k free,     8512k buffers Swap:        0k total,        0k used,        0k free,   264812k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            1635 root      20   0 17300 1200  920 R  0.3  0.1   0:00.01 top                    1 root      20   0 24188 2120 1300 S  0.0  0.2   0:00.56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.11 ksoftirqd/0
      

      Os valores de gentileza podem variar entre “-19/-20” (prioridade mais alta) e ”19/20” (prioridade mais baixa), dependendo do sistema.

      Para executar um programa com um certo valor de gentileza, podemos usar o comando nice:

      <pre>nice -n 15 <span class=“highlight”>commandtoexecute</span></pre>

      Isso funciona apenas ao iniciar um novo programa.

      Para alterar o valor de gentileza de um programa que já está sendo executado, usamos uma ferramenta chamada renice:

      <pre>renice 0 <span class=“highlight”>PIDtoprioritize</span></pre>

      Nota: embora o comando nice opere necessariamente com um nome de comando, o renice opera chamando o PID do processo

      Conclusão


      O gerenciamento de processos é um tópico que pode ser de difícil compreensão para novos usuários, pois as ferramentas usadas são diferentes de seus equivalentes gráficos.

      No entanto, as ideias são habituais e intuitivas e, com um pouco de prática, se tornarão naturais. Como os processos estão envolvidos em tudo o que é feito em um sistema de computador, aprender como controlá-los de maneira eficaz é uma habilidade essencial.

      <div class=“author”>Por Justin Ellingwood</div>



      Source link

      Cómo usar Journalctl para ver y manipular los registros de Systemd


      Introducción

      Algunas de las ventajas más convincentes de systemd son las que se relacionan con el proceso y registro del sistema. Al usar otros sistemas, los registros suelen estar dispersos por todo el sistema, son manejados por diferentes demonios y herramientas, y puede ser bastante difícil de interpretar cuando abarcan varias aplicaciones. Systemd intenta resolver estos problemas al proporcionar una solución de administración centralizada para registrar todos los procesos del kernel y del usuario. El sistema que recopila y administra estos registros se conoce como diario.

      El diario se implementa con el demonio journald, que gestiona todos los mensajes producidos por el kernel, initrd, servicios, etc. En esta guía, veremos cómo usar la utilidad journalctl, que puede usarse para acceder y manipular los datos que se encuentran dentro del diario.

      Idea general

      Uno de los impulsos detrás del diario systemd es centralizar la administración de los registros, independientemente de dónde se originen los mensajes. Dado que el proceso systemd gestiona gran parte del proceso de arranque y administración de servicios, tiene sentido estandarizar la forma en que se recopila y acceden a estos registros. El demonio journald recopila datos de todas las fuentes disponibles y los almacena en un formato binario para una manipulación fácil y dinámica.

      Eso nos proporciona varias ventajas significativas. Al interactuar con los datos usando una sola utilidad, los administradores pueden mostrar datos de registro de forma dinámica según sus necesidades. Esto puede ser tan simple como ver los datos del arranque de hace tres arranques o combinar las entradas de registro de forma secuencial de dos servicios relacionados para depurar un problema de comunicación.

      Almacenar los datos de registro en formato binario también significa que los datos pueden mostrarse en formatos de salida arbitrarios dependiendo de lo que se necesite en el momento. Por ejemplo, para la gestión de los registros diarios puede que esté acostumbrado a ver los registros en el formato estándar de syslog, pero si decide graficar las interrupciones del servicio más adelante, puede mostrar cada entrada como un objeto JSON para que sea consumible en su servicio gráfico. Dado que los datos no se escriben en el disco en texto plano, no es necesario convertirlos cuando se necesita un distinto formato bajo demanda.

      El diario systemd puede usarse con una implementación de syslog existente o puede sustituir la funcionalidad syslog, según sus necesidades. Aunque el diario systemd cubrirá la mayoría de las necesidades de registro del administrador, también puede complementar los mecanismos de registro existentes. Por ejemplo, es posible que tenga un servidor syslog centralizado que utilice para compilar datos de varios servidores, pero también es posible que quiera interconectar los registros de varios servicios en un solo sistema con el diario systemd. Puede hacer ambas cosas combinando estas tecnologías.

      Configurar la hora del sistema

      Una de las ventajas de usar un diario binario para el registro es la posibilidad de ver los registros en hora UTC o local libremente. systemd mostrará los resultados en hora local de manera predeterminada.

      Debido a esto, antes de comenzar con el diario, nos aseguraremos de que la zona horaria esté configurada correctamente. El paquete de systemd realmente viene con una herramienta llamada timedatectl que puede ayudar con esto.

      Primero, consulte qué zonas horarias están disponibles con la opción list-timezones:

      timedatectl list-timezones
      

      Esto mostrará la lista de zonas horarias disponibles en su sistema. Cuando encuentre la que coincida con la ubicación de su servidor, puede configurarla usando la opción set-timezone:

      sudo timedatectl set-timezone zone
      

      Para asegurarse de que su máquina esté usando la hora correcta actual, utilice el comando timedatectl solo o con la opción status. En la pantalla, se mostrará lo mismo:

      timedatectl status
      
            Local time: Thu 2015-02-05 14:08:06 EST
        Universal time: Thu 2015-02-05 19:08:06 UTC
              RTC time: Thu 2015-02-05 19:08:06
             Time zone: America/New_York (EST, -0500)
           NTP enabled: no
      NTP synchronized: no
       RTC in local TZ: no
            DST active: n/a
      

      La primera línea debe mostrar la hora correcta.

      Visualización básica de registros

      Para ver los registros que el demonio journald ha recopila el comando journalctl.

      Cuando se utilice solo, cada entrada de diario que se encuentre en el sistema se mostrará dentro de un localizador (por lo general, less) para que pueda navegar en él Las entradas más antiguas estarán arriba:

      journalctl
      
      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
      Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules
      
      . . .
      

      Es probable que tenga que desplazarse por páginas y páginas de datos, que pueden ser decenas o cientos de miles de líneas si systemd ha estado en su sistema por mucho tiempo. Esto demuestra la cantidad de datos disponibles en la base de datos del diario.

      El formato será familiar para aquellos que se utilizan para el registro syslog estándar. Sin embargo, esto realmente recopila datos de más fuentes de las que las implementaciones syslog tradicionales son capaces de recopilar. Incluye registros del proceso de arranque inicial, el kernel, el initrd, el error de estándar de la aplicación y la salida. Todos ellos están disponibles en el diario.

      Es posible que observe que todas las marcas de tiempo que se muestran son de hora local. Esto está disponible para cada entrada de registro ahora que tenemos nuestro tiempo local correctamente configurado en el sistema. Todos los registros se muestran usando esta nueva información.

      Si desea mostrar las marcas de tiempo en hora UTC, puede usar el indicador --utc:

      journalctl --utc
      

      Filtrado del diario por hora

      A pesar de que tener acceso a una colección tan grande de datos es definitivamente útil, es difícil o imposible inspeccionar y procesar mentalmente tal gran cantidad de datos. Debido a esto, una de las características más importantes de journalctl son sus opciones de filtrado.

      Mostrar los registros del arranque actual

      La más básica de estas que puede usar diariamente, es el indicador -b. Este indicador mostrará todas las entradas del diario que se recopilaron desde el reinicio más reciente.

      journalctl -b
      

      Esto le ayudará a identificar y administrar la información que sea pertinente para su entorno actual.

      En los casos en que no se usa esta función y se muestran más de un día de arranques, verá que journalctl insertó una línea parecida a la siguiente cada vez que el sistema se cae:

      . . .
      
      -- Reboot --
      
      . . .
      

      Lo puede usar para separar la información de manera lógica en sesiones de arranque.

      Arranques anteriores

      Aunque por lo general querrá mostrar la información del arranque actual, hay ocasiones en que los arranques anteriores también son útiles. El diario puede guardar la información de varios arranques anteriores, por lo que journalctl puede usarse para mostrar la información más fácilmente.

      Algunas distribuciones permiten guardar la información de los arranques anteriores de manera predeterminada, mientras que otras deshabilitan esta función. Para habilitar la información de arranque persistente, puede crear el directorio para almacenar el diario escribiendo lo siguiente:

      • sudo mkdir -p /var/log/journal

      O puede editar el archivo de configuración del diario:

      • sudo nano /etc/systemd/journald.conf

      En la sección [Journal], establezca la opción Storage= en “persistent” (persistente) para habilitar el registro persistente:

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Cuando la opción de guardar los arranques anteriores está habilitada en su servidor, journalctl proporciona algunos comandos para ayudarlo a trabajar con los arranques como unidad de división. Para ver los arranques que journald conoce, utilice la opción --list-boots con journalctl:

      journalctl --list-boots
      
      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
      -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
       0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
      

      Esto mostrará una línea para cada arranque. La primera columna es la compensación del arranque que puede usarse para hacer referencia fácilmente al arranque con journalctl. Si necesita una referencia absoluta, el ID del arranque está en la segunda columna. Puede saber la hora a la que se refiere la sesión de arranque con las dos especificaciones de hora que aparecen al final.

      Para mostrar la información de estos arranques, puede usar la información de la primera o la segunda columna.

      Por ejemplo, para ver el diario del arranque anterior, utilice el puntero relativo -1 con el indicador -b:

      journalctl -b -1
      

      También puede usar el ID de arranque invocar los datos de un arranque:

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Ventanas de tiempo

      Aunque ver las entradas de registro por arranque es increíblemente útil, en ocasiones es posible que quiera solicitar ventanas de tiempo que no se alinean bien con el arranque del sistema. Este puede ser el caso especialmente cuando se trata de servidores de larga duración con un tiempo de actividad significativo.

      Puede filtrar por límites de tiempo arbitrarios usando las opciones --since y --until, que restringen las entradas mostradas a aquellas posteriores o anteriores al tiempo indicado, respectivamente.

      Los valores de tiempo pueden venir en varios formatos. Para los valores absolutos de tiempo, debe usar el siguiente formato:

      YYYY-MM-DD HH:MM:SS
      

      Por ejemplo, podemos ver todas las entradas desde el 10 de enero de 2015 a las 5:15 p. m. escribiendo:

      journalctl --since "2015-01-10 17:15:00"
      

      Si se omiten los componentes del formato anterior, se aplicarán algunos valores predeterminados. Por ejemplo, si se omite la fecha, se asumirá la fecha actual. Si falta el componente que hace referencia a la hora, se sustituirá por “00:00:00” (medianoche). El campo de los segundos también se puede omitir para que aparezca “00” de manera predeterminada:

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"
      

      El diario también comprende algunos valores relativos y los accesos directos con nombre. Por ejemplo, puede usar las palabras “yesterday”, “today”, “tomorrow”, o “now”. Puede hacer referencia a tiempos relativos anteponiendo “-” o “+” a un valor numérico o utilizando palabras como “ago” en la construcción de las instrucciones.

      Para obtener los datos del día de ayer, puede escribir lo siguiente:

      journalctl --since yesterday
      

      Si recibió informes de una interrupción del servicio que comenzó a las 9:00 a.m. y continuó hasta hace una hora, puede escribir lo siguiente:

      journalctl --since 09:00 --until "1 hour ago"
      

      Como puede ver, es relativamente fácil definir ventanas de tiempo flexibles para filtrar las entradas que desea ver.

      Filtrado por interés de mensaje

      En la sección anterior hemos aprendido algunas formas de filtrar los datos del diario utilizando restricciones de tiempo. En esta sección, veremos cómo filtrar según el servicio o componente que le interese. El diario systemd proporciona varias formas de hacer esto.

      Por unidad

      Probablemente la forma más útil de filtrar es por la unidad que le interesa. Podemos usar la opción -u para filtrar de esta manera.

      Por ejemplo, para ver todos los registros de una unidad de Nginx en nuestro sistema, podemos escribir lo siguiente:

      journalctl -u nginx.service
      

      Por lo general, también querrá filtrar por tiempo para mostrar las líneas que le interesa. Por ejemplo, para comprobar cómo se está ejecutando el servicio hoy, puede escribir lo siguiente:

      journalctl -u nginx.service --since today
      

      Este tipo de enfoque resulta extremadamente útil cuando se aprovecha la capacidad del diario para intercalar registros de varias unidades. Por ejemplo, si su proceso de Nginx está conectado a una unidad PHP-FPM para procesar contenido dinámico, puede combinar las entradas de ambos en orden cronológico especificando ambas unidades:

      journalctl -u nginx.service -u php-fpm.service --since today
      

      Eso puede hacer que sea mucho más fácil detectar las interacciones entre diferentes programas y sistemas de depuración en vez de procesos individuales.

      Por proceso, usuario o ID de grupo

      Algunos servicios generan varios procesos secundarios para realizar el trabajo. Si ha localizado el PID exacto del proceso que le interesa, también se puede hacer un filtrado basándonos en eso.

      Para hacer esto, podemos filtrar especificando el campo _PID. Por ejemplo, si el PID que nos interesa es 8088, podemos escribir lo siguiente:

      journalctl _PID=8088
      

      En otras ocasiones, es posible que quiera mostrar todas las entradas registradas de un usuario o de un grupo específico. Esto puede hacerse con los filtros _UID o _GID. Por ejemplo, si su servidor web se ejecuta bajo el usuario www-data, puede encontrar el ID de usuario escribiendo lo siguiente:

      id -u www-data
      
      33
      

      Luego, puede usar el ID que salió en la búsqueda para filtrar los resultados del diario:

      journalctl _UID=33 --since today
      

      El diario systemd tiene muchos campos que pueden usarse para filtrar. Algunos de estos son pasados desde el proceso que se está registrando y otros son aplicados por journald usando la información que recopila del sistema en el momento del registro.

      El símbolo inicial de guion bajo indica que el campo _PID es de este último tipo. El diario registra e indexa automáticamente el PID del proceso que está registrando para filtrarlo después. Puede obtener información sobre todos los campos disponibles del diario escribiendo lo siguiente:

      man systemd.journal-fields
      

      En esta guía, veremos algunas de estas opciones. Por ahora, sin embargo, vamos a repasar una opción más útil que tiene que ver con el filtrado mediante estos campos. La opción -F puede usarse para mostrar todos los valores disponibles para un determinado campo del diario.

      Por ejemplo, para ver qué ID de grupo tiene entradas el diario systemd, puede escribir lo siguiente:

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Esto mostrará todos los valores que el diario almacenó para el campo del ID de grupo. Esto puede ayudarlo a crear sus filtros.

      Por ruta de componente

      También podemos filtrar proporcionando una ubicación de ruta.

      Si la ruta conduce a un ejecutable, journalctl mostrará todas las entradas que implican el ejecutable en cuestión. Por ejemplo, para encontrar aquellas entradas que implican el ejecutable bash, puede escribir lo siguiente:

      journalctl /usr/bin/bash
      

      Por lo general, si una unidad está disponible para el ejecutable, ese método es más limpio y proporciona mejor información (entradas de procesos secundarios asociados, etc.). A veces, sin embargo, eso no es posible.

      Mostrar mensajes de kernel

      Los mensajes de kernel, que suelen encontrarse en el resultado de dmesg, también se pueden recuperar del diario.

      Para mostrar solo estos mensajes, podemos añadir los indicadores -k o --dmesg a nuestro comando:

      journalctl -k
      

      De manera predeterminada, esto mostrará los mensajes del kernel del arranque actual. Puede especificar un arranque alternativo usando los indicadores normales de selección de arranque que se mostraron anteriormente. Por ejemplo, para obtener los mensajes de hace cinco arranques, puede escribir lo siguiente:

      journalctl -k -b -5
      

      Por prioridad

      Un filtro que suele interesar a los administradores de sistemas es el de prioridad de mensaje. Aunque a menudo es útil registrar información a un nivel muy verboso, cuando realmente se asimila la información disponible, los registros de baja prioridad pueden distraer y confundir.

      Puede usar journalctl para mostrar solo mensajes de una prioridad especifica o superior usando la opción -p. Esto le permite filtrar mensajes de menor prioridad.

      Por ejemplo, para mostrar solo las entradas registradas en el nivel de error o superior, puede escribir lo siguiente:

      journalctl -p err -b
      

      Esto le mostrará todos los mensajes marcados como error, crítico, alerta o emergencia. El diario implementa los niveles de mensaje syslog estándar. Puede usar el nombre de prioridad o su valor numérico correspondiente. En orden de mayor a menor prioridad, estos son:

      • 0: emergencia
      • 1: alerta
      • 2: crítico
      • 3: error
      • 4: advertencia
      • 5: aviso
      • 6: información
      • 7: depuración

      Los números o nombres anteriores pueden usarse indistintamente con la opción -p. Al seleccionar una prioridad, se mostrarán los mensajes marcados en el nivel especificado y aquellos que se encuentran por encima.

      Modificar la pantalla del diario

      Anteriormente, hemos demostrado la selección de entradas mediante el filtrado. Sin embargo, hay otras formas de modificar el resultado. Podemos ajustar la pantalla journalctl para que se adapte a varias necesidades.

      Truncar o ampliar el resultado

      Podemos ajustar la forma en que journalctl muestra datos indicándole que reduzca o amplíe el resultado.

      Por defecto, journalctl mostrará toda la entrada en el localizador, permitiendo que las entradas se desplacen a la derecha de la pantalla. Se puede acceder a esta información presionando la tecla de flecha derecha.

      Si prefiere truncar el resultado, insertar un elipses donde se eliminó la información, puede usar la opción --no-full:

      journalctl --no-full
      
      . . .
      
      Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
      Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
      Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
      

      También puede hacer lo opuesto e indicarle a journalctl que muestre toda la información, independientemente de si incluye caracteres no imprimibles. Podemos hacerlo con el indicador -a:

      journalctl -a
      

      Resultado a la salida estándar

      Por defecto, journalctl muestra el resultado en un localizador para un uso más sencillo. Sin embargo, si está planeando procesar los datos con herramientas de manipulación de texto, es probable que quiera poder mostrar un resultado estándar.

      Puede hacer esto con la opción --no-pager:

      journalctl --no-pager
      

      Se puede canalizar inmediatamente a una utilidad de procesamiento o redireccionar a un archivo en el disco, dependiendo de sus necesidades.

      Formatos de resultado

      Si está procesando las entradas del diario, como se mencionó anteriormente, es probable que le resulte más fácil analizar los datos si están en un formato más fácil de usar. Afortunadamente, el diario puede mostrarse en varios formatos según sea necesario. Puede hacerlo usando la opción -o con un especificador de formato.

      Por ejemplo, puede mostrar las entradas del diario en JSON escribiendo lo siguiente:

      journalctl -b -u nginx -o json
      
      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
      
      . . .
      

      Eso es útil para el análisis sintáctico con utilidades. Puede usar el formato json-pretty para obtener un mejor manejo de la estructura de datos antes de transmitirla al consumidor JSON:

      journalctl -b -u nginx -o json-pretty
      
      {
          "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
          "__REALTIME_TIMESTAMP" : "1422990364739502",
          "__MONOTONIC_TIMESTAMP" : "27200938",
          "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
          "PRIORITY" : "6",
          "_UID" : "0",
          "_GID" : "0",
          "_CAP_EFFECTIVE" : "3fffffffff",
          "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
          "_HOSTNAME" : "desktop",
          "SYSLOG_FACILITY" : "3",
          "CODE_FILE" : "src/core/unit.c",
          "CODE_LINE" : "1402",
          "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
          "SYSLOG_IDENTIFIER" : "systemd",
          "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
          "_TRANSPORT" : "journal",
          "_PID" : "1",
          "_COMM" : "systemd",
          "_EXE" : "/usr/lib/systemd/systemd",
          "_CMDLINE" : "/usr/lib/systemd/systemd",
          "_SYSTEMD_CGROUP" : "/",
          "UNIT" : "nginx.service",
          "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
          "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
      }
      
      . . .
      

      Se pueden usar los siguientes formatos para la visualización:

      • cat: Muestra solo el campo de mensaje.
      • export: Formato binario adecuado para transferir o hacer copias de seguridad.
      • json: JSON estándar con una entrada por línea.
      • json-pretty: JSON formateado para una mejor legibilidad humana
      • json-sse: Resultado formateado JSON envuelto para hacer que el evento enviado por servidor sea compatible
      • short: El resultado de estilo syslog predeterminado
      • short-iso: El formato predeterminado aumentado para mostrar las marcas de tiempo del reloj de pared ISO 8601.
      • short-monotonic: El formato predeterminado con marcas de tiempo monotónicas.
      • short-precise: El formato predeterminado con precisión de microsegundos.
      • verbose: Muestra todos los campos del diario disponibles para la entrada, incluidos los que suelen estar ocultos internamente.

      Estas opciones le permiten mostrar las entradas del diario en el formato que mejor se adapte a sus necesidades actuales.

      Supervisión activa de procesos

      El comando journalctl imita la cantidad de administradores que utilizan tail para supervisar la actividad activa o reciente. Esta funcionalidad está incorporada en journalctl, lo que le permite acceder a estas funciones sin necesidad de recurrir a otra herramienta.

      Cómo mostrar los registros recientes

      Para mostrar una cantidad determinada de registros, puede usar la opción -n, que funciona exactamente igual que tail -n.

      Por defecto, se mostrarán las 10 entradas más recientes:

      journalctl -n
      

      Puede especificar el número de entradas que desea ver agregando un número después de -n:

      journalctl -n 20
      

      Cómo hacer un seguimiento de los registros

      Para seguir activamente los registros a medida que se escriben, puede usar el indicador -f. Una vez más, esto funciona de la manera prevista si tiene experiencia usando tail -f:

      journalctl -f
      

      Mantenimiento del diario

      Es posible que se esté preguntando sobre el costo de almacenar todos los datos que hemos visto hasta ahora. Además, puede que le interese limpiar algunos registros antiguos y liberar espacio.

      Cómo encontrar el uso actual de disco

      Puede averiguar la cantidad de espacio que el diario está ocupando actualmente en el disco usando la opción el indicador --disk-usage:

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Cómo eliminar registros antiguos

      Si desea reducir su diario, puede hacerlo de dos distintas formas (disponibles en la versión 218 y posterior de systemd).

      Si usa la opción --vacuum-size, puede reducir su diario indicando un tamaño. Esto eliminará las entradas antiguas hasta que el espacio total del diario ocupado en el disco sea del tamaño solicitado:

      sudo journalctl --vacuum-size=1G
      

      Otra forma de reducir el diario es proporcionar un tiempo límite con la opción --vacuum-time. Cualquier entrada que sobrepase ese límite de tiempo será eliminada. Esto le permite mantener las entradas que se han creado después de un tiempo específico.

      Por ejemplo, para guardar las entradas del último año, puede escribir lo siguiente:

      sudo journalctl --vacuum-time=1years
      

      Cómo limitar la expansión del diario

      Puede configurar su servidor para que ponga límites sobre cantidad de espacio que puede ocupar el diario. Puede hacer esto editando el archivo /etc/systemd/journald.conf

      Puede usar los siguientes elementos para limitar la expansión del diario:

      • SystemMaxUse=: especifica el espacio máximo de disco que puede usar el diario en el almacenamiento persistente.
      • SystemKeepFree=: especifica la cantidad de espacio que el diario debe dejar libre al añadir entradas del diario al almacenamiento persistente.
      • SystemMaxFileSize=: controla el tamaño que pueden alcanzar los archivos individuales del diario en el almacenamiento persistente antes de rotar.
      • RuntimeMaxUse=: especifica el espacio máximo de disco que puede usarse en el almacenamiento volátil (dentro del sistema de archivos /run).
      • RuntimeKeepFree=: especifica la cantidad de espacio que debe reservarse para otros usos al escribir datos en el almacenamiento volátil (dentro del sistema de archivos /run).
      • RuntimeMaxFileSize=: especifica la cantidad de espacio que puede ocupar un archivo de diario individual en el almacenamiento volátil (dentro del sistema de archivos /run) antes de rotar.

      Al establecer estos valores, puede controlar la forma en que journald utiliza y preserva el espacio en su servidor. Tenga en cuenta que SystemMaxFileSize y RuntimeMaxFileSize orientarán los archivos para llegar a los límites indicados. Es importante recordar esto al interpretar el recuento de archivos después de una operación vaciado.

      Conclusión

      Como puede ver, el diario systemd es increíblemente útil para recopilar y administrar los datos de su sistema y aplicación. Su flexibilidad proviene, en mayor parte, de los amplios metadatos registrados automáticamente y del carácter centralizado del registro. El comando journalctl hace que sea fácil aprovechar las funciones avanzadas del diario, realizar amplios análisis y depurar de forma relacional los diferentes componentes de la aplicación.



      Source link