Difference between revisions of "Systemd (Português)"

From ArchWiki
Jump to: navigation, search
(Troubleshooting)
(30 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
[[Category:Boot process (Português)]]
 
[[Category:Boot process (Português)]]
 
[[ar:Systemd]]
 
[[ar:Systemd]]
 +
[[en:Systemd]]
 
[[es:Systemd]]
 
[[es:Systemd]]
 
[[fr:Systemd]]
 
[[fr:Systemd]]
Line 11: Line 12:
 
[[zh-CN:Systemd]]
 
[[zh-CN:Systemd]]
 
[[zh-TW:Systemd]]
 
[[zh-TW:Systemd]]
{{Article summary start}}
+
{{Article summary start| Sumário}}
{{Article summary text|Covers how to install and configure systemd.}}
+
{{Article summary text|Aborda como instalar e configurar o systemd.}}
{{Article summary heading|Related}}
+
{{Article summary heading|Relacionados}}
 
{{Article summary wiki|systemd/User}}
 
{{Article summary wiki|systemd/User}}
 
{{Article summary wiki|systemd/Services}}
 
{{Article summary wiki|systemd/Services}}
Line 24: Line 25:
 
De [http://freedesktop.org/wiki/Software/systemd project web page]:
 
De [http://freedesktop.org/wiki/Software/systemd project web page]:
  
:''Systemd'' é um sistema e gerenciador de serviços para Linux, compatível com os scripts de inicializações SysV e LS. ''Systemd'' fornece recursos de paralelização agressivos, usa socket e ativação [[D-Bus]] para iniciar seviços, oferece o incicio de daemons on-demand, mantém o registro de processos usando Linux [[cgroups|control groups]], suporte snapshotting e restauração do estado do sistema, preserva pontos de montagens e automontagens e implementa uma lógica de controle elaborado transacional baseada em dependência de serviço.
+
:''Systemd'' é um sistema e gerenciador de serviços para Linux, compatível com os scripts de inicializações SysV e LS. ''Systemd'' fornece recursos de paralelização agressivos, usa socket e ativação [[D-Bus]] para iniciar serviços, oferece o início de daemons on-demand, mantém o registro de processos usando [[cgroups|grupos de controle]] Linux, suporte snapshotting e restauração do estado do sistema, preserva pontos de montagens e automontagens e implementa uma lógica de controle elaborado transacional baseada em dependência de serviço.
  
{{Nota|1=Para uma explicação detalhada do porquê Arch mudou-se para ''systemd'', consulte [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 esta mensagem do fórum internacional].}}
+
{{Nota|1=Para uma explicação detalhada do porquê Arch migrou para o ''systemd'', consulte [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 esta mensagem do fórum internacional].}}
  
== Migração de SysVinit/initscripts ==
+
== Migração do SysVinit/initscripts ==
  
 
{{Nota|
 
{{Nota|
Line 38: Line 39:
  
 
* Faça [http://freedesktop.org/wiki/Software/systemd/ algumas leituras] sobre ''systemd''.
 
* Faça [http://freedesktop.org/wiki/Software/systemd/ algumas leituras] sobre ''systemd''.
* Note que systemd tem um systema ''journal'' que substitue ''syslog'', embora os dois podem co-existir. Consulte [[#Journal]].
+
* Note que systemd tem um sistema ''journal'' que substitue ''syslog'', embora os dois podem coexistir. Consulte [[#Journal]].
* Embora ''systemd'' possa subtituir algumas das funcionabilidades do ''cron'', ''acpid'', ou ''xinetd'', não há necessidade de deixar de usar os daemons traditionais, a menos que você queira.
+
* Embora o ''systemd'' possa subtituir algumas das funcionabilidades do ''cron'', ''acpid'', ou ''xinetd'', não há necessidade de deixar de usar as daemons tradicionais, a menos que você queira.
 
* Interativo ''initscripts''  não está trabalhando com ''systemd''. Em particular, ''netcfg-menu'' não pode ser usado no sistema de inicialização ({{Bug|31377}}).
 
* Interativo ''initscripts''  não está trabalhando com ''systemd''. Em particular, ''netcfg-menu'' não pode ser usado no sistema de inicialização ({{Bug|31377}}).
  
 
=== Procedimento de instalação ===
 
=== Procedimento de instalação ===
  
# [[pacman|Instalar]] {{Pkg|systemd}} do [[official repositories]].
+
# [[pacman|Instalar]] {{Pkg|systemd}} dos [[official repositories|repositórios oficiais]].
# Acrescente o seguinte ao seu [[kernel parameters]]: {{ic|1=init=/usr/lib/systemd/systemd}}.
+
# Acrescente ao seu [[kernel parameters|parâmetros kernel ]]: {{ic|1=init=/usr/lib/systemd/systemd}}.
# Uma vez concluído, você pode permitir que todos os serviços desejados, através do uso {{ic|systemctl enable ''service_name''}} (isso equivale o que você inclue na array {{ic|DAEMONS}}. Novos nomes podem ser encontrados em [[Daemons List]]).
+
# Uma vez concluído, você pode habilitar todos os serviços desejados, através do uso {{ic|systemctl enable ''service_name''}} (equivalente a inclusão na array {{ic|DAEMONS}}. Novos nomes podem ser encontrados em [[Daemons List|Lista de Daemons]]).
 
# Reinicie seu sistema e verifique se ''systemd'' está atualmente ativo emitindo o seguinte comando: {{ic|cat /proc/1/comm}}. Isso deve retornar a string {{ic|systemd}}.
 
# Reinicie seu sistema e verifique se ''systemd'' está atualmente ativo emitindo o seguinte comando: {{ic|cat /proc/1/comm}}. Isso deve retornar a string {{ic|systemd}}.
 
# Verifique se o seu hostname está configurado corretamente com ''systemd'': {{ic|hostnamectl set-hostname ''myhostname''}} ou {{ic|/etc/hostname}}.
 
# Verifique se o seu hostname está configurado corretamente com ''systemd'': {{ic|hostnamectl set-hostname ''myhostname''}} ou {{ic|/etc/hostname}}.
 
# Proceda para remover ''initscripts'' e ''sysvinit''  de seu sistema e instale {{Pkg|systemd-sysvcompat}}.
 
# Proceda para remover ''initscripts'' e ''sysvinit''  de seu sistema e instale {{Pkg|systemd-sysvcompat}}.
# Opcionalmente, remova o parâmetro {{ic|1=init=/usr/lib/systemd/systemd}}. Não é mais necessário desde que {{Pkg|systemd-sysvcompat}} fornece um symlink para ''systemd'''s.
+
# Opcionalmente, remova o parâmetro {{ic|1=init=/usr/lib/systemd/systemd}}. Não é mais necessário desde que {{Pkg|systemd-sysvcompat}} fornece um symlink para ''systemd''.
  
 
=== Informações complementares ===
 
=== Informações complementares ===
  
* Se você tem {{ic|quiet}} em seu parâmetro kernel, você talvez queira removê-lo em seus primeiros boots com systemd, para auxiliar na identificação de eventuais problemas durante a inicialização.
+
* Se você tem {{ic|quiet}} em seu parâmetro kernel, talvez queira removê-lo nos seus primeiros boots com systemd para auxiliar na identificação de eventuais problemas durante a inicialização.
  
* Não é necessário adicionar o usuário ao [[Groups|grupos]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) para a maioria dos casos de uso com systemd. Os grupos podem até causar algumas quebras de funcionalidades. Por exemplo, o grupo {{ic|audio}} vai quebrar a troca rápida de usuário e permite que os aplicativos bloqueiem programas. Cada registro PAM fornece uma sessão de logind, no qual para uma sessão local lhe dará permissões via [[Wikipedia:Access control list|POSIX ACLs]] em dispositivos audio/video, e permite certas operações como montagem de armazenamento removível via [[udisks]].
+
* Não é necessário adicionar o usuário aos [[Groups|grupos]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, etc.) para a maioria dos casos de uso com systemd. Os grupos podem até causar algumas quebras de funcionalidades. Por exemplo, o grupo {{ic|audio}} vai quebrar a troca rápida de usuário e permite que os aplicativos bloqueiem programas. Cada registro PAM fornece uma sessão de logind, no qual para uma sessão local lhe dará permissões via [[Wikipedia:Access control list|POSIX ACLs]] em dispositivos audio/video, e permite certas operações como montagem de armazenamento removível via [[udisks]].
  
* Veja o artigo [[Network Configuration]] para saber como configurar targets de rede.
+
* Veja o artigo [[Network Configuration|Configuração de Rede]] para saber como configurar targets de rede.
  
 
== Uso básico systemctl  ==
 
== Uso básico systemctl  ==
  
O principal comando usado para introspecção e controle ''systemd'' é '''systemctl'''. Alguns de seus usos são examinando o estado do sistema e gerenciando do sistema e serviços. Consulte {{ic|man 1 systemctl}} para mais detalhes.
+
O principal comando usado para introspecção e controle ''systemd'' é '''systemctl'''. Alguns de seus usos são examinando o estado do sistema e gerenciando o sistema e serviços. Consulte {{ic|man 1 systemctl}} para mais detalhes.
  
{{Tip|Você pode usar todos os seguintes comandos ''systemctl'' com o {{ic|-H ''user''@''host''}} altera para controlar uma instância  ''systemd'' em uma máqiona remota. Isto irá usar [[SSH]] para conectar-se uma instância remota ''systemd''.}}
+
{{Dica |Você pode usar todos os comandos ''systemctl'' com o {{ic|-H ''user''@''host''}} que muda para controlar uma instância  ''systemd'' em uma máquina remota. Isso usará [[SSH]] para conectar-se uma instância remota ''systemd''.}}
  
{{Nota|''systemadm'' é a interface gráfica oficial para ''systemctl''. é fornecido pelo pacote {{AUR|systemd-ui-git}} do [[AUR]].}}
+
{{Nota|''systemadm'' é a interface gráfica oficial para ''systemctl''. é fornecida pelo pacote {{AUR|systemd-ui-git}} do [[AUR]].}}
  
 
=== Analisando o estado do sistema ===
 
=== Analisando o estado do sistema ===
Line 92: Line 93:
 
Quando usa ''systemctl'', você geralmente tem que especificar o nome completo do arquivo unit, incluindo o sufixo, por exemplo ''sshd.socket''. No entanto, existem algumas formas curtas de especificar a unit nos seguintes comandos ''systemctl'':
 
Quando usa ''systemctl'', você geralmente tem que especificar o nome completo do arquivo unit, incluindo o sufixo, por exemplo ''sshd.socket''. No entanto, existem algumas formas curtas de especificar a unit nos seguintes comandos ''systemctl'':
  
* Se você não especificar o sufixo, systemctl irá assumir ''.service''. Por exemplo, {{ic|netcfg}} e {{ic|netcfg.service}} são equivalentes.
+
* Se você não especificar o sufixo, systemctl assumirá ''.service''. Por exemplo, {{ic|netcfg}} e {{ic|netcfg.service}} são equivalentes.
 
* Os pontos de montagem serão automaticamente convertidos para a unit ''.mount'' adequada. Por exemplo, especificando {{ic|/home}} equivale a {{ic|home.mount}}.
 
* Os pontos de montagem serão automaticamente convertidos para a unit ''.mount'' adequada. Por exemplo, especificando {{ic|/home}} equivale a {{ic|home.mount}}.
 
* Similar aos pontos de montagem, dispositivos são automaticamente convertido para a unit ''.device'' adequada, portanto, especificando {{ic|/dev/sda2}} equivale a {{ic|dev-sda2.device}}.
 
* Similar aos pontos de montagem, dispositivos são automaticamente convertido para a unit ''.device'' adequada, portanto, especificando {{ic|/dev/sda2}} equivale a {{ic|dev-sda2.device}}.
Line 127: Line 128:
 
  # systemctl enable ''unit''
 
  # systemctl enable ''unit''
  
{{Note|Serviços sem uma seção {{ic|[Install]}} são geralmente chamados por outros serviços automaticamente. Se você precisa instalá-los manualmente, use o seguinte comando, substituindo ''foo'' com o nome do serviço.
+
{{Nota |Serviços sem uma seção {{ic|[Install]}} são geralmente chamados por outros serviços automaticamente. Se você precisa instalá-los manualmente, use o seguinte comando, substituindo ''foo'' com o nome do serviço.
 
  # ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/
 
  # ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/
 
}}
 
}}
Line 151: Line 152:
 
  $ systemctl reboot
 
  $ systemctl reboot
  
Desliga e desliga o sistema:
+
Desliga e encerra o sistema:
  
 
  $ systemctl poweroff
 
  $ systemctl poweroff
Line 163: Line 164:
 
  $ systemctl hibernate
 
  $ systemctl hibernate
  
Coloca o sistema no modo de suspensão :
+
Coloca o sistema em modo de suspensão :
  
 
  $ systemctl hybrid-sleep
 
  $ systemctl hybrid-sleep
Line 169: Line 170:
 
== Executando Gerenciadores de Display no systemd ==
 
== Executando Gerenciadores de Display no systemd ==
  
{{Merge|Display Manager|Temos artigo separado, esta seção deve ser mudado para lá para manter as coisas em um só lugar.}}
+
{{Merge|Display Manager|Temos artigo separado, esta seção deve ser mudada para lá para manter as coisas em um só lugar.}}
  
 
Para habilitar a autenticação gráfica, execute o seu daemon de [[Display Manager]] preferido (ex. [[KDM]]). No momento, existem arquivos de serviço para [[GDM]], [[KDM]], [[SLiM]], [[XDM]], [[LXDM]], [[LightDM]], e {{AUR|SDDM}}.
 
Para habilitar a autenticação gráfica, execute o seu daemon de [[Display Manager]] preferido (ex. [[KDM]]). No momento, existem arquivos de serviço para [[GDM]], [[KDM]], [[SLiM]], [[XDM]], [[LXDM]], [[LightDM]], e {{AUR|SDDM}}.
Line 195: Line 196:
  
 
=== Console virtual ===
 
=== Console virtual ===
{{Deletion|Não estritamente relacionados, tentando remover a seção [[#Native configuration]] inteiramente.|section=Duplication of content in Native configuration section}}
+
{{Deletion |Não estritamente relacionados, tentando remover a seção [[#Native configuration]] inteiramente.|section=Duplication of content in Native configuration section}}
  
 
O console virtual (mapeamento de teclado, fonte do console e mapa do console) é configurado em {{ic|/etc/vconsole.conf}} ou utilizando a ferramenta ''localectl''.
 
O console virtual (mapeamento de teclado, fonte do console e mapa do console) é configurado em {{ic|/etc/vconsole.conf}} ou utilizando a ferramenta ''localectl''.
Line 206: Line 207:
 
''systemd'' usará UTC para o relógio do hardware por padrão.
 
''systemd'' usará UTC para o relógio do hardware por padrão.
  
{{Tip|É aconselhável ter [[Network Time Protocol daemon]] correndo para manter a hora do sistema sincronizado com a hora da Internet e o relógio do hardware.}}
+
{{Dica |É aconselhável ter [[Network Time Protocol daemon]] correndo para manter a hora do sistema sincronizado com a hora da Internet e o relógio do hardware.}}
  
 
==== Relógio do hardware em localtime ====
 
==== Relógio do hardware em localtime ====
  
Se quiser alterar o relógio de hardware para usar horário local ('''não recomendado''') fazer:
+
Se quiser alterar o relógio de hardware para usar horário local ('''não recomendado'''), faça:
  
 
  # timedatectl set-local-rtc true
 
  # timedatectl set-local-rtc true
Line 218: Line 219:
 
  # timedatectl set-local-rtc false
 
  # timedatectl set-local-rtc false
  
Esteja avisado que, se o relógio do hardware está definido para localtime, lidar com o horário de verão é uma confusão([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html there is a lot more to it]).  
+
Fique avisado que, se o relógio do hardware está definido para localtime, lidar com o horário de verão é uma confusão([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html há muito mais do que isso]).  
  
Uma razão para permitir que o RTC esteja em hora local é permitir dual boot com o Windowss ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx which uses localtime]). No entanto, o Windows é capaz de lidar com a RTC inicando em UTC, com um simples [[Time#UTC in Windows|registry fix]].
+
Uma razão para permitir que o RTC esteja em hora local é permitir dual boot com o Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx que usa localtime]). No entanto, o Windows é capaz de lidar com a RTC iniciando em UTC, com um simples [[Time#UTC in Windows|correção de registro]].
  
 
Para mais informação, consulte [[Time]].
 
Para mais informação, consulte [[Time]].
  
 
=== Módulos do kernel ===
 
=== Módulos do kernel ===
{{Deletion|Não estritamente relacionados, tentando remover a seçãoe [[#Native configuration]] inteiramente.|section=Duplication of content in Native configuration section}}
+
{{Deletion |Não estritamente relacionados, tentando remover a seção [[#Native configuration]] inteiramente.|section=Duplication of content in Native configuration section}}
  
 
Consulte [[Kernel modules#Configuration]].
 
Consulte [[Kernel modules#Configuration]].
Line 232: Line 233:
 
{{Merge|File Systems|Esta seção foi adicionada antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão.|section=Duplication of content in Native configuration section}}
 
{{Merge|File Systems|Esta seção foi adicionada antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão.|section=Duplication of content in Native configuration section}}
  
A configuração padrão será automaticamente fsck e montará sistemas de arquivos antes de iniciar os serviços que eles precisam para serem montados. Por exemplo, systemd automaticamente garante que monta sistemas de arquivos remotos como [[NFS]] ou [[Samba]] são somente iniciados depois que a rede for configurada. Portanto, montagens de sistema de arquivos local e remoto especificados em {{ic|/etc/fstab}}} devem funcionar.
+
A configuração padrão será automaticamente fsck e montará sistemas de arquivos antes de iniciar os serviços que eles precisam para serem montados. Por exemplo, systemd automaticamente garante que montagens de sistemas de arquivos remotos como [[NFS]] ou [[Samba]] são somente iniciados depois que a rede for configurada. Portanto, montagens de sistema de arquivos local e remoto especificadas em {{ic|/etc/fstab}}} devem funcionar.
  
 
Consulte {{ic|man 5 systemd.mount}} por detalhes.
 
Consulte {{ic|man 5 systemd.mount}} por detalhes.
Line 239: Line 240:
 
{{Merge|fstab|Esta seção foi adicionada antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão.|section=Duplication of content in Native configuration section}}
 
{{Merge|fstab|Esta seção foi adicionada antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão.|section=Duplication of content in Native configuration section}}
  
Se você tem uma partição {{ic|/home}} grande, talvez seja melhor permitir que os serviços que não dependem da {{ic|/home}} para iniciar enquanto {{ic|/home}} é verificada pelo ''fsck''. Isto pode ser feito adicionando as seguintes opções em {{ic|/etc/fstab}} na entrada de ssua partição {{ic|/home}}:
+
Se você tem uma partição {{ic|/home}} grande, talvez seja melhor permitir serviços que não dependem da {{ic|/home}} para iniciar enquanto {{ic|/home}} é verificada pelo ''fsck''. Isto pode ser feito adicionando as seguintes opções em {{ic|/etc/fstab}} na entrada de sua partição {{ic|/home}}:
  
 
  noauto,x-systemd.automount
 
  noauto,x-systemd.automount
  
Isso irá fsck e montar {{ic|/home}} quando for acessada pela primeira vez, e o kernel irá reter todos os acessos de arquivo para {{ic|/home}} até que está pronto.
+
Isso irá fsck e montar {{ic|/home}} ao acessada pela primeira vez, e o kernel irá reter todos os acessos de arquivo para {{ic|/home}} até que esteja pronto.
  
{{Note|Isso vai fazer seu sistema de arquivo {{ic|/home}} tipo {{ic|autofs}}, seja ignorado pelo [[mlocate]] por padrão. A aceleração de automontagem {{ic|/home}} pode não ser mais do que um ou dois segundos, dependendo do seu sistema, de modo que este truque pode não valer a pena.}}
+
{{Nota |Isso vai fazer seu sistema de arquivo {{ic|/home}} tipo {{ic|autofs}}, seja ignorado pelo [[mlocate]] por padrão. A aceleração de automontagem {{ic|/home}} pode não ser mais do que um ou dois segundos, dependendo do seu sistema, de modo que este truque possa não valer a pena.}}
  
O mesmo se aplica para montagens de sistemas de arquivos remotos. Se você quer que eles sejam montados apenas no acesso, você vai precisar usar o parâmetro {{ic|noauto,x-systemd.automount}}. Além disso, você pode usar a opção {{ic|1=x-systemd.device-timeout=#}} para especificar um limite no caso do recurso de rede não estiver disponível.
+
O mesmo se aplica para montagens de sistemas de arquivos remotos. Se você quer que eles sejam montados apenas no acesso, você vai precisar usar o parâmetro {{ic|noauto,x-systemd.automount}}. Além disso, você pode usar a opção {{ic|1=x-systemd.device-timeout=#}} para especificar um limite no caso do recurso de rede não está disponível.
  
Se você tem sistemas de arquivos criptografados com arquivo chaves, também pode adicionar o parâmetro {{ic|noauto}} para as entradas correspondentes em {{ic|/etc/crypttab}}. ''systemd'' então não vai abrir o dispositivo criptografado no boot, mas espera até que ele seja realmente acessado e então automaticamente o abre com o arquivo chave especificado antes de montá-lo. Isso pode economizar alguns segundos na inicialização, se você estiver usando um dispositivo RAID criptografado por exemplo, porque o systemd não tem que esperar para o dispositivo se tornar disponível. Por exemplo:
+
Se você tem sistemas de arquivos criptografados com arquivo chaves, também pode adicionar o parâmetro {{ic|noauto}} para as entradas correspondentes em {{ic|/etc/crypttab}}. Então ''systemd'' não vai abrir o dispositivo criptografado no boot, mas espera até que ele seja realmente acessado e então automaticamente o abre com o arquivo chave especificado antes de montá-lo. Isso pode economizar alguns segundos na inicialização, se você estiver usando um dispositivo RAID criptografado por exemplo, porque o systemd não tem que esperar para o dispositivo se tornar disponível. Por exemplo:
  
 
{{hc|/etc/crypttab|
 
{{hc|/etc/crypttab|
Line 256: Line 257:
 
==== LVM ====
 
==== LVM ====
 
{{Merge|LVM|Esta seção foi adicionada aqui antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão.|section=Duplication of content in Native configuration section}}
 
{{Merge|LVM|Esta seção foi adicionada aqui antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão.|section=Duplication of content in Native configuration section}}
Se você não tiver volumes [[LVM]] ativados via o [[Mkinitcpio|initramfs]], [[Systemd#Using_units|enable]] o serviço '''lvm-monitoring''', que é fornecido pelo pacote {{pkg|lvm2}}.
+
Se você não tiver volumes [[LVM]] ativados via o [[Mkinitcpio|initramfs]], [[Systemd#Using_units|habilite]] o serviço '''lvm-monitoring''', que é fornecido pelo pacote {{pkg|lvm2}}.
  
 
=== Gerenciamento de energia ACPI ===
 
=== Gerenciamento de energia ACPI ===
Line 269: Line 270:
 
Cada arquivo de configuração é chamado no estilo {{ic|/etc/tmpfiles.d/''program''.conf}}. Isso também irá substituir todos os arquivos em {{ic|/usr/lib/tmpfiles.d/}} com o mesmo nome.
 
Cada arquivo de configuração é chamado no estilo {{ic|/etc/tmpfiles.d/''program''.conf}}. Isso também irá substituir todos os arquivos em {{ic|/usr/lib/tmpfiles.d/}} com o mesmo nome.
  
tmpfiles normalmente são fornecidos em conjunto com arquivos de serviços para criar diretórios que deverão existir por certas daemons. Por exemplo o daemon [[Samba]] espera que o diretório {{ic|/run/samba}} exista e tenha as permissões corretas. Assim, o pacote {{Pkg|samba}} vem com esta configuração:
+
tmpfiles normalmente são fornecidos em conjunto com arquivos de serviços para criar diretórios que deverão existir por certas daemons. Por exemplo a daemon [[Samba]] espera que o diretório {{ic|/run/samba}} exista e tenha as permissões corretas. Assim, o pacote {{Pkg|samba}} vem com esta configuração:
  
 
{{hc|/usr/lib/tmpfiles.d/samba.conf|
 
{{hc|/usr/lib/tmpfiles.d/samba.conf|
Line 281: Line 282:
 
Consulte {{ic|man 5 tmpfiles.d}} para detalhes.
 
Consulte {{ic|man 5 tmpfiles.d}} para detalhes.
  
{{Note|Este método pode não funcionar para definir as opções em {{ic|/sys}} uma vez que o serviço ''systemd-tmpfiles-setup'' pode ser executado antes dos módulos de dispositivo apropriado for carregado. Neste caso, você pode verificar se o módulo tem um parâmetro para a opção que pretende definir com {{ic|modinfo ''module''}} e setar essa opção com um [[Modprobe.d#Configuration|arquivo de configuração em /etc/modprobe.d]]. Caso contrário, você terá que escrever uma [[Udev#About_udev_rules|regra udev]] para setar o atributo adequado logo que o dispositivo aparecer.}}
+
{{Nota |Este método pode não funcionar para definir as opções em {{ic|/sys}} uma vez que o serviço ''systemd-tmpfiles-setup'' pode ser executado antes dos módulos de dispositivo apropriado for carregado. Neste caso, você pode verificar se o módulo tem um parâmetro para a opção que pretende definir com {{ic|modinfo ''module''}} e ajustar essa opção com um [[Modprobe.d#Configuration|arquivo de configuração em /etc/modprobe.d]]. Caso contrário, você terá que escrever uma [[Udev#About_udev_rules|regra udev]] para ajustar o atributo adequado logo que o dispositivo aparecer.}}
  
 
== Escrevendo arquivos .service personalizados ==
 
== Escrevendo arquivos .service personalizados ==
Line 291: Line 292:
 
=== Manuseando dependências ===
 
=== Manuseando dependências ===
  
Com ''systemd'', dependências podem ser resolvidas através da concepção de arquivos unit correctamente. O caso mais típico é que a unit ''A'' requer a unit ''B'' para ser executado antes da ''A'' ser iniciada. Nesse caso, adicione {{ic|1=Requires=''B''}} e {{ic|1=After=''B''}} para a seção {{ic|[Unit]}} de ''A''. Se a dependência for opcional, então adicione {{ic|1=Wants=''B''}} e {{ic|1=After=''B''}}. Nota que {{ic|1=Wants=}} e {{ic|1=Requires=}} não implicam {{ic|1=After=}}, significando que se {{ic|1=After=}} não for especificado, as duas units serão iniciada em paralelo.
+
Com ''systemd'', dependências podem ser resolvidas através da concepção de arquivos unit corretamente. O caso mais típico é a unit ''A'' requerer a unit ''B'' para ser executada antes da ''A'' ser iniciada. Nesse caso, adicione {{ic|1=Requires=''B''}} e {{ic|1=After=''B''}} para a seção {{ic|[Unit]}} de ''A''. Se a dependência for opcional, então adicione {{ic|1=Wants=''B''}} e {{ic|1=After=''B''}}. Nota que {{ic|1=Wants=}} e {{ic|1=Requires=}} não implicam {{ic|1=After=}}, significando que se {{ic|1=After=}} não for especificado, as duas units serão iniciada em paralelo.
  
Dependências são normalmente colocadas em serviços e não em targets. Por exemplo, o ''network.target'' é puxado por qualquer serviço que configure as interfaces de rede, portanto, ordenando a sua unit personalizada depois é suficiente desde que ''network.target'' for iniciado de qualquer maneira.
+
Dependências são normalmente colocadas em serviços e não em targets. Por exemplo, o ''network.target'' é puxado por qualquer serviço que configure as interfaces de rede, portanto, ordenando a sua unit personalizada depois disso é o bastante desde que ''network.target'' é iniciado de qualquer maneira.
  
 
=== Tipo ===
 
=== Tipo ===
Line 299: Line 300:
 
Há vários tipos diferentes de arranque a considerar quando se escreve um arquivo de serviço personalizado. Isso é definido com o parâmetro {{ic|1=Type=}} na seção {{ic|[Service]}}. Consulte {{ic|man systemd.service}} para uma explicação mais detalhada.
 
Há vários tipos diferentes de arranque a considerar quando se escreve um arquivo de serviço personalizado. Isso é definido com o parâmetro {{ic|1=Type=}} na seção {{ic|[Service]}}. Consulte {{ic|man systemd.service}} para uma explicação mais detalhada.
  
* {{ic|1=Type=simple}} (padrão): ''systemd'' considera que o serviço seja iniciado imediatamente. O processo não tem fork. Não use este tipo se outros serviços carecem ser solicitados neste serviço, a menos que seja soquete ativado.
+
* {{ic|1=Type=simple}} (padrão): ''systemd'' considera que o serviço seja iniciado imediatamente. O processo não tem fork. Não use este tipo se outros serviços carecem ser solicitados neste serviço, a menos que seja socket ativado.
 
* {{ic|1=Type=forking}}: ''systemd'' considera que o serviço iniciou uma vez que os processos forks e o pai sairam. Para daemons clássicos use este tipo, a menos que você saiba que ele não é necessário. Deve especificar {{ic|1=PIDFile=}} tão bem como ''systemd'' possa acompanhar o processo principal.
 
* {{ic|1=Type=forking}}: ''systemd'' considera que o serviço iniciou uma vez que os processos forks e o pai sairam. Para daemons clássicos use este tipo, a menos que você saiba que ele não é necessário. Deve especificar {{ic|1=PIDFile=}} tão bem como ''systemd'' possa acompanhar o processo principal.
 
* {{ic|1=Type=oneshot}}: este é útil para os scripts que fazem um trabalho único e, em seguida, saem. Você pode querer definir {{ic|1=RemainAfterExit=yes}} também para que ''systemd'' ainda considere o serviço como ativo depois que o processo foi encerrado.
 
* {{ic|1=Type=oneshot}}: este é útil para os scripts que fazem um trabalho único e, em seguida, saem. Você pode querer definir {{ic|1=RemainAfterExit=yes}} também para que ''systemd'' ainda considere o serviço como ativo depois que o processo foi encerrado.
 
* {{ic|1=Type=notify}}: idêntico ao {{ic|1=Type=simple}}, mas com a condição de que o servidor irá enviar um sinal para ''systemd'' quando estiver pronto. A implementação de referência para essa notificação é fornecido pelo ''libsystemd-daemon.so''.
 
* {{ic|1=Type=notify}}: idêntico ao {{ic|1=Type=simple}}, mas com a condição de que o servidor irá enviar um sinal para ''systemd'' quando estiver pronto. A implementação de referência para essa notificação é fornecido pelo ''libsystemd-daemon.so''.
* {{ic|1=Type=dbus}}: o serviço é considerado pronto quando o especificado {{ic|BusName}} aparece na barramento do sistema do DBus.
+
* {{ic|1=Type=dbus}}: o serviço é considerado pronto quando o especificado {{ic|BusName}} aparece no barramento do sistema do DBus.
  
 
=== Edição de arquivos units referidos ===
 
=== Edição de arquivos units referidos ===
Line 314: Line 315:
 
After=''new dependency''}}
 
After=''new dependency''}}
  
Em seguida, execute o comandos para que as alterações tenham efeito:
+
Em seguida, execute os comandos para que as alterações tenham efeito:
  
 
  # systemctl daemon-reload
 
  # systemctl daemon-reload
Line 321: Line 322:
 
Alternativamente, você pode copiar o antigo arquivo unit de {{ic|/usr/lib/systemd/system/}} para {{ic|/etc/systemd/system/}} e fazer suas modificações lá. Um arquivo unit em {{ic|/etc/systemd/system/}} sempre sobrepõe a mesma unit em {{ic|/usr/lib/systemd/system/}}. Note que quando a unit original em {{ic|/usr/lib/}} é alterada devido a uma atualização de pacotes, essas alterações não serão aplicadas automaticamente ao seu arquivo unit personalizado em {{ic|/etc/}}. Além disso, você vai ter que reativar manualmente a unit com {{ic|systemctl reenable ''unit''}}. Portanto, é recomendável usar o método ''*.conf'' descrito anteriormente.
 
Alternativamente, você pode copiar o antigo arquivo unit de {{ic|/usr/lib/systemd/system/}} para {{ic|/etc/systemd/system/}} e fazer suas modificações lá. Um arquivo unit em {{ic|/etc/systemd/system/}} sempre sobrepõe a mesma unit em {{ic|/usr/lib/systemd/system/}}. Note que quando a unit original em {{ic|/usr/lib/}} é alterada devido a uma atualização de pacotes, essas alterações não serão aplicadas automaticamente ao seu arquivo unit personalizado em {{ic|/etc/}}. Além disso, você vai ter que reativar manualmente a unit com {{ic|systemctl reenable ''unit''}}. Portanto, é recomendável usar o método ''*.conf'' descrito anteriormente.
  
{{Tip|Você pode usar '''systemd-delta''' para ver quais arquivos units foram sobrescritos e o que exatamente foi alterado.}}
+
{{Dica |Você pode usar '''systemd-delta''' para ver quais arquivos units foram sobrescritos e o que exatamente foi alterado.}}
  
Como os arquivos units referidos serão atualizados ao longo do tempo, use ''systemd-delta'' para a manutenção do sistema.
+
Como os arquivos units referidos serão atualizados ao longo do tempo, use ''systemd-delta'' para a manutenção do sistema.
  
=== Realce de sintaxe para units dentro Vim ===
+
=== Realce de sintaxe para units dentro do Vim ===
  
 
Realce de sintaxe para arquivos unit ''systemd'' dentro do [[Vim]] pode ser habilitado através da instalação do {{Pkg|vim-systemd}} dos [[Official Repositories|repositórios oficiais]].
 
Realce de sintaxe para arquivos unit ''systemd'' dentro do [[Vim]] pode ser habilitado através da instalação do {{Pkg|vim-systemd}} dos [[Official Repositories|repositórios oficiais]].
Line 331: Line 332:
 
== Targets ==
 
== Targets ==
  
''systemd'' uses ''targets'' which serve a similar purpose as runlevels but act a little different. Each ''target'' is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some ''target''s are implemented by inheriting all of the services of another ''target'' and adding additional services to it. There are ''systemd'' ''target''s that mimic the common SystemVinit runlevels so you can still switch ''target''s using the familiar {{ic|telinit RUNLEVEL}} command.
+
''Systemd'' usa ''targets'' que servem a um propósito semelhante, como níveis de execução, mas agem um pouco diferente. Cada ''target'' é nomeada em vez de numerada e destina-se a servir uma finalidade específica com a possibilidade de ter múltiplos ativos ao mesmo tempo. Algumas ''target''s são implementadas por herdar todos os serviços da outra ''target'' e adicionando serviços adicionais a ela. ''target''s ''systemd'' que imitam os níveis de execução SystemVinit comuns para que possa mudar ''target''s usando o comando familiar {{ic|telinit RUNLEVEL}}.
  
=== Get current targets ===
+
=== Obter targets atuais ===
  
The following should be used under ''systemd'' instead of running {{ic|runlevel}}:
+
O comando deve ser no ''systemd'' em vez de executar {{ic|runlevel}}:
  
 
  $ systemctl list-units --type=target
 
  $ systemctl list-units --type=target
  
=== Create custom target ===
+
=== Criar target personalizada ===
  
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific ''systemd'' ''target''. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4. If you make use of those it is suggested that you make a new named ''systemd'' ''target'' as {{ic|/etc/systemd/system/''your target''}} that takes one of the existing runlevels as a base (you can look at {{ic|/usr/lib/systemd/system/graphical.target}} as an example), make a directory {{ic|/etc/systemd/system/''your target''.wants}}, and then symlink the additional services from {{ic|/usr/lib/systemd/system/}} that you wish to enable.
+
Os níveis de execução que são atribuídas uma finalidade específica na instalação vanilla Fedora; 0, 1, 3, 5, e 6; tem um mapeamento 1:1 com uma específica ''target'' ''systemd''. Infelizmente, não há nenhuma boa forma de fazer o mesmo com os níveis de execução definidos pelo usuário, como 2 e 4. Se você fizer uso deles é sugerido que você faça uma nova nomeação ''target'' ''systemd'' como {{ic|/etc/systemd/system/''your target''}} que tem um dos níveis de execução existentes como base (você pode examinar {{ic|/usr/lib/systemd/system/graphical.target}} como um exemplo), crie um diretório {{ic|/etc/systemd/system/''your target''.wants}}, e então symlink o adicional serviço de {{ic|/usr/lib/systemd/system/}} que você deseja ativar.
  
 
=== Tabela de targets ===
 
=== Tabela de targets ===
Line 366: Line 367:
 
=== Alterar target atual ===
 
=== Alterar target atual ===
  
NO ''systemd'' targets estão expostas via ''target units''. Você pode alterá-las assim:
+
No ''systemd'' targets estão expostas via ''target units''. Você pode alterá-las assim:
  
 
  # systemctl isolate graphical.target
 
  # systemctl isolate graphical.target
Line 374: Line 375:
 
=== Alterar target padrão para inicializar ===
 
=== Alterar target padrão para inicializar ===
  
A target padrão é ''default.target'', que tem alias por padrão para ''graphical.target'' (que corresponde ao antigo nível de execução 5).Para alterar o destino padrão na hora da inicialização, adicione um dos seguintes [[kernel parameters]] para seu gerenciador de boot:
+
A target padrão é ''default.target'', que tem alias por padrão para ''graphical.target'' (que corresponde ao antigo nível de execução 5).Para alterar o destino padrão na hora da inicialização, adicione um dos seguintes [[kernel parameters|parâmetros kernel]] para o seu gerenciador de boot:
  
{{Tip|A extensão ''.target'' pode ser deixada de fora.}}
+
{{Dica |A extensão ''.target'' pode ser deixada de fora.}}
  
 
* {{ic|1=systemd.unit=multi-user.target}} (que corresponde ao antigo nível de execução 3),
 
* {{ic|1=systemd.unit=multi-user.target}} (que corresponde ao antigo nível de execução 3),
Line 394: Line 395:
 
== Journal ==
 
== Journal ==
  
''systemd'' tem o seu próprio sistema de registro chamado de o journal e, portanto, a execução de um daemon syslog não é mais necessário. Para ler o log, utilize:
+
''systemd'' tem o seu próprio sistema de registro chamado de o journal e, portanto, a execução de uma daemon syslog não é mais necessário. Para ler o registro, utilize:
  
 
  # journalctl
 
  # journalctl
  
Por padrão (quando {{ic|1=Storage=}} é definido para {{ic|auto}} em {{ic|/etc/systemd/journald.conf}}), o journal escreve para {{ic|/var/log/journal/}}. O diretório {{ic|/var/log/journal/}} faz parte do pacote ''systemd''. Se você ou algum programa apagar esse diretório, systemd '''não''' irá recriá-lo automaticamente; no entanto, ele será recriado durante a próxima atualização do pacote systemd. Até então, os registros serão gravados {{ic|/run/systemd/journal}}, e os registros se perderão na reinicialização.
+
Por padrão (quando {{ic|1=Storage=}} é definido para {{ic|auto}} em {{ic|/etc/systemd/journald.conf}}), o journal escreve para {{ic|/var/log/journal/}}. O diretório {{ic|/var/log/journal/}} faz parte do pacote ''systemd''. Se você ou algum programa excluir esse diretório, systemd '''não''' irá recriá-lo automaticamente; no entanto, ele será recriado durante a próxima atualização do pacote systemd. Até então, os registros serão gravados em {{ic|/run/systemd/journal}}, e os registros se perderão na reinicialização.
  
{{Tip|Se {{ic|/var/log/journal/}} reside em um sistema de arquivo [[btrfs]] você deve considerar a desativação [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] do diretório:
+
{{Dica |Se {{ic|/var/log/journal/}} reside em um sistema de arquivo [[btrfs]] você deve considerar a desativação [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] do diretório:
 
  # chattr +C /var/log/journal
 
  # chattr +C /var/log/journal
 
}}
 
}}
Line 420: Line 421:
 
  # journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac
 
  # journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac
  
desde que a inicialização anterior aconteceu hoje. Esteja ciente que, se houver muitas mensagens para o dia atual, a saída deste comando pode ser atrasada por algum tempo.
+
desde que a inicialização anterior aconteceu hoje. Esteja ciente que, se houver muitas mensagens para o dia atual, a saída deste comando pode ser atrasada por um tempo.
{{note|Isso precisa ser corrigido uma vez que 206 regiões.  {{ic|journalctl -b}} agora assume argumentos como {{ic|-0}} para a última inicialização ou uma ID de inicialização. E.x. {{ic|journalctl -b -3}} vai mostrar todas as mensagens da quarta para a última inicialização.}}
+
{{Nota |Isso precisa ser corrigido uma vez que 206 regiões.  {{ic|journalctl -b}} agora assume argumentos como {{ic|-0}} para a última inicialização ou uma ID de inicialização. Ex. {{ic|journalctl -b -3}} vai mostrar todas as mensagens da quarta para a última inicialização.}}
  
 
Acompanhe as novas mensagens:
 
Acompanhe as novas mensagens:
Line 427: Line 428:
 
  # journalctl -f
 
  # journalctl -f
  
Mostrar todas as mensagens por um executável específico:
+
Mostra todas as mensagens por um executável específico:
  
 
  # journalctl /usr/lib/systemd/systemd
 
  # journalctl /usr/lib/systemd/systemd
  
Mostrar todas as mensagens através de um processo específico:
+
Mostra todas as mensagens através de um processo específico:
  
 
  # journalctl _PID=1
 
  # journalctl _PID=1
  
Mostrar todas as mensagens de uma unit específica:
+
Mostra todas as mensagens de uma unit específica:
  
 
  # journalctl -u netcfg
 
  # journalctl -u netcfg
  
Consulte {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}}, ou Lennert's [http://0pointer.de/blog/projects/journalctl.html mensagem de blog] para detalhes.
+
Consulte {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}}, ou [http://0pointer.de/blog/projects/journalctl.html mensagem do blog] de Lennert para detalhes.
  
 
=== Tamanho limite do Journal ===
 
=== Tamanho limite do Journal ===
  
Se o journal é persistente (não volátil), seu tamanho limite é definido para um valor padrão de 10% do tamanho do respectivo sistema de arquivos. Por exemplo, com o {{ic|/var/log/journal}} localizado em uma partição raiz de 50 GiB isso levaria a 5 GiB de dados do journal. O tamanho máximo do journal persistente pode ser controlado pelo {{ic|SystemMaxUse}} em {{ic|/etc/systemd/journald.conf}}, então para limitá-lo, por exemplo, a 50 MiB descomente e edite a linha correspondente a:
+
Se o journal é persistente (não volátil), seu tamanho limite é definido para um valor padrão de 10% do tamanho do respectivo sistema de arquivos. Por exemplo, com o {{ic|/var/log/journal}} localizado em uma partição root de 50 GiB isso levaria a 5 GiB de dados do journal. O tamanho máximo do journal persistente pode ser controlado pelo {{ic|SystemMaxUse}} em {{ic|/etc/systemd/journald.conf}}, então para limitá-lo, por exemplo, a 50 MiB descomente e edite a linha correspondente a:
  
 
  SystemMaxUse=50M
 
  SystemMaxUse=50M
Line 451: Line 452:
 
=== Journald em conjunto com o syslog ===
 
=== Journald em conjunto com o syslog ===
  
Compatibilidade com implementações syslog clássico é fornecida através do soquete {{ic|/run/systemd/journal/syslog}}, para o qual todas as mensagens são encaminhadas. Para fazer funcionar o daemon syslog com o journal, tem de vincular a este soquete em vez de {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). O pacote {{Pkg|syslog-ng}} nos repositórios fornece automaticamente a configuração necessária.
+
Compatibilidade com implementações do syslog clássico é fornecida através da socket {{ic|/run/systemd/journal/syslog}}, para o qual todas as mensagens são encaminhadas. Para fazer funcionar a daemon syslog com o journal, tem de vincular a este socket em vez de {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ official announcement]). O pacote {{Pkg|syslog-ng}} nos repositórios fornece automaticamente a configuração necessária.
  
 
  # systemctl enable syslog-ng
 
  # systemctl enable syslog-ng
Line 461: Line 462:
 
=== Desligar/reiniciar demora um longo tempo===
 
=== Desligar/reiniciar demora um longo tempo===
  
Se o processo de encerramento tem um tempo muito longo (ou parece congelar) mais provavelmente um serviço que não encerra é o responsável. ''Systemd'' espera um tempo para cada serviço encerrar antes de tentar matá-lo. Para descobrir se você foi afetado, consulte [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].
+
Se o processo de encerramento tem um tempo muito longo (ou parece congelar) mais provavelmente um serviço que não encerra é o responsável. ''Systemd'' espera um tempo para cada serviço terminar antes de tentar matá-lo. Para descobrir se você foi afetado, consulte [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually this article].
  
 
=== Processos de curta duração não parecem registrar qualquer saída ===
 
=== Processos de curta duração não parecem registrar qualquer saída ===
  
Se {{ic|journalctl -u foounit}} não mostra nenhuma saída para um serviço de curta duração, veja o PID em vez disso. Por exemplo, se {{ic|systemd-modules-load.service}} falha, e {{ic|systemctl status systemd-modules-load}} mostra que executou com PID 123, então você talvez possa ver uma saída no journal por esse PID, ou seja, {{ic|journalctl -b _PID=123}}. Campos de metadados para o journal como _SYSTEMD_UNIT e _COMM são coletados de forma assíncrona e invocam o diretório {{ic|/proc}} para o processo existente. A solução deste problema requer fixar o kernel para fornecer esses dados através de uma conexão de soquete, semelhante ao SCM_CREDENTIALS.
+
Se {{ic|journalctl -u foounit}} não mostra nenhuma saída para um serviço de curta duração, veja o PID em vez disso. Por exemplo, se {{ic|systemd-modules-load.service}} falha, e {{ic|systemctl status systemd-modules-load}} mostra que executou com PID 123, então você talvez possa ver uma saída no journal por esse PID, ou seja, {{ic|journalctl -b _PID=123}}. Campos de metadados para o journal como _SYSTEMD_UNIT e _COMM são coletados de forma assíncrona e invocam o diretório {{ic|/proc}} para o processo existente. A solução deste problema requer fixar o kernel para fornecer esses dados através de uma conexão de socket, semelhante ao SCM_CREDENTIALS.
  
 
=== Diagnosticar problemas de inicialização ===
 
=== Diagnosticar problemas de inicialização ===
Line 485: Line 486:
 
  # /usr/lib/systemd/systemd-sysctl
 
  # /usr/lib/systemd/systemd-sysctl
  
Como antes, você também precisa "unlimit" o tamanho dos arquivos de núcleo no shell:
+
Como antes, você também precisa o tamanho "unlimit" dos arquivos de núcleo no shell:
 
  $ ulimit -c unlimited
 
  $ ulimit -c unlimited
  
Consulte [http://www.freedesktop.org/software/systemd/man/sysctl.d.html sysctl.d] e [https://www.kernel.org/doc/Documentation/sysctl/kernel.txt the documentation for /proc/sys/kernel] para mais informações.
+
Consulte [http://www.freedesktop.org/software/systemd/man/sysctl.d.html sysctl.d] e [https://www.kernel.org/doc/Documentation/sysctl/kernel.txt a documentação para /proc/sys/kernel] para mais informações.
  
== See also ==
+
== Consulte também ==
  
 
*[http://www.freedesktop.org/wiki/Software/systemd Official web site]
 
*[http://www.freedesktop.org/wiki/Software/systemd Official web site]

Revision as of 17:45, 26 August 2013

Sumário help replacing me
Aborda como instalar e configurar o systemd.
Relacionados
systemd/User
systemd/Services
systemd FAQ
init Rosetta
Daemons List
udev
Improve Boot Performance

De project web page:

Systemd é um sistema e gerenciador de serviços para Linux, compatível com os scripts de inicializações SysV e LS. Systemd fornece recursos de paralelização agressivos, usa socket e ativação D-Bus para iniciar serviços, oferece o início de daemons on-demand, mantém o registro de processos usando grupos de controle Linux, suporte snapshotting e restauração do estado do sistema, preserva pontos de montagens e automontagens e implementa uma lógica de controle elaborado transacional baseada em dependência de serviço.
Nota: Para uma explicação detalhada do porquê Arch migrou para o systemd, consulte esta mensagem do fórum internacional.

Migração do SysVinit/initscripts

Nota:

Considerações antes de mudar

  • Faça algumas leituras sobre systemd.
  • Note que systemd tem um sistema journal que substitue syslog, embora os dois podem coexistir. Consulte #Journal.
  • Embora o systemd possa subtituir algumas das funcionabilidades do cron, acpid, ou xinetd, não há necessidade de deixar de usar as daemons tradicionais, a menos que você queira.
  • Interativo initscripts não está trabalhando com systemd. Em particular, netcfg-menu não pode ser usado no sistema de inicialização (FS#31377).

Procedimento de instalação

  1. Instalar systemd dos repositórios oficiais.
  2. Acrescente ao seu parâmetros kernel : init=/usr/lib/systemd/systemd.
  3. Uma vez concluído, você pode habilitar todos os serviços desejados, através do uso systemctl enable service_name (equivalente a inclusão na array DAEMONS. Novos nomes podem ser encontrados em Lista de Daemons).
  4. Reinicie seu sistema e verifique se systemd está atualmente ativo emitindo o seguinte comando: cat /proc/1/comm. Isso deve retornar a string systemd.
  5. Verifique se o seu hostname está configurado corretamente com systemd: hostnamectl set-hostname myhostname ou /etc/hostname.
  6. Proceda para remover initscripts e sysvinit de seu sistema e instale systemd-sysvcompat.
  7. Opcionalmente, remova o parâmetro init=/usr/lib/systemd/systemd. Não é mais necessário desde que systemd-sysvcompat fornece um symlink para systemd.

Informações complementares

  • Se você tem quiet em seu parâmetro kernel, talvez queira removê-lo nos seus primeiros boots com systemd para auxiliar na identificação de eventuais problemas durante a inicialização.
  • Não é necessário adicionar o usuário aos grupos (sys, disk, lp, network, video, audio, optical, storage, scanner, power, etc.) para a maioria dos casos de uso com systemd. Os grupos podem até causar algumas quebras de funcionalidades. Por exemplo, o grupo audio vai quebrar a troca rápida de usuário e permite que os aplicativos bloqueiem programas. Cada registro PAM fornece uma sessão de logind, no qual para uma sessão local lhe dará permissões via POSIX ACLs em dispositivos audio/video, e permite certas operações como montagem de armazenamento removível via udisks.

Uso básico systemctl

O principal comando usado para introspecção e controle systemd é systemctl. Alguns de seus usos são examinando o estado do sistema e gerenciando o sistema e serviços. Consulte man 1 systemctl para mais detalhes.

Dica: Você pode usar todos os comandos systemctl com o -H user@host que muda para controlar uma instância systemd em uma máquina remota. Isso usará SSH para conectar-se uma instância remota systemd.
Nota: systemadm é a interface gráfica oficial para systemctl. é fornecida pelo pacote systemd-ui-gitAUR do AUR.

Analisando o estado do sistema

Lista units executadas:

$ systemctl

ou:

$ systemctl list-units

Lista units que falharam::

$ systemctl --failed

Os arquivos units disponíveis podem ser vistos em /usr/lib/systemd/system/ e /etc/systemd/system/ (este último tem precedência). Você pode ver uma lista dos arquivos units instalados com:

$ systemctl list-unit-files

Usando units

As units podem ser, por exemplo, serviços (.service), pontos de montagem (.mount), dispositivos (.device) ou sockets (.socket).

Quando usa systemctl, você geralmente tem que especificar o nome completo do arquivo unit, incluindo o sufixo, por exemplo sshd.socket. No entanto, existem algumas formas curtas de especificar a unit nos seguintes comandos systemctl:

  • Se você não especificar o sufixo, systemctl assumirá .service. Por exemplo, netcfg e netcfg.service são equivalentes.
  • Os pontos de montagem serão automaticamente convertidos para a unit .mount adequada. Por exemplo, especificando /home equivale a home.mount.
  • Similar aos pontos de montagem, dispositivos são automaticamente convertido para a unit .device adequada, portanto, especificando /dev/sda2 equivale a dev-sda2.device.

Consulte man systemd.unit para detalhes.


Ativa uma unit imediatamente:

# systemctl start unit

Desativa uma unit imediatamente:

# systemctl stop unit

Reinicia uma unit:

# systemctl restart unit

Peça uma unit para recarregar sua configuração:

# systemctl reload unit

Mostra o estado de uma unit, inclusive se estiver em execução ou não:

$ systemctl status unit

Verifica se a unit já está habilitada ou não:

$ systemctl is-enabled unit

Habilita uma unit para ser iniciada na inicialização:

# systemctl enable unit
Nota: Serviços sem uma seção [Install] são geralmente chamados por outros serviços automaticamente. Se você precisa instalá-los manualmente, use o seguinte comando, substituindo foo com o nome do serviço.
# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/

Desativa uma unit para não iniciar durante a inicialização:

# systemctl disable unit

Mostra a página de manual associado a uma unit (tem que ser suportado pelo arquivo da unit):

$ systemctl help unit

Recarrega o systemd, scaneando por units novas e modificadas:

# systemctl daemon-reload

O gerenciamento de energia

polkit é necessário para o gerenciamento de energia. Se você está numa sessão de usuário local systemd-logind e nenhuma outra sessão está ativa, os seguintes comandos funcionarão sem privilégios root. Se não (por exemplo, porque outro usuário está conectado em um tty), systemd irá automaticamente pedir a senha de root.

Desliga e reinicia o sistema:

$ systemctl reboot

Desliga e encerra o sistema:

$ systemctl poweroff

Suspende o sistema:

$ systemctl suspend

Coloca o sistema em modo de hibernação:

$ systemctl hibernate

Coloca o sistema em modo de suspensão :

$ systemctl hybrid-sleep

Executando Gerenciadores de Display no systemd

Merge-arrows-2.pngThis article or section is a candidate for merging with Display Manager.Merge-arrows-2.png

Notes: Temos artigo separado, esta seção deve ser mudada para lá para manter as coisas em um só lugar. (Discuss in Talk:Systemd (Português)#)

Para habilitar a autenticação gráfica, execute o seu daemon de Display Manager preferido (ex. KDM). No momento, existem arquivos de serviço para GDM, KDM, SLiM, XDM, LXDM, LightDM, e SDDMAUR.

# systemctl enable kdm

Isso deve funcionar. Se não, você pode ter que definir o default.target manualmente ou de uma velha instalação:

# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

Basta apagar o link simbólico e systemd usará seu default.target (ex. graphical.target).

# rm /etc/systemd/system/default.target

Usando systemd-logind

A fim de verificar o estado de sua sessão de usuário, você pode usar loginctl. Todas ações PolicyKit como suspender o sistema ou montar unidades externas irão funcionar.

$ loginctl show-session $XDG_SESSION_ID

Configuração nativa

Nota: Você talvez precise criar esses arquivos. Todos os arquivos devem ter permissões 644 e propriedade root:root.

Console virtual

Tango-edit-cut.pngThis section is being considered for removal.Tango-edit-cut.png

Reason: Não estritamente relacionados, tentando remover a seção #Native configuration inteiramente. (Discuss in Talk:Systemd (Português)#Duplication of content in Native configuration section)

O console virtual (mapeamento de teclado, fonte do console e mapa do console) é configurado em /etc/vconsole.conf ou utilizando a ferramenta localectl.

Para mais informação, consulte fontes do console e keymaps.

Relógio do hardware

Merge-arrows-2.pngThis article or section is a candidate for merging with Time.Merge-arrows-2.png

Notes: Esta seção foi adicionada antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão. (Discuss in Talk:Systemd (Português)#Duplication of content in Native configuration section)

systemd usará UTC para o relógio do hardware por padrão.

Dica: É aconselhável ter Network Time Protocol daemon correndo para manter a hora do sistema sincronizado com a hora da Internet e o relógio do hardware.

Relógio do hardware em localtime

Se quiser alterar o relógio de hardware para usar horário local (não recomendado), faça:

# timedatectl set-local-rtc true

Se quiser reverter para o relógio do hardware estando em UTC, faça:

# timedatectl set-local-rtc false

Fique avisado que, se o relógio do hardware está definido para localtime, lidar com o horário de verão é uma confusão(há muito mais do que isso).

Uma razão para permitir que o RTC esteja em hora local é permitir dual boot com o Windows (que usa localtime). No entanto, o Windows é capaz de lidar com a RTC iniciando em UTC, com um simples correção de registro.

Para mais informação, consulte Time.

Módulos do kernel

Tango-edit-cut.pngThis section is being considered for removal.Tango-edit-cut.png

Reason: Não estritamente relacionados, tentando remover a seção #Native configuration inteiramente. (Discuss in Talk:Systemd (Português)#Duplication of content in Native configuration section)

Consulte Kernel modules#Configuration.

Montagens de sistemas de arquivos

Merge-arrows-2.pngThis article or section is a candidate for merging with File Systems.Merge-arrows-2.png

Notes: Esta seção foi adicionada antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão. (Discuss in Talk:Systemd (Português)#Duplication of content in Native configuration section)

A configuração padrão será automaticamente fsck e montará sistemas de arquivos antes de iniciar os serviços que eles precisam para serem montados. Por exemplo, systemd automaticamente garante que montagens de sistemas de arquivos remotos como NFS ou Samba são somente iniciados depois que a rede for configurada. Portanto, montagens de sistema de arquivos local e remoto especificadas em /etc/fstab} devem funcionar.

Consulte man 5 systemd.mount por detalhes.

Automontagem

Merge-arrows-2.pngThis article or section is a candidate for merging with fstab.Merge-arrows-2.png

Notes: Esta seção foi adicionada antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão. (Discuss in Talk:Systemd (Português)#Duplication of content in Native configuration section)

Se você tem uma partição /home grande, talvez seja melhor permitir serviços que não dependem da /home para iniciar enquanto /home é verificada pelo fsck. Isto pode ser feito adicionando as seguintes opções em /etc/fstab na entrada de sua partição /home:

noauto,x-systemd.automount

Isso irá fsck e montar /home ao acessada pela primeira vez, e o kernel irá reter todos os acessos de arquivo para /home até que esteja pronto.

Nota: Isso vai fazer seu sistema de arquivo /home tipo autofs, seja ignorado pelo mlocate por padrão. A aceleração de automontagem /home pode não ser mais do que um ou dois segundos, dependendo do seu sistema, de modo que este truque possa não valer a pena.

O mesmo se aplica para montagens de sistemas de arquivos remotos. Se você quer que eles sejam montados apenas no acesso, você vai precisar usar o parâmetro noauto,x-systemd.automount. Além disso, você pode usar a opção x-systemd.device-timeout=# para especificar um limite no caso do recurso de rede não está disponível.

Se você tem sistemas de arquivos criptografados com arquivo chaves, também pode adicionar o parâmetro noauto para as entradas correspondentes em /etc/crypttab. Então systemd não vai abrir o dispositivo criptografado no boot, mas espera até que ele seja realmente acessado e então automaticamente o abre com o arquivo chave especificado antes de montá-lo. Isso pode economizar alguns segundos na inicialização, se você estiver usando um dispositivo RAID criptografado por exemplo, porque o systemd não tem que esperar para o dispositivo se tornar disponível. Por exemplo:

/etc/crypttab
data /dev/md0 /root/key noauto

LVM

Merge-arrows-2.pngThis article or section is a candidate for merging with LVM.Merge-arrows-2.png

Notes: Esta seção foi adicionada aqui antes do systemd tornar-se o sistema de inicialização padrão. Removida após a fusão. (Discuss in Talk:Systemd (Português)#Duplication of content in Native configuration section)

Se você não tiver volumes LVM ativados via o initramfs, habilite o serviço lvm-monitoring, que é fornecido pelo pacote lvm2.

Gerenciamento de energia ACPI

Tango-edit-cut.pngThis section is being considered for removal.Tango-edit-cut.png

Reason: Não estritamente relacionados, tentando remover a seção #Native configuration inteiramente. (Discuss in Talk:Systemd (Português)#Duplication of content in Native configuration section)

Consulte Power Management.

Arquivos temporários

Template:Moveto

systemd-tmpfiles usa arquivos de configuração em /usr/lib/tmpfiles.d/ e /etc/tmpfiles.d/ para descrever a criação, limpeza e remoção de arquivos e diretórios voláteis e temporários que normalmente residem em diretórios como /run ou /tmp. Cada arquivo de configuração é chamado no estilo /etc/tmpfiles.d/program.conf. Isso também irá substituir todos os arquivos em /usr/lib/tmpfiles.d/ com o mesmo nome.

tmpfiles normalmente são fornecidos em conjunto com arquivos de serviços para criar diretórios que deverão existir por certas daemons. Por exemplo a daemon Samba espera que o diretório /run/samba exista e tenha as permissões corretas. Assim, o pacote samba vem com esta configuração:

/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root

tmpfiles também pode ser usado para escrever os valores em determinados arquivos na inicialização. Por exemplo, se você usa /etc/rc.local para desativar ativação de dispositivos USB com echo USBE > /proc/acpi/wakeup, você pode usar o seguinte tmpfile:

/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE

Consulte man 5 tmpfiles.d para detalhes.

Nota: Este método pode não funcionar para definir as opções em /sys uma vez que o serviço systemd-tmpfiles-setup pode ser executado antes dos módulos de dispositivo apropriado for carregado. Neste caso, você pode verificar se o módulo tem um parâmetro para a opção que pretende definir com modinfo module e ajustar essa opção com um arquivo de configuração em /etc/modprobe.d. Caso contrário, você terá que escrever uma regra udev para ajustar o atributo adequado logo que o dispositivo aparecer.

Escrevendo arquivos .service personalizados

A sintaxe do systemd arquivos unit é inspirado pela Especificações de Entrada dos arquivos .desktop XDG Desktop, que são, por sua vez inspirado pelo .ini Microsoft Windows.

Consulte systemd/Services para mais exemplos.

Manuseando dependências

Com systemd, dependências podem ser resolvidas através da concepção de arquivos unit corretamente. O caso mais típico é a unit A requerer a unit B para ser executada antes da A ser iniciada. Nesse caso, adicione Requires=B e After=B para a seção [Unit] de A. Se a dependência for opcional, então adicione Wants=B e After=B. Nota que Wants= e Requires= não implicam After=, significando que se After= não for especificado, as duas units serão iniciada em paralelo.

Dependências são normalmente colocadas em serviços e não em targets. Por exemplo, o network.target é puxado por qualquer serviço que configure as interfaces de rede, portanto, ordenando a sua unit personalizada depois disso é o bastante desde que network.target é iniciado de qualquer maneira.

Tipo

Há vários tipos diferentes de arranque a considerar quando se escreve um arquivo de serviço personalizado. Isso é definido com o parâmetro Type= na seção [Service]. Consulte man systemd.service para uma explicação mais detalhada.

  • Type=simple (padrão): systemd considera que o serviço seja iniciado imediatamente. O processo não tem fork. Não use este tipo se outros serviços carecem ser solicitados neste serviço, a menos que seja socket ativado.
  • Type=forking: systemd considera que o serviço iniciou uma vez que os processos forks e o pai sairam. Para daemons clássicos use este tipo, a menos que você saiba que ele não é necessário. Deve especificar PIDFile= tão bem como systemd possa acompanhar o processo principal.
  • Type=oneshot: este é útil para os scripts que fazem um trabalho único e, em seguida, saem. Você pode querer definir RemainAfterExit=yes também para que systemd ainda considere o serviço como ativo depois que o processo foi encerrado.
  • Type=notify: idêntico ao Type=simple, mas com a condição de que o servidor irá enviar um sinal para systemd quando estiver pronto. A implementação de referência para essa notificação é fornecido pelo libsystemd-daemon.so.
  • Type=dbus: o serviço é considerado pronto quando o especificado BusName aparece no barramento do sistema do DBus.

Edição de arquivos units referidos

Para editar um arquivo unit fornecido por um pacote, você pode criar um diretório chamado /etc/systemd/system/unit.d/ por exemplo /etc/systemd/system/httpd.service.d/ e coloque os arquivos *.conf lá para substituir ou adicionar novas opções. Systemd irá analisar esses arquivos *.conf e aplicá-los no topo da unit original. Por exemplo, se você simplesmente quiser adicionar uma dependência adicional para a unit, você pode criar o seguinte arquivo:

/etc/systemd/system/unit.d/customdependency.conf
[Unit]
Requires=new dependency
After=new dependency

Em seguida, execute os comandos para que as alterações tenham efeito:

# systemctl daemon-reload
# systemctl restart unit

Alternativamente, você pode copiar o antigo arquivo unit de /usr/lib/systemd/system/ para /etc/systemd/system/ e fazer suas modificações lá. Um arquivo unit em /etc/systemd/system/ sempre sobrepõe a mesma unit em /usr/lib/systemd/system/. Note que quando a unit original em /usr/lib/ é alterada devido a uma atualização de pacotes, essas alterações não serão aplicadas automaticamente ao seu arquivo unit personalizado em /etc/. Além disso, você vai ter que reativar manualmente a unit com systemctl reenable unit. Portanto, é recomendável usar o método *.conf descrito anteriormente.

Dica: Você pode usar systemd-delta para ver quais arquivos units foram sobrescritos e o que exatamente foi alterado.

Como os arquivos units referidos serão atualizados ao longo do tempo, use systemd-delta para a manutenção do sistema.

Realce de sintaxe para units dentro do Vim

Realce de sintaxe para arquivos unit systemd dentro do Vim pode ser habilitado através da instalação do vim-systemd dos repositórios oficiais.

Targets

Systemd usa targets que servem a um propósito semelhante, como níveis de execução, mas agem um pouco diferente. Cada target é nomeada em vez de numerada e destina-se a servir uma finalidade específica com a possibilidade de ter múltiplos ativos ao mesmo tempo. Algumas targets são implementadas por herdar todos os serviços da outra target e adicionando serviços adicionais a ela. Há targets systemd que imitam os níveis de execução SystemVinit comuns para que possa mudar targets usando o comando familiar telinit RUNLEVEL.

Obter targets atuais

O comando deve ser no systemd em vez de executar runlevel:

$ systemctl list-units --type=target

Criar target personalizada

Os níveis de execução que são atribuídas uma finalidade específica na instalação vanilla Fedora; 0, 1, 3, 5, e 6; tem um mapeamento 1:1 com uma específica target systemd. Infelizmente, não há nenhuma boa forma de fazer o mesmo com os níveis de execução definidos pelo usuário, como 2 e 4. Se você fizer uso deles é sugerido que você faça uma nova nomeação target systemd como /etc/systemd/system/your target que tem um dos níveis de execução existentes como base (você pode examinar /usr/lib/systemd/system/graphical.target como um exemplo), crie um diretório /etc/systemd/system/your target.wants, e então symlink o adicional serviço de /usr/lib/systemd/system/ que você deseja ativar.

Tabela de targets

Modo de execução SysV systemd Target Notas
0 runlevel0.target, poweroff.target Interrrompe o sistema.
1, s, único runlevel1.target, rescue.target Modo de usuário único.
2, 4 runlevel2.target, runlevel4.target, multi-user.target Níveis de execução User-defined/Site-specific. Por padrão, idêntico ao 3.
3 runlevel3.target, multi-user.target Multi-usuário, não-gráfico. Os usuários geralmente podem acessar através de múltiplos consoles ou via rede.
5 runlevel5.target, graphical.target Multi-usuário, gráfico. Normalmente tem todos os serviços do nível de execução 3, mais um login gráfico.
6 runlevel6.target, reboot.target Reiniciar
emergência emergency.target Shell de emergência

Alterar target atual

No systemd targets estão expostas via target units. Você pode alterá-las assim:

# systemctl isolate graphical.target

Isso só vai mudar a target atual, e não tem nenhum efeito na próxima inicialização. É equivalente aos comandos como telinit 3 ou telinit 5 no Sysvinit.

Alterar target padrão para inicializar

A target padrão é default.target, que tem alias por padrão para graphical.target (que corresponde ao antigo nível de execução 5).Para alterar o destino padrão na hora da inicialização, adicione um dos seguintes parâmetros kernel para o seu gerenciador de boot:

Dica: A extensão .target pode ser deixada de fora.
  • systemd.unit=multi-user.target (que corresponde ao antigo nível de execução 3),
  • systemd.unit=rescue.target (que corresponde ao antigo nível de execução 1).

Alternativamente, você pode deixar o gerenciador de boot sozinho e alterar default.target. Pode ser feito usando o systemctl:

# systemctl enable multi-user.target

O efeito desse comando é emitido pelo systemctl; um symlink para a nova target padrão é feita em /etc/systemd/system/default.target. Isso funciona se, e somente se:

[Install]
Alias=default.target

está no arquivo de configuração da target. Atualmente, multi-user.target e graphical.target ambos têm isso.

Journal

systemd tem o seu próprio sistema de registro chamado de o journal e, portanto, a execução de uma daemon syslog não é mais necessário. Para ler o registro, utilize:

# journalctl

Por padrão (quando Storage= é definido para auto em /etc/systemd/journald.conf), o journal escreve para /var/log/journal/. O diretório /var/log/journal/ faz parte do pacote systemd. Se você ou algum programa excluir esse diretório, systemd não irá recriá-lo automaticamente; no entanto, ele será recriado durante a próxima atualização do pacote systemd. Até então, os registros serão gravados em /run/systemd/journal, e os registros se perderão na reinicialização.

Dica: Se /var/log/journal/ reside em um sistema de arquivo btrfs você deve considerar a desativação Copy-on-Write do diretório:
# chattr +C /var/log/journal

Filtrando saída

journalctl permite filtrar a saída por campos específicos.

Exemplos:

Mostra todas as mensagens desta inicialização:

# journalctl -b

No entanto, muitas vezes alguém está interessado em mensagens não do atual, mas do boot anterior (por exemplo, se uma falha irrecuperável do sistema aconteceu). Atualmente, este recurso não está implementado, embora foi uma discussão em systemd-devel@lists.freedesktop.org (Setembro/Outubro 2012).

Como alternativa você pode usar no momento:

# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac

desde que a inicialização anterior aconteceu hoje. Esteja ciente que, se houver muitas mensagens para o dia atual, a saída deste comando pode ser atrasada por um tempo.

Nota: Isso precisa ser corrigido uma vez que 206 regiões. journalctl -b agora assume argumentos como -0 para a última inicialização ou uma ID de inicialização. Ex. journalctl -b -3 vai mostrar todas as mensagens da quarta para a última inicialização.

Acompanhe as novas mensagens:

# journalctl -f

Mostra todas as mensagens por um executável específico:

# journalctl /usr/lib/systemd/systemd

Mostra todas as mensagens através de um processo específico:

# journalctl _PID=1

Mostra todas as mensagens de uma unit específica:

# journalctl -u netcfg

Consulte man 1 journalctl, man 7 systemd.journal-fields, ou mensagem do blog de Lennert para detalhes.

Tamanho limite do Journal

Se o journal é persistente (não volátil), seu tamanho limite é definido para um valor padrão de 10% do tamanho do respectivo sistema de arquivos. Por exemplo, com o /var/log/journal localizado em uma partição root de 50 GiB isso levaria a 5 GiB de dados do journal. O tamanho máximo do journal persistente pode ser controlado pelo SystemMaxUse em /etc/systemd/journald.conf, então para limitá-lo, por exemplo, a 50 MiB descomente e edite a linha correspondente a:

SystemMaxUse=50M

Consulte man journald.conf para mais informações.

Journald em conjunto com o syslog

Compatibilidade com implementações do syslog clássico é fornecida através da socket /run/systemd/journal/syslog, para o qual todas as mensagens são encaminhadas. Para fazer funcionar a daemon syslog com o journal, tem de vincular a este socket em vez de /dev/log (official announcement). O pacote syslog-ng nos repositórios fornece automaticamente a configuração necessária.

# systemctl enable syslog-ng

Um bom tutorial journalctl está aqui.

Solução de problemas

Desligar/reiniciar demora um longo tempo

Se o processo de encerramento tem um tempo muito longo (ou parece congelar) mais provavelmente um serviço que não encerra é o responsável. Systemd espera um tempo para cada serviço terminar antes de tentar matá-lo. Para descobrir se você foi afetado, consulte this article.

Processos de curta duração não parecem registrar qualquer saída

Se journalctl -u foounit não mostra nenhuma saída para um serviço de curta duração, veja o PID em vez disso. Por exemplo, se systemd-modules-load.service falha, e systemctl status systemd-modules-load mostra que executou com PID 123, então você talvez possa ver uma saída no journal por esse PID, ou seja, journalctl -b _PID=123. Campos de metadados para o journal como _SYSTEMD_UNIT e _COMM são coletados de forma assíncrona e invocam o diretório /proc para o processo existente. A solução deste problema requer fixar o kernel para fornecer esses dados através de uma conexão de socket, semelhante ao SCM_CREDENTIALS.

Diagnosticar problemas de inicialização

Inicialização desses parâmetros na linha de comando do kernel: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

More Debugging Information

Desativando despejos de memória de aplicativos journaling

Para voltar os arquivos normais de despejo de memória, edite o seguinte arquivo de forma que sobrescreva os ajustes de /lib/sysctl.d/:

/etc/sysctl.d/49-coredump.conf
kernel.core_pattern = core
kernel.core_uses_pid = 0

Então execute:

# /usr/lib/systemd/systemd-sysctl

Como antes, você também precisa o tamanho "unlimit" dos arquivos de núcleo no shell:

$ ulimit -c unlimited

Consulte sysctl.d e a documentação para /proc/sys/kernel para mais informações.

Consulte também