Crie um serviço systemd. Comparando Systemd vs. SysVinit vs. Upstart

Como antes, para executar algum script na inicialização do sistema, você pode colocá-lo em um arquivo /etc/rc.d/rc.local. No entanto, vale a pena considerar os detalhes da execução desse script no systemd.

O arquivo de serviço da unidade responsável por isso é assim:

$ cat /lib/systemd/system/rc-local.service Description=/etc/rc.d/rc.local Compatibilidade After=network.target Type=forking ExecStart=/etc/rc.d/rc.local start TimeoutSec= 0 RemainAfterExit=sim SysVStartPriority=99

A partir disso, pode-se ver, em primeiro lugar, que o arquivo /etc/rc.d/rc.local deve ser executável.

E em segundo lugar, é claro que o serviço rc-local só depende do alvo rede.alvo. Parâmetro SysVStartPriority=99é responsável apenas pela prioridade em comparação com outros scripts sysVinit, que estão se tornando cada vez menos no Fedora. Com carregamento paralelo, isso significa que o script que você coloca no arquivo rc.local pode começar muito cedo, por exemplo, antes do início dos serviços necessários. Portanto, se você colocar scripts de reinicialização do Apache neste arquivo, eles provavelmente não funcionarão.

Nas versões anteriores ao Fedora 17, não havia dependência de rede.alvo, portanto, esse script foi executado quase no início.

Usando a unidade systemd

Uma maneira mais natural de o systemd executar scripts é criar sua própria unidade.

Basta criar um arquivo /etc/systemd/system/my_stuff.service com o seguinte texto:

Descrição=Executar minhas coisas Requer= rede.alvo Depois = rede.alvo Type=oneshot RemainAfterExit=True ExecStart= /some/script --com-alguns-parâmetros ExecStart= /algum/outro/script ProcuradoPor= multiusuário.alvo

Aqui Requer- indica o alvo após o qual o serviço deve ser iniciado, Depois significa que a rede deve estar totalmente operacional no momento do lançamento, Procurado por- a finalidade para a qual o serviço é iniciado. EM ExecStart deve ser especificado caminho completo ao script ou executável porque a variável PATH não é usada.

multi-user.target é o equivalente a init 3 em sysVinit. Você pode ler mais sobre a implementação de runlevels no systemd no link.

Nesta configuração, os scripts serão iniciados imediatamente após a rede ser iniciada e todas as interfaces serem iniciadas. No entanto, o systemd permite muito mais configuração flexível. Por exemplo, para executar scripts após iniciar o DM gráfico, você pode usar After: systemd-user-sessions.service

Pequeno exemplo: Após o aparecimento do armazenamento em nuvem Yandex.Disk, eu queria montá-lo automaticamente no sistema de arquivos via davfs2 (com o login e a senha definidos antecipadamente em /etc/davfs2/secrets). A gravação em fstab falhou, assim como a gravação em rc.local, porque no Fedora 16 ambos foram processados ​​antes que a rede fosse levantada. Mas criar um módulo de acordo com o exemplo acima resolveu o problema.

Adicionalmente

Para diagnosticar um serviço, use o comando

Systemctl status rc-local.service

ou dê uma olhada no arquivo /var/log/boot.log(aparecerá se você remover nas opções de inicialização quieto, cm.

Aqui vou mostrar como escrever initniks para iniciar automaticamente qualquer daemon em um sistema systemd.

O Systemd trata os arquivos de unidade como arquivos de configuração. É como um arquivo .conf para upstart ou scripts init para initd. Arquivos de unidade também podem descrever outras entidades do sistema, mas em este caso estamos interessados ​​neles como uma configuração para o início automático do serviço. No Ubuntu 16.04 eles estão em /etc/systemd/ . Vamos escrever nosso arquivo unit.

Digamos que temos um programa que queremos executar como um daemon. Aqui eu escrevi como criar um bot de telegrama. Eu tenho um arquivo executável que roda e trava esperando por mensagens. Agora quero que ele inicie como um daemon quando o sistema for inicializado.

Criamos esse arquivo:

Description = TelegramBotMonitoring After = network.target Type = simple ExecStart = /usr/local/bin/telegram-site-monitoring -telegrambottoken 397______:___________WRDsIU -chatid -14____640 Reiniciar = sempre WantedBy = multi-user.target

e coloque-o em /etc/systemd/system/telegram-bot.service

A configuração é semelhante a um arquivo ini regular:

Depois - lança esta unidade após certos demônios ou alvos (o alvo é um conjunto de unidades). Network.target é especificado aqui, o que significa que o daemon será iniciado após o surgimento das interfaces de rede.

Tipo - o tipo de como o daemon é iniciado. O mais comumente usado é simple , forking ou one-shot . simples - o daemon inicia e espera no console e não bifurca. bifurcação - o daemon inicia, então bifurca e termina o processo pai. Muitos programas são iniciados dessa maneira para alternar para o modo de segundo plano. Por exemplo, o nginx inicia assim. one-shot - usado para executar scripts que executam, executam e terminam. No meu caso, isso não é um script e o programa não bifurca, então o tipo é simples

ExecStart é o comando para iniciar o daemon.

Reiniciar - reinicie o daemon se ele terminar/falhar. Com always systemd, o daemon será reiniciado, independentemente do motivo pelo qual ele foi encerrado. Você pode especificar on-failure , então ele será reiniciado se o daemon sair com um código de retorno diferente de zero ou for encerrado por um sinal (kill DAEMONPID)

WantedBy - dizemos para executar este daemon quando o sistema inicializar no modo multiusuário

# systemctl daemon-reload

E adicione a unidade criada para carregar automaticamente:

# systemctl habilita telegram-bot.service Link simbólico criado de /etc/systemd/system/multi-user.target.wants/telegram-bot.service para /etc/systemd/system/telegram-bot.service.```

Todos. O serviço foi adicionado à inicialização, mas ainda não foi iniciado. Vamos correr:

# systemctl start telegram-bot

Lançado:

# systemctl status telegram-bot ● telegram.service - TelegramBotMonitoring Carregado: carregado (/etc/systemd/system/telegram-bot.service; ativado; predefinição do fornecedor: ativado) Ativo: ativo (em execução) desde qui 2017-07-13 17:10:19 MSK; 5s atrás PID principal: 1825 (telegram-site-m) Tarefas: 4 Memória: 4.4M CPU: 39ms CGroup: /system.slice/telegram-bot.service └─1825 /usr/local/bin/telegram-site-monitoring -telegrambottoken 3972____:__________Gi03WRDsIU -chatid -14____40 13 de julho 17:10:19 ubuntu systemd: Iniciado TelegramBotMonitoring. 13 de julho 17:10:19 ubuntu telegram-site-monitoring:2017/07/13 17:10:19 () 13 de julho 17:10:19 ubuntu telegram-site-monitoring: 2017/07/13 17:10:19 Autorizado por conta 13 de julho 17:10:19 ubuntu telegram-site-monitoring: 2017/07/13 17:10:19 Arquivo de configuração: config.json 13 de julho 17:10:19 ubuntu telegram-site-monitoring: 2017/07/13 17:10:19 ChatID: 13 de julho 17:10:19 ubuntu telegram-site-monitoring: 2017/07/13 17:10:19 Iniciando thread de monitoramento

Folha de dicas com comandos para gerenciar daemons systemd -

Houve holiwars em torno do systemd por vários anos. O Systemd veio até nós para substituir o System V Init no Linux. Existem apoiadores do systemd e seus oponentes. Vejamos por que o systemd é tão ruim:

1. O Systemd quebra a filosofia Unix de "Faça uma coisa e faça bem" simplesmente apresentando um conjunto complexo de binários fracamente acoplados. Sua área de responsabilidade há muito cresceu além do sistema init e começa a se espalhar para gerenciamento de energia, dispositivos, pontos de montagem, cron, criptografia de disco, API de soquete, registro (syslog), configuração de rede, gerenciamento de sessão, readahead, partição definição, registro de contêiner [virtualização], gerenciamento de nome de host-tempo-localidade, mDNS/DNS-SD, consoles Linux e muito mais, tudo em um. Na agenda - uma maior expansão do systemd e sua introdução no ambiente GNU/Linux foi esclarecida durante o "2014 GNOME Asia talk". Dê-nos um BEIJO.

2. logs systemd (para journald) são armazenados em um formato binário muito complexo e só podem ser consultados por journalctl. Isso torna os logs potencialmente corrompidos e eles não têm transações compatíveis com ACID. Você não gostaria que nada acontecesse com os logs do sistema. Conselhos de desenvolvedores do systemd? Mate isso. A única maneira de criar logs tradicionais é executar syslogd como rsyslog junto com journald. Ele também possui um servidor HTTP integrado. Códigos QR também podem ser fornecidos através dele, usando libqrencode.

3. Como o systemd é muito dependente da API do kernel do Linux, diferentes versões do systemd são incompatíveis com diferentes kernels e a portabilidade é reduzida desnecessariamente em diferentes componentes. Esta é uma política de isolamento, que, claro, coloca o ecossistema Linux em sua própria gaiola, atuando como um obstáculo ao desenvolvimento de software portátil com derivados Linux e Unix. Isso também causa dificuldades no backporting de mudanças no sistema de suporte de longo prazo.

4. udev e dbus tornam-se dependências obrigatórias. Na verdade, o udev foi incorporado ao ramo systemd há muito tempo. Integrar o gerenciador de "nó de dispositivo" (que fazia parte do kernel do Linux) não é uma decisão fácil. Há muitas conotações políticas aqui (significando política do desenvolvedor) e muitos pacotes que dependem do udev tornaram-se dependentes do systemd, apesar de bifurcações como o eudev. Desde o systemd-209, os desenvolvedores introduziram sua própria API sd-bus não padrão e pouco documentada, que substitui algumas das tarefas libdbus. Eles então decidiram portar o udev para esse novo transporte, substituíram o Netlink e transformaram o udev em um daemon systemd conectado. O efeito é, obviamente, significativo.

5. O systemd apresenta um auxiliar que faz coredumps (core dumps) e os redireciona para /var/lib/systemd/coredump ou journal, onde devem ser solicitados via coredumpctl. Este último, aliás, era o comportamento padrão e parece que será retornado. Isso significa que usuários e administradores estão sendo tratados como idiotas, mas, mais importante, a natureza inerentemente corrupta dos logs do journald torna isso um incômodo sério e uma escolha irresponsável no design do sistema. Também pode criar complicações em ambientes multiusuário em termos de privilégios.

6. O tamanho do systemd (aparentemente em arquivos e megabytes - aprox. por.) O transforma em um grande "ponto único de falha". No momento da redação deste artigo, o systemd teve 9 relatórios de CVE (vulnerabilidades) desde a introdução em março de 2010. Pode não parecer muito, mas sua natureza difundida (em termos de responsabilidade do componente) e importante pode ser um petisco saboroso para crackers , já que sua largura é menor que o kernel , mas igualmente crítico em termos de consequências

7. systemd é viral, suas extensões adicionam novas APIs, mas continuam dependendo de sua inicialização. Sua cobertura de funcionalidade e sua disseminação como uma dependência em vários pacotes significa que os mantenedores da distribuição serão obrigados a forçar uma transição ou derrubá-la (a antiga). Por exemplo, o GNOME geralmente usa componentes systemd como logind, e o suporte a sistemas não systemd torna-se difícil. Em Wayland, o GNOME usa o logind, o que força você a usar o systemd novamente. Mais e mais mantenedores estão escrevendo dependências do systemd por esse motivo. O rápido crescimento na adoção de distribuições como Debian, Arch Linux, Ubuntu, Fedora, openSUSE mostra que muitos estão tentando pular no trem de partida, às vezes sem pensar (talvez eu não tenha traduzido exatamente aqui). Por exemplo, é estranho que Weston compositor, Polkit, upower, udisks2, PackageKit, etc. dependam dele. Além disso, o fato de o systemd não querer ser executado como usuário realmente não dá nada.

8. O systemd é executado sob o PID 1 em vez de ser executado como um hipervisor de processo separado. Como ele controla vários componentes, há muitas opções nas quais ele pode morrer (pintar) e enviar todo o sistema ao esquecimento (veja acima sobre o ponto de falha). Também observamos que, para reduzir a necessidade de reinicialização, o systemd fornece um mecanismo para reiniciar o systemctl em tempo real. Mas se algo está errado com ele, o sistema entra em colapso novamente. Existem também várias maneiras pelas quais isso pode acontecer, incluindo a incapacidade de ler um estado incompatível anterior. Este parece ser outro exemplo de SPOF (ponto único de falha) e sobrecarga desnecessária em um componente já crítico (init).

9. systemd é projetado com glibc em mente e realmente não suporta outras libcs. Em geral, a ideia dos desenvolvedores do systemd na biblioteca libc padrão é que bug a bug repetirá glibc.

10. A complexa organização mental do systemd torna muito difícil estender além de sua própria estrutura de desenvolvimento. Embora seja possível executar um script a partir de arquivos de módulo, é muito difícil escrever uma implementação do comportamento que sai da caixa, levando em consideração todos esses recursos interessantes. É mais provável que muitos usuários desejem escrever programas complexos que interajam diretamente com a API do systemd ou até modifiquem (suas fontes). Alguém pode se preocupar com muitos caminhos de código em um programa crítico do sistema, incluindo a possibilidade de que o systemd fique fora de sincronia com o barramento de mensagens na inicialização e travar. Isso é o oposto do init tradicional, que é definido e previsível pela arquitetura.

11. Em última análise, a disseminação do systemd é um pouco mais simbólica do que apenas systemd. Isso mostra uma mudança radical na mentalidade da comunidade Linux. E não necessariamente positivo. Essa mudança é principalmente orientada para a área de trabalho, limitada na escolha, isolacionista, cíclica e extremamente antipadrão. Se seu objetivo é satisfazer o menor divisor, faça-o. Mas vamos olhar em alguma outra direção.

12. systemd parece não saber o que diabos quer ser. Às vezes é descrito como um "daemon do sistema" ou como "uma unidade base do espaço do usuário para criar um sistema operacional", ambos os termos são muito ambíguos. Ele absorve a funcionalidade que costumava pertencer ao util-linux, ferramentas sem fio, syslog e outros projetos. Não tem uma direção clara, exceto como peculiaridades dos próprios desenvolvedores. O que é engraçado apesar dos objetivos de padronização distribuições Linux, não tem um padrão claro e essencialmente apenas rola como uma erva daninha.

O systemd é um novo daemon de inicialização do sistema Linux que deve eventualmente substituir o clássico daemon SysV initd. As principais tarefas que se destina a resolver são, em primeiro lugar, a aceleração da inicialização do sistema devido a ampliação máxima o número de serviços executados em paralelo, em segundo lugar, melhorando a capacidade de gerenciamento do sistema por meio do uso de recursos específicos fornecidos pelo kernel do Linux, em terceiro lugar, a unificação das configurações de todo o sistema e a generalização máxima do código de inicialização para vários serviços. Pelo menos foi assim que me senti depois de ler a documentação.

Quero agradecer a Sergey Ptashnik pela excelente tradução da documentação do systemd: systemd para o administrador do autor do próprio sistema, Lennart Potering. Também quero agradecer as inúmeras notas à documentação, que sempre estão em vigor. Esta e minhas notas subsequentes são essencialmente baseadas nesta documentação, ou melhor, em sua versão PDF.

1. Instale o systemd

Instalar o systemd é muito fácil. Vamos instalar o pacote primeiro:
# apt-get install systemd E escreva o uso de systemd nas configurações do kernel do Linux. Para fazer isso, abra o arquivo com as configurações do carregador de inicialização GRUB 2:
# vi /etc/default/grub E adicione à configuração GRUB_CMDLINE_LINUX_DEFAULT opção adicional init=/lib/systemd/systemd. Após a edição, esta opção fica assim:
GRUB_CMDLINE_LINUX="video=VGA-1:640x480 video=TV-1:640x480 rootfstype=ext4 init=/lib/systemd/systemd" Agora aplique as alterações gerando um novo arquivo de configuração do bootloader:
# update-grub Agora você pode reiniciar o sistema para começar a usar o systemd:
# desligamento -r agora 2. Resolução de problemas

2.1. Localização do console de texto

O primeiro problema que encontrei foi um erro ao executar o script cirílico do console. Esse script deve ser executado com um console de texto ativo e o systemd executa todos os scripts init de forma assíncrona, fazendo com que esse script seja executado quando o servidor X já estiver em execução. Como resultado, em vez de letras russas, quadrados são exibidos no console, você não pode alternar o layout e voltar para a sessão gráfica.

Console-cyrillic é um pacote obsoleto que foi deixado no meu sistema desde quando o instalei (que foi durante os dias do Etch). Este pacote está presente em versões mais recentes do Debian e ainda é suportado, mas os pacotes de configuração do console e configuração do teclado são alternativas mais genéricas. O artigo Exibindo russo no console Natty do Ubuntu 11.04 descreve as etapas necessárias para configurá-los.

Instale os pacotes necessários:
# apt-get install console-setup keyboard-configuration Se, por algum motivo, o configurador de pacotes não foi iniciado durante a instalação dos pacotes, você pode forçar a configuração do pacote:
# dpkg-reconfigure console-setup # dpkg-reconfigure keyboard-configuration Em geral, o systemd fornece novos arquivos de configuração para configurar um console de texto, mas essas configurações não funcionaram no meu sistema.

2.2. Salvando a hora do sistema no relógio de hardware do BIOS

Ao alterar as configurações de hora, por algum motivo, a hora não é salva no relógio do BIOS. Você pode salvar a hora atual do sistema no relógio do hardware com o comando:
# hwclock -w A hora real que será armazenada no relógio do BIOS depende da terceira linha de /etc/adjtime. No caso de uma string UTC, o horário de Greenwich será salvo, no caso de uma string LOCAL, a hora do fuso horário atual será salva.

Deve-se notar que, desde Wheezy, a configuração UTC foi removida do arquivo /etc/default/rcS e a configuração do arquivo /etc/adjtime: release-notes: utc/local timezone não está mais em /etc/default/rcS arquivo é usado em seu lugar.

A raiz do problema está no fato de eu usar o openntpd, não o ntpd. No caso de um ntpd em execução no kernel do sistema, está incluído o salvamento do tempo atual do sistema em um cronômetro de hardware a cada 11 minutos. Os desenvolvedores do systemd acharam que isso era o suficiente. Se o ntpd não for usado, é impossível determinar qual dos relógios é mais preciso - hardware ou sistema, portanto, não faz sentido preferir um relógio em detrimento de outro. Se necessário, o usuário deve ajustar manualmente o relógio conforme necessário.

Para resolver esse problema, decidi escrever meu próprio arquivo de serviço para o daemon openntpd. O conteúdo do arquivo de serviço /etc/systemd/system/openntpd.service:
Description=openntpd After=network.target Type=simple ExecStart=/usr/sbin/ntpd -dsf /etc/openntpd/ntpd.conf ExecStartPost=/bin/chown ntpd /var/lib/openntpd/ntpd.drift ExecStop=/sbin /hwclock -w WantedBy=multi-user.target Agora precisamos parar a instância openntpd já em execução, diga ao systemd que sua configuração foi alterada:
# systemctl stop openntpd.service # systemctl daemon-reload Carregue automaticamente o arquivo de serviço recém-criado e inicie o openntpd:
# systemctl enable openntpd.service # systemctl start openntpd.service 3. Gerenciamento de serviços

O Systemd, ao contrário do inetd, pode monitorar independentemente todos os processos gerados pelo serviço. Para isso, são utilizados os chamados grupos de controle de processos - cgroups. Cada serviço começa com seu próprio ID de grupo. Todos os processos adicionais gerados no serviço também recebem esse identificador. Isso elimina a necessidade de usar arquivos PID para gerenciar o serviço. Além disso, graças aos cgroups, os processos gerados por um serviço nunca são perdidos. Por exemplo, o processo CGI será interrompido junto com o servidor web, mesmo que o servidor web não se encarregue de pará-lo e coloque o ID do processo no arquivo PID. Os processos do usuário também são colocados em um grupo de controle separado e monitorados pelo subsistema logind, que substituiu o ConsoleKit.

A segunda característica importante do systemd é que ele tem seu próprio sistema de journaling chamado journald. Este sistema agrega informações de diferentes fontes e as vincula a serviços. Mensagens de kernel, mensagens de processo enviadas via syslog, mensagens enviadas usando a própria API do journald e mensagens enviadas por um processo para a saída padrão - STDOUT e para o fluxo padrão para mensagens de diagnóstico - STDERR são coletadas em um local com um link para um serviço. O Systemd também rastreia os códigos de saída do processo. Graças a isso, todas as informações de diagnóstico do serviço podem ser visualizadas em um só lugar e é conveniente diagnosticar problemas.

systemctl- visualizar os status do serviço. Se a saída do comando não for redirecionada para algum lugar, mas chegar ao console, um programa de pager será iniciado automaticamente para visualizar o status dos serviços, geralmente é menor,
status systemctl openntpd.service - visão detalhada do status do serviço especificado (openntpd),
status systemctl --follow openntpd.service - visualizar o status do serviço especificado (openntpd) com a exibição de mensagens do serviço no processo de recebimento. Esta opção tem uma contraparte mais curta - -f, que por algum motivo não funcionou no meu sistema. Talvez o fato seja que a opção -f também tenha um segundo significado - --force e systemctl não é capaz de determinar qual das opções se refere,
status do systemctl -n10 openntpd.service - visualizar o status do serviço especificado (openntpd) com a saída das últimas 10 mensagens do serviço,
systemctl reset-failed- redefinir todos os status de encerramento exibidos pelo comando view service status,
systemd-cgls- visualizar a hierarquia dos grupos de controle do processo (algo semelhante pode ser obtido usando o comando ps xawf -eo pid,user,cgroups,args),
systemctl daemon-reload- recarregar a configuração do systemd,
systemctl start openntpd.service - iniciar o serviço especificado (openntpd), semelhante a update-rc.d openntpd iniciar para SysV initd,
systemctl stop openntpd.service - pare o serviço especificado (openntpd), semelhante a update-rc.d openntpd parar para SysV initd,
reinicialização systemctl openntpd.service - reinicie o serviço especificado (openntpd),
systemctl ativar openntpd.service - ativar a inicialização do serviço especificado (openntpd) na inicialização do sistema, semelhante a update-rc.d openntpd habilitar para SysV initd,
systemctl desativar openntpd.service - desativar o início do serviço especificado (openntpd) na inicialização do sistema, semelhante a update-rc.d openntpd desativar para SysV initd,
máscara systemctl openntpd.service - proibição de iniciar o serviço especificado (openntpd), será mesmo impossível iniciá-lo manualmente,
systemctl desmascarar openntpd.service - permissão para iniciar o serviço especificado (openntpd), pode ser iniciado manualmente, também será permitido iniciar na inicialização do sistema, se estiver configurado,
systemctl kill openntpd.service - enviar um sinal (por padrão, um sinal SIGTERM é enviado) para todos os processos no grupo de controle do serviço (openntpd),
systemctl kill -s SIGKILL openntpd.service - enviar um sinal SIGKILL para todos os processos no grupo de controle do serviço (openntpd). Você também pode usar o nome abreviado do sinal - KILL,
systemctl kill -s HUP --kill-who=main serviço crond - Envio de um sinal SIGHUP para o processo principal do grupo de controle do serviço (crond). Este exemplo forçará o crond a reler o arquivo de configuração, enquanto os trabalhos iniciados pelo crond não receberão este sinal e continuarão trabalho normal,
ajuda systemctl openntpd.service - ver a documentação do serviço (não funciona no Debian Wheezy),
culpa do systemd-analyze- exibição de uma lista de serviços, classificados em ordem decrescente do tempo gasto em seu início. O comando pode ser útil para encontrar gargalos durante a inicialização do sistema,
systemd-analyze plot > plot.svg- saída de um diagrama de temporização em formato SVG, ilustrando a sequência (e paralelismo) de início dos serviços.

4. Novos arquivos de configuração do sistema

Systemd apresenta uma série de novos arquivos de configuração para configurações de todo o sistema. Espera-se que esses arquivos eventualmente se tornem padrão e substituam os arquivos de configuração do sistema que são específicos para diferentes distribuições. Até que isso aconteça, o systemd usará os arquivos de configuração da distribuição se não houver novos arquivos.

Além disso, como todos os serviços agora serão iniciados usando arquivos de serviço, não há necessidade de usar arquivos incluídos em scripts de shell. Estes são arquivos localizados em /etc/default (família Debian) e /etc/sysconfig (família RedHat). Como os arquivos de serviço são muito mais fáceis de navegar do que os scripts de shell, não há necessidade de mover as configurações de serviço para arquivos separados - todas as configurações necessárias podem ser inseridas diretamente no arquivo de serviço.

Aqui estão os novos arquivos de configuração introduzidos pelo systemd:

/etc/hostname- nome da rede do sistema,
/etc/vconsole.conf- configurações de fonte do console do sistema e layout do teclado,
/etc/locale.conf- configurações de idioma do sistema,
/etc/modules-load.d/*.conf- um diretório para listar os módulos do kernel a serem forçados a carregar na inicialização do sistema,
/etc/sysctl.d/*.conf- diretório para configurações de parâmetros do kernel, complementa o arquivo clássico /etc/sysctl.conf,
/etc/tmpfiles.d/*.conf- diretório para gerenciar configurações de arquivo temporário,
/etc/binfmt.d/*.conf- um diretório para registrar formatos de arquivos executáveis, como formatos Java, Mono, WINE,
/etc/os-release- um arquivo com o identificador da distribuição e sua versão,
/etc/machie-id- um arquivo com um identificador de sistema exclusivo permanente,
/etc/machie-info- um arquivo com um nome de rede descritivo para o sistema. O ícone do sistema que será exibido em shells gráficos também é configurado aqui. O arquivo é servido pelo daemon systemd-hostnamed.

5. subsistema de registro diário

Como já mencionado, o systemd apresenta um novo sistema de registro que coleta informações de várias fontes (mensagens do kernel, mensagens enviadas para syslog, STDOUT e STDERR) em um só lugar. Este sistema não o força a abandonar o daemon de registro syslog padrão - você pode usar ambos os sistemas de registro em paralelo.

O Journald usa dois diretórios para armazenar informações do diário:
/run/log/journal- diretório com um buffer circular de mensagens recentes,
/var/log/diário- diretório com armazenamento permanente de todas as mensagens.

Por padrão, apenas o primeiro diretório é usado e, para permitir o armazenamento persistente de todas as mensagens, o segundo diretório deve ser criado manualmente (no Debian Wheezy, esse diretório é criado automaticamente quando o systemd é instalado e o primeiro diretório não é usado):
# mkdir -p /var/log/journald Você pode então, mas não precisa, remover o daemon de registro de diário rsyslog ou ng-syslog padrão.

As configurações do daemon journald do Debian Wheezy são armazenadas em um arquivo /etc/systemd/systemd-journald.conf. Em particular, você pode definir configurações de compactação para o arquivo de log, definir um limite para o tamanho dos arquivos de log, configurar a duplicação de mensagens para o console do sistema ou para o daemon syslog.

O usuário root e os usuários do grupo adm têm acesso a todas as mensagens do log, enquanto os usuários normais só têm acesso às mensagens geradas por seus processos.

Para visualizar as mensagens do diário no Debian Wheezy, você pode usar o comando systemd-journalctl (o manual especifica o comando journalctl):
systemd-journalctl- ver todas as mensagens. Como no caso do systemctl, se a saída do comando não for redirecionada para nenhum lugar, mas chegar ao console, um programa de pager, geralmente menor, é iniciado automaticamente para uma visualização mais conveniente das mensagens,
systemd-journalctl -f- visualização de mensagens em processo de recebimento,
systemd-journalctl -n10- ver as últimas 10 mensagens,
systemd-journalctl -b- visualizar as mensagens geradas desde a inicialização do sistema (não funciona no Debian Wheezy),
systemd-journalctl -b -p err- visualizar mensagens geradas desde a inicialização do sistema e com erro de prioridade ou superior (não funciona no Debian Wheezy),
systemd-journalctl --since=ontem- visualizar todas as mensagens geradas desde ontem (não funciona no Debian Wheezy),
systemd-journalctl --since=2012-10-15 --until="2012-10-16 23:59:59"- visualizar todas as mensagens geradas em 15 e 16 de outubro de 2012 (não funciona no Debian Wheezy),
systemd-journalctl -u httpd --since=00:00 --until=09:30- ver todas as mensagens geradas por um usuário httpd hoje da meia-noite às nove e meia (não funciona no Debian Wheezy),
systemd-journalctl /dev/sdc- ver todas as mensagens mencionando a unidade sdc (não funciona no Debian Wheezy),
systemd-journalctl /usr/sbin/vpnc- visualizar todas as mensagens dos processos /usr/sbin/vpnc (não funciona no Debian Wheezy),
systemd-journalctl /usr/sbin/vpnc /usr/sbin/dhclient- visualizar todas as mensagens dos processos /usr/sbin/vpnc e /usr/sbin/dhclient, combinadas e classificadas por hora (não funciona no Debian Wheezy),

Além de simplesmente visualizar mensagens de texto, é possível visualizar os metadados que o próprio journald adiciona a cada entrada de diário. Para ver esses campos, basta usar a seguinte opção, que altera o formato de saída dos dados:
systemd-journalctl -o detalhado- Exibe todos os metadados que acompanham a mensagem em um formato legível por humanos junto com a mensagem do log. Outros formatos disponíveis: exportação - o mesmo formato detalhado, mas sem recuos, json - saída no formato JSON, cat - saída apenas de texto de mensagem sem nenhum dado adicional.

Os nomes de campo que começam com um sublinhado podem ser usados ​​para filtrar mensagens. A revista é indexada em todos os campos, portanto, a pesquisa é rápida. Exemplos de filtragem de mensagens por metadados:
systemd-journalctl _UID=70- exibir todas as mensagens dos processos do usuário com ID 70,
systemd-journalctl _UID=70 _UID=71- saída de todas as mensagens de processos de usuário com identificadores 70 e 71. A especificação de campos com o mesmo nome implica automaticamente uma operação lógica OR,
systemd-journalctl _HOSTNAME=epsilon _COMM=avahi-daemon- saída de todas as mensagens de processos chamados avahi-daemon rodando em um computador chamado epsilon. Nesse caso, diferentes campos são especificados, portanto, uma operação lógica AND está implícita,
systemd-journalctl _HOSTNAME=theta _UID=70 + _HOSTNAME=epsilon _COMM=avahi-daemon- exibir mensagens que correspondam a qualquer um dos dois filtros combinados com um sinal de +. O sinal + indica uma operação OR lógica explícita, que tem precedência menor que AND,
systemd-journalctl -F _SYSTEMD_UNIT- saída de todos os valores do campo _SYSTEMD_UNIT disponíveis no log. Os valores resultantes podem ser usados ​​para filtrar registros de interesse (não funciona no Debian Wheezy).

Systemd é um sistema init e gerenciador de sistema que está se tornando o novo padrão para máquinas Linux. O debate sobre o desempenho do systemd comparado aos sistemas SysV init tradicionais ainda está em andamento, no entanto, a maioria das distribuições planeja implementar esse sistema, e muitas já o fizeram.

Aprender e trabalhar com as ferramentas e daemons do systemd ajudará você a apreciar melhor o poder, a flexibilidade e outros recursos do sistema ou, pelo menos, lidar com o mínimo de problemas.

Este tutorial ensinará como trabalhar com o comando systemctl, a principal ferramenta de gerenciamento do sistema systemd init. Você aprenderá como gerenciar serviços, verificar status e trabalhar com arquivos de configuração.

gerenciamento de serviços

O principal objetivo do sistema init é inicializar os componentes que devem ser iniciados após o carregamento do kernel do Linux (tradicionalmente chamados de componentes "customizados"). O sistema init também é usado para gerenciar serviços e daemons do servidor. Com isso em mente, vamos começar nossa introdução ao systemd com operações simples de gerenciamento de serviços.

No systemd, o alvo da maioria das ações são as unidades, que são recursos que o systemd pode gerenciar. As unidades são categorizadas pelos tipos de recursos que representam. As unidades são definidas nos chamados arquivos de unidade. O tipo de cada unidade pode ser determinado pelo sufixo no final do arquivo.

Arquivos de unidade com o sufixo .service destinam-se a tarefas de gerenciamento de serviço. No entanto, na maioria dos casos, o sufixo .service pode ser omitido, pois o systemd é inteligente o suficiente para descobrir o que fazer ao usar comandos de controle de serviço sem o sufixo.

Iniciando e parando o serviço

Para iniciar um serviço systemd, use o comando start. Se você não estiver em uma sessão root, precisará usar o sudo, pois este comando afetará o estado do sistema operacional:

sudo systemctl start application.service

Como mencionado anteriormente, o systemd sabe procurar arquivos *.service para comandos de gerenciamento de serviço, então este comando pode ser digitado assim:

sudo systemctl iniciar aplicativo

O formato acima pode ser usado no trabalho diário, mas no manual para maior clareza, usaremos o sufixo .service.

Para parar o serviço, basta digitar o comando stop:

sudo systemctl stop application.service

Reinicie e reinicie

Para reiniciar o serviço, use restart:

sudo systemctl reiniciar aplicativo.service

Se o aplicativo especificado puder recarregar seus arquivos de configuração (sem reiniciar), reload pode ser usado:

sudo systemctl reload application.service

Se você não sabe se um serviço pode recarregar seus arquivos, use o comando reload-or-restart. Ele reiniciará o serviço e, se isso não for possível, ele o reiniciará.

sudo systemctl reload-or-restart application.service

Habilitando e desabilitando serviços

Os comandos acima são necessários ao trabalhar com o serviço na sessão atual. Para adicionar um serviço ao carregamento automático do systemd, você precisa ativá-lo.

Existe um comando de habilitação para isso:

sudo systemctl habilitar aplicativo.service

Isso criará um link simbólico para uma cópia do arquivo de serviço (normalmente /lib/systemd/system ou /etc/systemd/system) no ponto do disco onde o systemd procura arquivos para execução automática (normalmente /etc/systemd/system/ some_target.target.want , mais sobre isso posteriormente no guia).

Para remover o serviço da inicialização, você precisa inserir:

sudo systemctl desativar application.service

Lembre-se de que habilitar um serviço não o inicia na sessão atual. Se você deseja iniciar o serviço e incluí-lo na inicialização, é necessário executar os comandos start e enable.

Verificando o status de um serviço

Para verificar o status de um serviço, digite:

systemctl status application.service

Este comando produzirá o estado do serviço, a hierarquia do grupo e as primeiras linhas do log.

Por exemplo, ao verificar o status do servidor Nginx, você pode ver uma saída como esta:

nginx.service - Um servidor web de alto desempenho e um servidor proxy reverso
Carregado: carregado (/usr/lib/systemd/system/nginx.service; ativado; predefinição do fornecedor: desativado)
Ativo: ativo (em execução) desde terça-feira 27/01/2015 19:41:23 EST; 22 horas atrás
PID principal: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: processo mestre /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: processo de trabalho
27 de janeiro 19:41:23 desktop systemd: Iniciando um servidor web de alto desempenho e um servidor proxy reverso...
27 de janeiro 19:41:23 desktop systemd: Iniciado Um servidor web de alto desempenho e um servidor proxy reverso.

Isso fornece uma visão geral do estado atual do aplicativo, notifica você sobre quaisquer problemas e qualquer ação que possa ser necessária no futuro.

Também existem métodos para verificar estados específicos. Por exemplo, para verificar se uma determinada unidade está ativa (em execução), você pode usar o comando is-active:

systemctl is-active application.service

Isso exibirá o estado atual da unidade, geralmente ativo ou inativo. O código de saída será "0" se a unidade estiver ativa, o que simplifica o processo de análise.

Para descobrir se uma unidade está habilitada, você pode usar o comando is-enabled:

systemctl está habilitado application.service

Este comando informará se o serviço está habilitado e retornará o código de saída para "0" ou "1" dependendo do resultado.

O terceiro comando permite determinar se a unidade está em estado de falha. Isso indica que houve um problema ao iniciar a unidade em questão:

systemctl falhou application.service

O comando retornará ativo se a unidade estiver funcionando corretamente e falhará se ocorrer um erro. Se a unidade foi parada propositalmente, o comando pode retornar desconhecido ou inativo. Um código de saída "0" significa que ocorreu uma falha, enquanto "1" indica qualquer outro estado.

Visão geral do status do sistema

Anteriormente, cobrimos os comandos necessários para gerenciar serviços individuais, mas eles não são muito úteis para examinar o estado atual do sistema. Existem vários comandos systemctl que fornecem essas informações.

Visualizando uma lista de unidades atuais

Para solicitar uma lista das unidades systemd atuais, use o comando list-units:

systemctl list-units

Este comando listará todas as unidades que existem atualmente no sistema systemd. O resultado será mais ou menos assim:

SUB DESCRIÇÃO DE CARGA DA UNIDADE ATIVA
atd.service carregado ativo executando daemon ATD
avahi-daemon.service carregado ativo em execução Avahi mDNS/DNS-SD Stack
dbus.service carregado ativo executando D-Bus System Message Bus
dcron.service carregado ativo em execução Programador de comando periódico
dkms.service carregado ativo encerrado Dynamic Kernel Modules System
[e-mail protegido] carregado ativo em execução Getty em tty1
. . .

A saída tem as seguintes colunas:

• UNIT é o nome da unidade systemd.
• LOAD Informa se a configuração da unidade foi processada pelo systemd. A configuração das unidades carregadas é armazenada na memória.
• ACTIVE - estado resumido da unidade. Isso geralmente permite que você determine rapidamente se a unidade atual foi iniciada com sucesso.
• SUB: Estado de subnível que fornece informações detalhadas sobre o dispositivo. Isso geralmente depende do tipo de unidade, do estado e do método real em que a unidade está sendo executada.
• DESCRIÇÃO- Pequena descrição funções da unidade.

Como o comando list-units mostra apenas as unidades ativas por padrão, todas as entradas acima serão carregadas na coluna LOAD e ativas na coluna ACTIVE. Este formato é o comportamento padrão de systemctl quando chamado sem comandos adicionais, então você verá a mesma coisa se chamar systemctl sem argumentos:

Com systemctl, você pode consultar várias informações adicionando sinalizadores. Por exemplo, para ver todas as unidades que o systemd carregou (ou tentou carregar), estejam elas ativas ou não, você pode usar o sinalizador -all:

systemctl list-units --all

Este comando relatará as unidades que o systemd carregou ou tentou carregar, independentemente de seu estado atual. Após a inicialização, algumas unidades ficam inativas e as unidades que o systemd tentou carregar não foram encontradas no disco.

Você pode usar outros sinalizadores para filtrar os resultados. Por exemplo, o sinalizador --state= pode ser usado para especificar os estados LOAD, ACTIVE ou SUB. O sinalizador --all deve ser deixado para que o sistema exiba unidades inativas:

systemctl list-units --all --state=inativo

Outro filtro popular é --type=. Ele permite que você filtre as unidades por tipo. Por exemplo, para solicitar apenas unidades ativas, você pode inserir:

systemctl list-units --type=service

Lista de arquivos da unidade

O comando list-units lista apenas as unidades que o systemd tentou processar e carregar na memória. Como o systemd lê seletivamente apenas os arquivos de unidade que considera necessários, a lista não incluirá todos os arquivos de unidade disponíveis. Para listar todos os arquivos de unidade disponíveis (incluindo aqueles que o systemd não tentou carregar), use o comando list-unit-files.

arquivos de unidade de lista systemctl

Unidades são representações de recursos que o systemd conhece. Como o systemd não lê necessariamente todas as definições de unidade, ele apenas apresenta informações sobre os próprios arquivos. A saída consiste em duas colunas: UNIT FILE e STATE.

ESTADO DO ARQUIVO DA UNIDADE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount estático
sys-kernel-debug.mount estático
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path ativado
. . .

Normalmente, a coluna STATE contém os valores ativados, desativados, estáticos ou mascarados. Nesse contexto, estático significa que não há seção de instalação no arquivo da unidade, que é usada para habilitar a unidade. Assim, essas unidades não podem ser habilitadas. Isso geralmente significa que a unidade executa uma ação única ou é usada apenas como dependência de outra unidade e não deve ser iniciada por si mesma.

Gerenciamento de unidade

Agora você sabe como trabalhar com serviços e exibir informações sobre unidades e arquivos de unidades que o systemd conhece. Você pode obter informações mais específicas sobre unidades usando alguns comandos adicionais.

Exibição de arquivo de unidade

Para exibir o arquivo de unidade que o systemd carregou, você pode usar o comando cat (adicionado na versão 209 do systemd). Por exemplo, para visualizar o arquivo de unidade do daemon de agendamento atd, você pode digitar:

systemctl cat atd.service
Descrição=daemon ATD
Tipo=bifurcação
ExecStart=/usr/bin/atd
WantedBy=multi-user.target

Na tela, você verá um arquivo unit que é conhecido pelo processo systemd atualmente em execução. Isso pode ser importante se você mudou seus arquivos de unidade recentemente, ou se estiver redefinindo algumas opções em um fragmento de arquivo de unidade (mais sobre isso depois).

Mapeamento de dependências

Para ver a árvore de dependências de uma unidade, use o comando:

systemctl list-dependencies sshd.service

Ele exibirá uma hierarquia de dependências com as quais o sistema precisa lidar para executar esta unidade. As dependências neste contexto são aquelas unidades necessárias para a operação de outras unidades que são superiores na hierarquia.

sshd.service
├─system.slice
└─basic.target
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─slices.target
. . .

Dependências recursivas são mostradas apenas para unidades .target que indicam estados do sistema. Para listar recursivamente todas as dependências, adicione o sinalizador --all.

Para mostrar dependências reversas (unidades que dependem de um elemento especificado), você pode adicionar o sinalizador --reverse ao comando. Os sinalizadores --before e --after também são úteis, eles exibem unidades que dependem da unidade especificada e são executadas antes ou depois dela.

Verificando as propriedades da unidade

Para ver as propriedades de baixo nível de uma unidade, você pode usar o comando show. Isso exibirá uma lista de propriedades para a unidade especificada no formato chave=valor.

systemctl show sshd.service
id=sshd.service
Nomes=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=Daemon do servidor OpenSSH
. . .

Para exibir uma das propriedades, passe o sinalizador -p e especifique o nome da propriedade. Por exemplo, para ver conflitos na unidade sshd.service, digite:

systemctl show sshd.service -p Conflitos
Conflicts=shutdown.target

disfarce de unidade

O Systemd pode bloquear uma unidade (automática ou manualmente) criando um link simbólico para /dev/null. Isso é chamado de mascaramento de unidade e é feito com o comando mask:

sudo systemctl mask nginx.service

Agora, o serviço Nginx não será iniciado automática ou manualmente enquanto o mascaramento estiver ativado.

Se você verificar list-unit-files, verá que o serviço está marcado como mascarado:

arquivos de unidade de lista systemctl
. . .
kmod-static-nodes.service static
ldconfig.service estático
mandb.service estático
messagebus.service estático
nginx.service mascarado
quotaon.service estático
rc-local.service estático
rdisc.service desativado
serviço de resgate estático
. . .

Se você tentar iniciar o serviço, receberá esta mensagem:

sudo systemctl start nginx.service
Falha ao iniciar nginx.service: a unidade nginx.service está mascarada.

Para desmascarar uma unidade e disponibilizá-la, use unmask:

sudo systemctl unmask nginx.service

Isso retornará o serviço ao seu estado anterior.

Editando arquivos de unidade

Embora o formato específico dos arquivos de unidade não seja discutido neste manual, o systemctl fornece mecanismos integrados para edição e modificação de arquivos de unidade. Essa funcionalidade foi adicionada na versão 218 do systemd.

O comando de edição abre o trecho de arquivo da unidade por padrão:

sudo systemctl editar nginx.service

Este será um arquivo vazio que pode ser usado para substituir ou adicionar diretivas à definição da unidade. Um diretório será criado no diretório /etc/systemd/system que contém o nome do dispositivo com o sufixo .d. Por exemplo, para nginx.service, o diretório nginx.service.d será criado.

Dentro deste diretório, um trecho chamado override.conf será criado. Quando a unidade for carregada, o systemd mesclará o trecho de substituição na memória com o restante do arquivo da unidade. As diretivas de snippet terão precedência sobre as especificadas no arquivo de unidade de origem.

Se você deseja editar todo o arquivo da unidade em vez de criar um trecho, pode passar o sinalizador --full:

sudo systemctl edit --full nginx.service

Isso carregará o arquivo da unidade atual no editor, onde poderá ser modificado. Quando o editor fechar, o arquivo modificado será gravado em /etc/systemd/system e terá precedência sobre a definição da unidade do sistema (geralmente localizada em algum lugar em /lib/systemd/system).

Para remover quaisquer adições feitas, remova o diretório config.d ou o arquivo de serviço modificado de /etc/systemd/system. Por exemplo, para remover um snippet, você pode digitar:

sudo rm -r /etc/systemd/system/nginx.service.d

Para excluir o arquivo editado completo, digite:

sudo rm /etc/systemd/system/nginx.service

Depois de excluir um arquivo ou diretório, o processo systemd deve ser recarregado para que o sistema não tente mais se referir a esses arquivos e volte a usar cópias do sistema. Para fazer isso, digite:

sudo systemctl daemon-reload

Alterando os níveis de execução

Alvos são arquivos de unidades especiais que descrevem níveis de sistema ou pontos de sincronização. Como outras unidades, os arquivos de destino podem ser identificados por um sufixo. Nesse caso, o sufixo .target é usado. Os alvos sozinhos não fazem nada, em vez disso, eles são usados ​​para agrupar outras unidades.

As metas podem ser usadas para levar o sistema a um determinado estado. Da mesma forma, outros sistemas init usam níveis de execução. Eles são usados ​​como referências quando determinados recursos estão disponíveis, permitindo que você especifique o estado desejado em vez de configurar as unidades individuais necessárias para criar esse estado.

Por exemplo, há um swap.target que é usado para indicar que o swap está pronto para ser usado. As unidades que fazem parte deste processo podem ser sincronizadas para este fim usando as diretivas WantedBy= ou RequiredBy=. As unidades que precisam de uma troca podem especificar essa condição por meio das especificações Wants=, Requires= ou After=.

Verificando e definindo metas padrão

O processo systemd tem um destino padrão que usa quando o sistema é inicializado. Fornecer um conjunto de dependências para esse único destino leva o sistema ao estado desejado. Para encontrar o destino padrão, digite:

systemctl get-default
multiusuário.alvo

Se você deseja definir um destino padrão diferente, pode usar set-default. Por exemplo, se você tiver uma área de trabalho gráfica instalada e quiser que o sistema a carregue por padrão, poderá alterar o destino de acordo:

sudo systemctl set-default graphic.target

Lista de alvos disponíveis

Você pode visualizar a lista de alvos disponíveis com o comando:

systemctl list-unit-files --type=target

Ao contrário dos níveis de execução, vários destinos podem ser ativados ao mesmo tempo. Um alvo ativo indica que o systemd tentará iniciar todas as unidades ligadas a esse alvo e não tentará desativá-las. Para ver todos os alvos ativos, digite:

systemctl list-units --type=target

Isolamento alvo

É possível iniciar todas as unidades associadas ao alvo e parar todas as unidades que não fazem parte da árvore de dependências. O comando de isolamento é usado para isso. É semelhante a alterar o nível de execução em outros sistemas init.

Por exemplo, se você estiver trabalhando em um ambiente gráfico onde o destino graphic.target está ativo, você pode desabilitar o sistema gráfico e colocar o sistema em um estado multiusuário linha de comando, isolando multi-user.target. Uma vez que graphic.target depende de multi-user.target, mas não vice-versa, todas as unidades gráficas serão interrompidas.

Você pode dar uma olhada nas dependências do alvo que está sendo isolado antes de fazer este procedimento para garantir que você não interrompa os serviços vitais:

systemctl list-dependencies multi-user.target

Se tudo lhe convier, você pode isolar o alvo:

sudo systemctl isolar multi-user.target

Abreviaturas

Existem destinos definidos para eventos importantes, como desligamento ou reinicialização. O systemctl também oferece vários atalhos para acesso rápido.

Por exemplo, para colocar o sistema no modo de depuração, você pode simplesmente inserir rescue em vez de isolar rescue.target:

sudo systemctl resgate

Isso fornecerá funcionalidade adicional - notificará todos os usuários do sistema sobre o evento.

Para interromper o sistema, você pode usar o comando halt:

sudo systemctl halt

Para iniciar um desligamento completo, você pode usar o comando poweroff:

sudo systemctl poweroff

Uma reinicialização pode ser iniciada com o comando reboot:

sudo systemctl reboot

Esses comandos notificarão os usuários do sistema sobre eventos, o que o comando padrão não fará. Observe que a maioria das máquinas usa comandos mais curtos para essas operações para fazê-las funcionar corretamente com o systemd.

Por exemplo, para reiniciar o sistema, basta digitar:

Conclusão

Agora você está familiarizado com os mecanismos básicos do systemctl e sabe como controlar o sistema init com esta ferramenta.

Embora o systemctl funcione principalmente com o processo systemd, existem outros componentes no sistema systemd que são controlados por outros utilitários. Por exemplo, daemons e utilitários separados são usados ​​para gerenciar o log e as sessões do usuário (journald/journalctl e logind/loginctl, respectivamente).