# systemd (Português)

Artigos relacionados

- systemd/User
- 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.

## 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[broken link: archived in aur-mirror] 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

This article or section is a candidate for merging with Display Manager.

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

    # 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

## Arquivos temporários

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[broken link: invalid section]. 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[broken link: invalid section] é inspirado pela Especificações de Entrada dos arquivos .desktop XDG Desktop, que são, por sua vez inspirado pelo .ini Microsoft Windows.

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

- Official web site
- Wikipedia article
- Manual pages
- systemd optimizations
- FAQ
- Tips and tricks
- systemd for Administrators (PDF)
- About systemd on Fedora Project
- How to debug systemd problems
- Two part introductory article in The H Open magazine.
- Lennart's blog story
- Status update
- Status update2
- Status update3
- Most recent summary
- Fedora's SysVinit to systemd cheatsheet

Categories:

- Daemons and system services (Português)
- Boot process (Português)

Hidden categories:

- Pages with broken package links
- Pages or sections flagged with Template:Merge
- Pages with broken section links