Traduções: English - Español - Français - 한국어 - Russian - Português (Brasil) - 简体中文


systemd - gerenciador de sistema e serviços

== Introdução ==

systemd é um gerenciador de sistema e serviços para Linux. systemd é compatível com os scripts de inicialização SysV e LSB. Pode funcionar como um substituto para o sysvinit. Systemd

Consulte a página upstream para obter mais informações.

Instalando e Testando

Systemd foi incluído no Debian wheezy como uma prévia tecnológica. Certifique-se de que está usando Debian jessie ou mais recente para obter uma versão recente do systemd.

Instalação

Para instalar o systemd:

# apt-get update
# apt-get install systemd

Isso irá instalar os pacotes do systemd, mas não configurará o systemd como seu sistema de inicialização.

Configurando para teste

Para testar systemd antes de mudar para ele por padrão, você pode adicionar o seguinte parâmetro de inicialização ao kernel:

init=/bin/systemd

Isso pode ser feito no menu grub para uma única inicialização - pressione "e" no menu grub e adicione isso à linha do kernel. Por exemplo, dependendo das opções necessárias para seu sistema em particular, pode parecer algo como:

linux   /vmlinuz-3.13-1-amd64 root=/dev/mapper/root-root init=/bin/systemd ro quiet

Se o PID 1 é systemd, então o seu sistema está sendo executado com systemd.

Configurando como padrão

Para usar o sistema, você também deve instalar systemd-sysv que fornece os links sysmlinks para /sbin/init. Recomenda-se executar isso quando já estiver executando no sistema, conforme descrito na seção anterior.

# apt-get install systemd-sysv

Para iniciar seu sistema com o systemd recém instalado, basta reiniciar.

# reboot

Se você executar um kernel autocompilado, certifique-se de ser o 2.6.39 ou mais recente e ativar as seguintes opções:

 * CONFIG_DEVTMPFS=y
 * CONFIG_CGROUPS=y
 * CONFIG_AUTOFS4_FS=[y|m]
 * CONFIG_IPV6=[y|m], opcional, mas altamente recomendado
 * CONFIG_FANOTIFY=y, opcional, necessário para o systemd readahead. disponível no kernel Linux >= 2.6.37.

Para obter uma lista atualizada, consulte a seção "REQUISITOS" no arquivo upstream README.

Gerenciando serviços com systemd

systemctl é a principal ferramenta utilizada para introspecção e controle do estado do gerenciador de sistema e serviços "systemd". Você pode usar systemctl, por exemplo, para ativar/desativar serviços permanentemente ou apenas para a sessão atual. Consulte a página de log systemctl(1) para obter mais detalhes.

Alguns exemplos básicos de uso

Liste todos os serviços em execução:

$ systemctl

Ativa o serviço "example1" imediatamente:

# systemctl start example1

Desativa o serviço "example1" imediatamente:

# systemctl stop example1

Reinicia o serviço "example1" imediatamente:

# systemctl restart example1

Mostra o status do serviço "example1":

# systemctl status example1

Permite que "example1" seja iniciado no boot:

# systemctl enable example1

Desabilita "example1" para não iniciar durante a inicialização:

# systemctl disable example1

Depuração

Às vezes, é necessário investigar por que o systemd trava na inicialização ou na reinicialização/desligamento.

Solução #0: Remova "quiet" da linha de comando do Kernel (denominada "cmdline" ou "grub line")

Solução #1: Aumentar a verbosidade via cmdline: Adicione "systemd.log_target=kmsg systemd.log_level=debug"

Claro que você pode ter uma solução "temporária" persistente:

[ /etc/default/grub ]
GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug" <--- Adicione aqui (ao descomentar você pode facilmente alternar para debug)

# update-grub

Solução #2: Aumentar a verbosidade via /etc/systemd/system.conf

LogLevel=debug <--- Desconecte esta linha e use "debug" (padrão: comentado e "info")
LogTarget=syslog-or-kmsg <--- Descomente desta linha (padrão: comentado)

Solução #3: Inicializar um shell de emergência: Adicione systemd.unit=rescue.target ou apenas 1 (o número um) para a linha de comando do kernel.

Solução #4: Habilite o shell de depuração: Execute systemctl enable debug-shell.service. (Você pode fazer isso em um ambiente chroot depois de inicializar um sistema de recuperação.) Isso inicia um shell de root no TTY 9.

DICA: "man systemd" e "man systemd-system.conf"

DICA: informações extensivas de depuração sobre systemd estão em this FreeDesktop page.

DICA: Como verificar os parâmetros/opções da linha de comando do Kernel?

# cat /proc/cmdline

NOTA no! LogLevel (veja systemd (1) e systemd-system.conf (5)):

"Definir o nível de log. Como argumento, isso aceita um nível de log numérico ou os nomes simbólicos conhecidos do syslog(3) (Minúsculas): emerg, alert, crit, err, warning, notice, info, debug."

DICA: mantenha uma cópia de /sbin/init do pacote sysvinit em caso de recuperação (para que você possa usar init=/sbin/init.sysvinit na cmdline)!

# cp -av /sbin/init /sbin/init.sysvinit <--- Antes de instalar o pacote systemd-sysv

Veja também https://fedoraproject.org/wiki/How_to_debug_Systemd_problems

Depuração de Kernel sem depuração do systemd no Jessie

Usando o antigo parâmetro do kernel "debug" no Jessie ativará o log de depuração do systemd, bem como o log de depuração do kernel. Para obter o comportamento antigo, não use "depurar", em vez disso, use o parâmetro do kernel "loglevel=7".

Bugs e sistemas de rastreamento de erros

Problemas Conhecidos e Soluções Alternativas

bind mounts compartilhados

O comportamento padrão de bind mounts muda sob systemd. O kernel do Linux faz bind mount de qualquer coisa abaixo de / PRIVATE. Systemd altera isso para SHARED.

Assim, quando você faz isso:

    mount --bind / $CHROOT
    mount --bind /dev/ $CHROOT/dev
    umount $CHROOT/dev

Então /dev será desmontado em seu sistema base/pai também!

O que você pode fazer agora, em vez disso, é:

    mount --bind --make-rslave / $CHROOT
    mount --bind --make-rslave /dev/ $CHROOT/dev

Isso irá propagar mudanças de montagem (também opções de montagem) no sistema base/pai no $CHROOT, mas não da $CHROOT de volta ao pai.

A justificativa para a mudança do comportamento padrão pode ser encontrada em bug 739593, em particular em Lenart's comment.

A sessão SSH não termina de forma limpa na reinicialização/desligamento

Se você reiniciar/desligar a máquina remota via ssh, você pode perceber que sua sessão não foi encerrada corretamente, deixando você com o terminal não reagente até o tempo limite longo terminar. Há um bug 751636 sobre isso. No momento, o trabalho em torno deste problema é instalar:

    apt-get install libpam-systemd

Que terminará a sessão ssh antes que a rede seja removida. Observe que isso exigiria que PAM fosse habilitado em sshd.

Faltando mensagens de inicialização no console (tty1) após a inicialização

Com o systemd, console(tty1) é tratado de forma diferente e se você verificou para ver como sua inicialização foi agora, você verá apenas algumas linhas não informativas.

Para poder obter uma transcrição completa da inicialização do sistema em seu console, você precisa executar duas etapas.

1. Adicionar às opções do kernel systemd.show_status=1, por exemplo, através de /etc/default/grub:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.show_status=1"

E execute update-grub2.

2. Crie o arquivo /etc/systemd/system/getty@tty1.service.d/noclear.conf com o conteúdo:

[Service]
TTYVTDisallocate=no

Para desabilitar a limpeza do terminal na invocação do getty.

Mudanças no console virtual e serial

Aqueles usados ​​para mudar inittab para habilitar / desativar consoles virtuais ou de série notarão que esse arquivo se foi de instalações limpas. Tudo isso é gerenciado através do SystemD diretamente agora. Por exemplo, você pode habilitar um console serial no COM1 com:

systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service

No entanto, geralmente é preferível adicionar console=ttyS0 na linha de comando do kernel, uma vez que isso também permite a saída do kernel nas reinicializações. No entanto, adicionando o seguinte a /etc/default/grub:

GRUB_CMDLINE_LINUX="console=ttyS0"

... e executando update-grub. Isso só entrará em vigor na próxima reinicialização.

processos órfãos

Como administra as sessões dos usuários (assumindo o papel de X ou outros componentes), o systemd pode mudar ligeiramente como os processos sobrevivem a uma sessão de logos. Por padrão, quando o X é interrompido, todos os processos devem sair e systemd irá limpar a sessão, mas existem alguns casos de canto em que determinados processos não são apagados adequadamente.

Você pode configurar como systemd gerencia os processos restantes com o parâmetro KillUserProcesses= em logind.conf. Ao definir isso como yes, os processos serão forçados a serem mortos quando a sessão for encerrada. Observe que isso irá quebrar ferramentas como o screen ou tmux, a menos que estejam configuradas para serem executadas sob uma unidade distinta de user@.service e se enable-linger estiver configurado para yes em loginctl.

Uma boa maneira de listar os processos afetados é agrupá-los por "grupo de controle", com o comando systemd-cgls:

systemd-cgls

Algumas aplicações conhecidas de comportamento incorreto:

Onde obter ajuda?

O Systemd é um projeto jovem com forte ênfase na solução de problemas de forma agnóstica de distribuição.

Os canais específicos do Debian incluem

Várias outras distribuições estão usando systemd

Instalando sem systemd

Jessie instala systemd por padrão em novas instalações. Se alguém desejar instalar sem systemd, use o sysvinit-core em vez disso (antigo sysV5 init), é possível usar preseed para substituir systemd com sysvinit no final da instalação (Isso provavelmente não funcionará se selecionar um ambiente de trabalho que exija características específicas do systemd, no entanto). Se já estiver usando um arquivo preseed, apenas certifique-se de definir o valor do preseed

preseed/late_command="in-target apt-get install -y sysvinit-core"

Se não estiver usando um arquivo preseed, isso pode ser adicionado aos argumentos de inicialização em vez disso, pressionando TAB no menu de inicialização na entrada desejada e anexando a linha predefinida acima no final do comando de inicialização.

Ainda pode haver algumas partes do systemd instaladas, mas, pelo menos, o próprio init não é sistematizado e a limpeza de peças restantes não deve ser muito difícil.

Recursos Debian

Outros Recursos


CategoryPermalink