Tutorial de Introdu??o ao Systemd: Parte Prática

Tutorial de Introdu??o ao Systemd: Parte de Comandos

Autor: Ruan Yifeng

Data: 7 de mar?o de 2016

Systemd é uma ferramenta do sistema Linux usada para iniciar. daemon tornou-se a configura??o padr?o na maioria das distribui??es.

Este artigo apresenta seu uso básico, dividido em duas partes. Hoje, vamos apresentar seus principais comandos. Próximo artigo. Introduza como usar em situa??es reais.

1. Origem

Na história, Inicializa??o do Linux sempre adotado init Processo.

O comando abaixo é usado para iniciar o servi?o.

xxxxxxxxxx
			
			

			

			

				

					

					

					
$ sudo /etc/init.d/apache2 start
				
				
ou
				

					
$ service apache2 start
				
			
			
			
			
			
			

			

			
			
			

Esse método tem duas desvantagens.

Primeiro, o tempo de inicializa??o é longo. init Os processos s?o iniciados em série, e apenas quando o processo anterior é concluído, o próximo processo será iniciado.

Em segundo lugar, o script de inicializa??o é complexo. init O processo apenas executa o script de inicializa??o, sem se preocupar com outras coisas. O script precisa lidar com várias situa??es por conta própria, o que muitas vezes faz com que o script se torne muito longo.

II. Vis?o Geral do Systemd

O Systemd foi criado para resolver esses problemas. Seu objetivo de design é fornecer uma solu??o completa para a inicializa??o e gerenciamento do sistema.

De acordo com a conven??o do Linux, as letras d é a abrevia??o de "daemon". O significado do nome Systemd é que ele deve proteger todo o sistema.

(A imagem acima é do autor do Systemd) Lennart Poettering ）

Usando o Systemd, n?o é mais necessário usar. init O systemd substituiu initd tornando-se o primeiro processo do sistema (PID igual a 1), outros processos s?o seus processos.

xxxxxxxxxx
				
				

				

				

					

						

						

						
$ systemctl --version
					
				
				
				
				
				
				

				

				
				
				

O comando acima verifica a vers?o do Systemd.

Systemd 的優(yōu)點(diǎn)是功能強大，使用方便，缺點(diǎn)是體系龐大，非常復雜。事實(shí)上，現在還有很多人反對使用 Systemd，理由就是它過(guò)于復雜，與操作系統的其他部分強耦合，違反"keep simple, keep stupid"的 Filosofia Unix

(A imagem acima é um diagrama da arquitetura do Systemd)

Três, Gest?o do Sistema

Systemd n?o é um comando, mas sim um conjunto de comandos que envolve todos os aspectos da gest?o do sistema.

3.1 systemctl

systemctl é o comando principal do Systemd, utilizado para gerenciar o sistema.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Reiniciar o sistema
					
					
$ sudo systemctl reboot
					
?
					
# Desligar o sistema, cortar a energia
					
$ sudo systemctl poweroff
					
?
					
# CPU parou de funcionar
					
$ sudo systemctl halt
					
?
					
# Suspender o sistema
					
$ sudo systemctl suspend
					
?
					
# Colocar o sistema em modo de hiberna??o
					
$ sudo systemctl hibernate
					
?
					
# Colocar o sistema em estado de suspens?o interativa
					
$ sudo systemctl hybrid-sleep
					
?
					
# Iniciar em modo de recupera??o (modo de usuário único)
					

						
$ sudo systemctl rescue
					
				
				
				
				
				
				

				

				
				
				

3.2 systemd-analyze

systemd-analyze O comando é usado para verificar o tempo de inicializa??o.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Verificar o tempo de inicializa??o
					
					

						
$ systemd-analyze ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
					
					
# Verifique o tempo de inicializa??o de cada servi?o
					
$ systemd-analyze blame
					
?
					
# Exibir o fluxo de processo de inicializa??o em forma de cascata
					
$ systemd-analyze critical-chain
					
?
					
# Exibir o fluxo de inicializa??o do servi?o especificado
					

						
$ systemd-analyze critical-chain atd.service
					
				
				
				
				
				
				

				

				
				
				

3.3 hostnamectl

hostnamectl O comando é usado para visualizar as informa??es do host atual.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Exibir informa??es sobre o host atual
					
					
$ hostnamectl
					
?
					
# Definir o nome do host.
					

						
$ sudo hostnamectl set-hostname rhel7
					
				
				
				
				
				
				

				

				
				
				

3.4 localectl

localectl O comando é usado para verificar as configura??es de localiza??o.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Verificar configura??es de localiza??o
					
					
$ localectl
					
?
					
# Configurar parametros de localiza??o.
					
$ sudo localectl set-locale LANG=en_GB.utf8
					

						
$ sudo localectl set-keymap en_GB
					
				
				
				
				
				
				

				

				
				
				

3.5 timedatectl

timedatectl O comando é usado para verificar a configura??o do fuso horário atual.

# Verificar a configura??o do fuso horário atual
				
				
$ timedatectl
				
?
				
# Exibir todos os fusos horários disponíveis
				

					
$ timedatectl list-timezones ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
				
				
# Definir o fuso horário atual
				
$ sudo timedatectl set-timezone America/New_York
				
$ sudo timedatectl set-time YYYY-MM-DD
				
$ sudo timedatectl set-time HH:MM:SS
				
				
				
				
				
				

				

				
				
				

3.6 loginctl

loginctl O comando é usado para ver os usuários atualmente logados.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Listar a sess?o atual
					
					
$ loginctl list-sessions
					
?
					
# Listar usuários atualmente logados
					
$ loginctl list-users
					
?
					
# Listar informa??es do usuário especificado
					
$ loginctl show-user ruanyf
				
				
				
				
				
				

				

				
				
				

quatro, unidade

4.1 Significado

O Systemd pode gerenciar todos os recursos do sistema. Diferentes recursos s?o coletivamente chamados de Unidades.

A unidade é dividida em 12 tipos.

• Unidade de servi?o: Servi?o do sistema
• Unidade alvo: um grupo composto por várias unidades.
• Unidade do Dispositivo: Hardware
• Mount Unit: ponto de montagem do sistema de arquivos
• Unidade de Automontagem: ponto de montagem automático
• Unidade de Caminho: arquivo ou caminho
• Escopo da Unidade: Processo externo n?o iniciado pelo Systemd.
• Slice Unit: Grupo de Processos
• Snapshot Unit: Snapshot do Systemd, que permite reverter para um determinado snapshot.
• Socket Unit: socket de comunica??o entre processos
• Unidade de troca: arquivo de troca
• Unidade de Temporizador: Timer

systemctl list-units O comando pode ver todas as Unidades do sistema atual.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Liste as Unidades em execu??o
					
					
$ systemctl list-units
					
?
					
# Liste todas as Unidades, incluindo aquelas sem arquivo de configura??o encontrado ou que falharam ao iniciar.
					
$ systemctl list-units --all
					
?
					
# Liste todos os Units que n?o est?o em execu??o.
					
$ systemctl list-units --all --state=inactive
					
?
					
# Liste todas as Unidades que falharam ao carregar
					
$ systemctl list-units --failed
					
?
					
# Liste todas as unidades do tipo service que est?o em execu??o.
					
$ systemctl list-units --type=service
				
				
				
				
				
				

				

				
				
				

Estado da Unidade 4.2

systemctl status O comando é usado para verificar o estado do sistema e o estado de uma única unidade.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Exibir o estado do sistema
					
					
$ systemctl status
					
?
					
# Exibir o estado de uma única Unidade
					
$ sysystemctl status bluetooth.service
					
?
					
# Mostrar o estado de uma unidade específica em um host remoto
					
$ systemctl -H root@rhel7.example.com status httpd.service
				
				
				
				
				
				

				

				
				
				

exceto status ordem, systemctl Também foram fornecidos três métodos simples para consultar o estado, principalmente para uso em instru??es de verifica??o internas do script.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Exibir se uma determinada Unidade está em execu??o
					
					
$ systemctl is-active application.service
					
?
					
# Exibir se uma Unidade está em estado de falha ao iniciar
					
$ systemctl is-failed application.service
					
?
					
# Exibir se um servi?o Unit estabeleceu um link de inicializa??o
					
$ systemctl is-enabled application.service
				
				
				
				
				
				

				

				
				
				

4.3 Gest?o de Unidade

Para os usuários, os comandos mais utilizados para iniciar e parar Unidades (principalmente servi?os) s?o os seguintes.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Iniciar um servi?o imediatamente
					
					
$ sudo systemctl start apache.service
					
?
					
# Parar um servi?o imediatamente
					
$ sudo systemctl stop apache.service
					
?
					
Reiniciar um servi?o
					
$ sudo systemctl restart apache.service
					
?
					
# Matar todos os subprocessos de um servi?o
					
$ sudo systemctl kill apache.service
					
?
					
# Recarregar o arquivo de configura??o de um servi?o
					
$ sudo systemctl reload apache.service
					
?
					
# Recarregar todos os arquivos de configura??o modificados
					
$ sudo systemctl daemon-reload
					
?
					
# Mostrar todos os parametros subjacentes de uma determinada Unidade
					
$ systemctl show httpd.service
					
?
					
# Mostrar o valor de um atributo específico de uma Unidade
					
$ systemctl show -p CPUShares httpd.service
					
?
					
# Definir um atributo específico de uma unidade
					
$ sudo systemctl set-property httpd.service CPUShares=500
				
				
				
				
				
				

				

				
				
				

4.4 Dependências

Há uma rela??o de dependência entre as unidades: A depende de B, o que significa que o Systemd, ao iniciar A, também iniciará B.

systemctl list-dependencies Comando para listar todas as dependências de uma Unidade.

xxxxxxxxxx
				
				

				

				

					

						

						

						
$ systemctl list-dependencies nginx.service
					
				
				
				
				
				
				

				

				
				
				

Na saída do comando acima, algumas dependências s?o do tipo Target (conforme descrito abaixo) e, por padr?o, n?o ser?o exibidas. Para expandir o Target, é necessário usar --all Parametro.

xxxxxxxxxx
				
				

				

				

					

						

						

						
$ systemctl list-dependencies --all nginx.service
					
				
				
				
				
				
				

				

				
				
				

Cinco, o arquivo de configura??o da Unidade.

5.1 Vis?o Geral

Cada Unit tem um arquivo de configura??o que informa ao Systemd como iniciar essa Unit.

O diretório padr?o do systemd /etc/systemd/system/ Ler o arquivo de configura??o. No entanto, a maioria dos arquivos armazenados nele s?o links simbólicos que apontam para diretórios. /usr/lib/systemd/system/ O verdadeiro arquivo de configura??o está armazenado naquele diretório.

systemctl enable O comando é usado para estabelecer uma rela??o de link simbólico entre os dois diretórios acima.

xxxxxxxxxx
				
				

				

				

					

						

						

						
$ sudo systemctl enable clamd@scan.service
					
					
# Equivalente a
					
$ sudo ln -s '/usr/lib/systemd/system/clamd@scan.service' '/etc/systemd/system/multi-user.target.wants/clamd@scan.service'
				
				
				
				
				
				

				

				
				
				

Se o arquivo de configura??o estiver configurado para iniciar automaticamente na inicializa??o, systemctl enable O comando equivale a ativar a inicializa??o automática.

correspondentemente, systemctl disable O comando é usado para revogar a rela??o de link simbólico entre dois diretórios, o que equivale a desativar a inicializa??o automática.

xxxxxxxxxx
				
				

				

				

					

						

						

						
$ sudo systemctl disable clamd@scan.service
					
				
				
				
				
				
				

				

				
				
				

A extens?o do arquivo de configura??o é o tipo dessa Unidade, como por exemplo. sshd.socket Se omitido, o sufixo padr?o do Systemd é .service ent?o sshd pode ser entendido como sshd.service 。

5.2 Estado do arquivo de configura??o

systemctl list-unit-files O comando é usado para listar todos os arquivos de configura??o.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Listar todos os arquivos de configura??o
					
					
$ systemctl list-unit-files
					
?
					
# Listar arquivos de configura??o do tipo especificado
					
$ systemctl list-unit-files --type=service
				
				
				
				
				
				

				

				
				
				

Este comando irá gerar uma lista.

xxxxxxxxxx
			
			

			

			

				

					

					

					
$ systemctl list-unit-files
				
				
?
				
UNIT FILE ? ? ? ? ? ?  STATE
				
chronyd.service ? ? ?  enabled
				
clamd@.service ? ? ? ? static
				
clamd@scan.service ? ? disabled
			
			
			
			
			
			

			

			
			
			

Esta lista mostra o status de cada perfil, totalizando quatro tipos.

• habilitado: link de inicializa??o estabelecido
• desativado: nenhum link de inicializa??o foi criado
• static: Este arquivo de configura??o n?o existe. [Install] Parte (n?o executável), apenas pode ser utilizada como dependência de outros arquivos de configura??o.
• masked: Este arquivo de configura??o está proibido de criar links de inicializa??o.

Aten??o, n?o é possível determinar a partir do estado do arquivo de configura??o se a Unidade está em execu??o. Isso deve ser realizado conforme mencionado anteriormente. systemctl status Comando.

xxxxxxxxxx
				
				

				

				

					

						

						

						
$ systemctl status bluetooth.service
					
				
				
				
				
				
				

				

				
				
				

Uma vez que o arquivo de configura??o é modificado, é necessário fazer com que o SystemD recarregue o arquivo de configura??o e, em seguida, reiniciar, caso contrário, a modifica??o n?o terá efeito.

xxxxxxxxxx
				
				

				

				

					

						

						

						
$ sudo systemctl daemon-reload
					
					
$ sudo systemctl restart httpd.service
				
				
				
				
				
				

				

				
				
				

5.3 Formato do arquivo de configura??o

O arquivo de configura??o é um arquivo de texto comum que pode ser aberto com um editor de texto.

systemctl cat O comando pode visualizar o conteúdo do arquivo de configura??o.

xxxxxxxxxx
				
				

				

				

					

						

						

						
$ systemctl cat atd.service
					
					
?
					
[Unit]
					
Description=ATD daemon
					
?
					
[Service]
					
Type=forking
					
ExecStart=/usr/bin/atd
					
?
					
[Install]
					
WantedBy=multi-user.target
				
				
				
				
				
				

				

				
				
				

A partir da saída acima, podemos ver que o arquivo de configura??o é dividido em vários blocos. A primeira linha de cada bloco é identificada por um nome entre colchetes, como [Unit] Aten??o, os nomes dos blocos e os nomes dos campos no arquivo de configura??o s?o sensíveis a maiúsculas e minúsculas.

Dentro de cada bloco, existem pares de chave-valor conectados por sinais de igual.

xxxxxxxxxx
				
				

				

				

					

						

						

						
[Section]
					
					
Directive1=value
					
Directive2=value
					
?
					
. . .
				
				
				
				
				
				

				

				
				
				

5.4 Blocos de configura??o do arquivo

[Unit] O bloco de configura??o geralmente é o primeiro bloco do arquivo de configura??o, usado para definir os metadados da Unidade e as rela??es com outras Unidades. Seus principais campos s?o os seguintes.

• Dsecription Descri??o breve
• Documentation Endere?o do documento
• Requires O Unit atual depende de outros Units; se eles n?o estiverem em execu??o, o Unit atual falhará ao iniciar.
• Wants : Outras Unidades que trabalham em conjunto com a Unidade atual, se n?o estiverem em execu??o, a Unidade atual n?o falhará ao iniciar.
• BindsTo e Requires Semelhante, se a Unidade especificada sair, fará com que a Unidade atual pare de funcionar.
• Before Se a Unidade especificada por esse campo também precisar ser iniciada, ela deve ser iniciada após a Unidade atual.
• After Se a Unidade especificada por este campo também deve ser iniciada, ela deve ser iniciada antes da Unidade atual.
• Conflicts A Unidade especificada aqui n?o pode ser executada ao mesmo tempo que a Unidade atual.
• Condition... As condi??es que a Unidade deve atender para funcionar atualmente, caso contrário, n?o funcionará.
• Assert... As condi??es que a Unidade deve atender para funcionar atualmente, caso contrário, ocorrerá uma falha na inicializa??o.

[Install] Normalmente é o último bloco do arquivo de configura??o, usado para definir como iniciar e se deve iniciar na inicializa??o do sistema. Seus principais campos s?o os seguintes.

• WantedBy O seu valor é um ou mais Targets, e o link simbólico será colocado quando a Unidade estiver ativada (enable). /etc/systemd/system Embaixo do diretório, com o nome do alvo + .wants em subdiretórios formados por sufixos
• RequiredBy Seu valor é um ou mais Targets, e quando a Unidade atual está ativada, o link simbólico será colocado. /etc/systemd/system Embaixo do diretório, com o nome do alvo + .required em subdiretórios formados por sufixos
• Alias : Alias disponível para iniciar a Unidade atual.
• Also Quando a Unidade atual está ativada (habilitada), outras Unidades que ser?o ativadas simultaneamente.

[Service] O bloco de configura??o usado para o Service é exclusivo para unidades do tipo Service. Seus principais campos s?o os seguintes.

• Type Define o comportamento do processo na inicializa??o. Ele possui os seguintes valores.
• Type=simple Valor padr?o, executar ExecStart Comando especificado, iniciar o processo principal.
• Type=forking : Criar um processo filho a partir do processo pai usando a forma fork, e após a cria??o, o processo pai sairá imediatamente.
• Type=oneshot Processo de uma única vez, o Systemd aguardará a saída do servi?o atual antes de continuar a execu??o.
• Type=dbus O servi?o atual é iniciado através do D-Bus.
• Type=notify O servi?o atual foi iniciado com sucesso e será notificado. Systemd Continue a executar.
• Type=idle Se houver outras tarefas concluídas, o servi?o atual só será executado ent?o.
• ExecStart Comando para iniciar o servi?o atual.
• ExecStartPre Comandos a serem executados antes de iniciar o servi?o atual.
• ExecStartPost Comando executado após iniciar o servi?o atual.
• ExecReload Comando executado ao reiniciar o servi?o atual.
• ExecStop Comando executado ao parar o servi?o atual.
• ExecStopPost : Comando a ser executado após a interrup??o do servi?o
• RestartSec Número de segundos para reiniciar o servi?o atual automaticamente.
• Restart Definir em quais situa??es o Systemd reiniciará automaticamente o servi?o atual, os valores possíveis incluem: always (Sempre reiniciando) on-success 、 on-failure 、 on-abnormal 、 on-abort 、 on-watchdog
• TimeoutSec Definir o número de segundos que o Systemd espera antes de parar o servi?o atual.
• Environment Definir variáveis de ambiente

Para a lista completa de campos de configura??o do arquivo Unit, consulte. Documenta??o oficial

Seis, Alvo

Ao iniciar o computador, é necessário ativar uma grande quantidade de unidades (Unit). Se a cada inicializa??o for necessário especificar quais unidades s?o necessárias, isso se torna claramente muito inconveniente. A solu??o do Systemd é o Target.

簡(jiǎn)單說(shuō)，Target 就是一個(gè) Unit 組，包含許多相關(guān)的 Unit 。啟動(dòng)某個(gè) Target 的時(shí)候，Systemd 就會(huì )啟動(dòng)里面所有的 Unit。從這個(gè)意義上說(shuō)，Target這個(gè)概念類(lèi)似于"狀態(tài)點(diǎn)"，啟動(dòng)某個(gè) Target 就好比啟動(dòng)到某種狀態(tài)。

tradicional init No modo de inicializa??o, há o conceito de RunLevel, que tem uma fun??o semelhante à de Target. A diferen?a é que RunLevel é mutuamente exclusivo, n?o é possível iniciar múltiplos RunLevels ao mesmo tempo, enquanto múltiplos Targets podem ser iniciados simultaneamente.

xxxxxxxxxx
				
				

				

				

					

						

						

						
# Ver todos os Targets do sistema atual
					
					
$ systemctl list-unit-files --type=target
					
?
					
# Ver todos os Unidades contidas em um Target
					
$ systemctl list-dependencies multi-user.target
					
?
					
# Verificar o Target padr?o durante a inicializa??o
					
$ systemctl get-default
					
?
					
# Definir o Target padr?o na inicializa??o
					
$ sudo systemctl set-default multi-user.target
					
?
					
# Ao alternar o Target, n?o feche por padr?o o processo iniciado pelo Target anterior.
					
O comando # systemctl isolate altera esse comportamento.
					
# Fechar todos os processos do Target anterior que n?o pertencem ao Target seguinte.
					
$ sudo systemctl isolate multi-user.target
				
				
				
				
				
				

				

				
				
				

A rela??o de correspondência entre o Target e o RunLevel tradicional é a seguinte.

xxxxxxxxxx
				
				

				

				

					

						

						

						
Traditional runlevel ? ?  New target name ? ? Symbolically linked to...
					
					
?
					
Runlevel 0 ? ? ? ? ? | ?  runlevel0.target -> poweroff.target
					
Runlevel 1 ? ? ? ? ? | ?  runlevel1.target -> rescue.target
					
Runlevel 2 ? ? ? ? ? | ?  runlevel2.target -> multi-user.target
					
Runlevel 3 ? ? ? ? ? | ?  runlevel3.target -> multi-user.target
					
Runlevel 4 ? ? ? ? ? | ?  runlevel4.target -> multi-user.target
					
Runlevel 5 ? ? ? ? ? | ?  runlevel5.target -> graphical.target
					
Runlevel 6 ? ? ? ? ? | ?  runlevel6.target -> reboot.target
				
				
				
				
				
				

				

				
				
				

Ele com init As principais diferen?as entre os processos s?o as seguintes.

(1) Nível de Execu??o padr?o (Em /etc/inittab As configura??es de arquivo) agora foram substituídas pelo Target padr?o, a localiza??o é /etc/systemd/system/default.target geralmente simboliza um link para graphical.target (interface gráfica) ou multi-user.target (Múltiplos usuários na linha de comando).

Localiza??o do script de inicializa??o antes era /etc/init.d Diretório, links simbólicos para diferentes diretórios de RunLevel (por exemplo, /etc/rc3.d 、 /etc/rc5.d agora está armazenado em /lib/systemd/system e /etc/systemd/system índice.

(3) Localiza??o do arquivo de configura??o antes init O arquivo de configura??o do processo é /etc/inittab os arquivos de configura??o dos diversos servi?os est?o armazenados em /etc/sysconfig índice. Os arquivos de configura??o atuais est?o principalmente armazenados em /lib/systemd índice, em /etc/systemd As altera??es no diretório podem substituir as configura??es originais.

Sete, Gest?o de Registros

O Systemd gerencia de forma unificada os logs de inicializa??o de todas as Unidades. A vantagem disso é que você pode usar apenas journalctl Um comando para visualizar todos os logs (logs do kernel e logs de aplicativos). O arquivo de configura??o dos logs é /etc/systemd/journald.conf 。

journalctl Poderoso, com muitas aplica??es.

# Ver todos os logs (por padr?o, apenas os logs da inicializa??o atual s?o salvos)
				
				
$ sudo journalctl
				
?
				
# Verificar o log do kernel (n?o exibir logs de aplicativos)
				
$ sudo journalctl -k
				
?
				
# Verifique os logs da inicializa??o do sistema desta vez.
				
$ sudo journalctl -b
				
$ sudo journalctl -b -0
				
?
				
# Verifique o log da última inicializa??o (é necessário alterar as configura??es)
				
$ sudo journalctl -b -1
				
?
				
# Ver logs de um horário específico
				
$ sudo journalctl --since="2012-10-30 18:17:16"
				
$ sudo journalctl --since "20 min ago"
				
$ sudo journalctl --since yesterday
				
$ sudo journalctl --since "2015-01-10" --until "2015-01-11 03:00"
				
$ sudo journalctl --since 09:00 --until "1 hour ago"
				
?
				
# Exibir as últimas 10 linhas do log no final
				
$ sudo journalctl -n
				
?
				
# Exibir as linhas de log especificadas no final
				
$ sudo journalctl -n 20
				
?
				
# Exibi??o em tempo real dos logs mais recentes
				
$ sudo journalctl -f
				
?
				
# Verificar os logs do servi?o especificado
				
$ sudo journalctl /usr/lib/systemd/systemd
				
?
				
# Verificar os logs de um processo específico
				
$ sudo journalctl _PID=1
				
?
				
# Verificar os logs de um script em um determinado caminho
				
$ sudo journalctl /usr/bin/bash
				
?
				
# Verificar os logs de um usuário específico
				
$ sudo journalctl _UID=33 --since today
				
?
				
# Ver logs de uma unidade específica
				
$ sudo journalctl -u nginx.service
				
$ sudo journalctl -u nginx.service --since today
				
?
				
# Exibi??o em tempo real dos últimos logs de uma Unidade
				
$ sudo journalctl -u nginx.service -f
				
?
				
# Mesclar logs de várias unidades
				
$ journalctl -u nginx.service -u php-fpm.service --since today
				
?
				
# Ver logs de prioridade especificada (e acima), totalizando 8 níveis.
				
# 0: emerg
				
# 1: alert
				
# 2: crit
				
# 3: err
				
# 4: warning
				
# 5: notice
				
# 6: info
				

					
# 7: debug
				
				
$ sudo journalctl -p err -b
				

					
?
				
				
# Saída padr?o de log com pagina??o desativada, --no-pager alterado para saída padr?o normal.
				
$ sudo journalctl --no-pager
				
?
				
{"output": "Saída em formato JSON (uma linha)"}
				
$ sudo journalctl -b -u nginx.service -o json
				
?
				
```json
{
  "message": "A saída em formato JSON (multilinha) é mais legível."
}
```
				
$ sudo journalctl -b -u nginx.serviceqq
				
-o json-pretty
				
?
				
# Exibir o espa?o em disco ocupado pelos logs
				
$ sudo journalctl --disk-usage
				
?
				
# Especificar o espa?o máximo ocupado pelo arquivo de log
				
$ sudo journalctl --vacuum-size=1G
				

					
?
				
				
# Especificar por quanto tempo os arquivos de log devem ser mantidos
				
$ sudo journalctl --vacuum-time=1years
				
				
				
				
				
				

				

				
				
				

(Fim)

Informa??es do documento

• Declara??o de direitos autorais: Reprodu??o livre - N?o comercial - N?o derivado - Manter atribui??o Licen?a Creative Commons 3.0 )
• Data de publica??o: 7 de mar?o de 2016