Introdução
Systemd
é um gerenciador de sistema de inicialização e do sistema que é amplamente tornando-se o novo padrão para computadores com Linux. Embora existam opiniões consideráveis sobre se systemd
é uma melhoria ao longo dos tradicionais SysV
sistemas de inicialização é a substituição, a maioria das distribuições pretendemos adotá-la ou já o fizeram.
Devido à sua forte adoção, familiarizar-se com
systemd
é bem vale a pena, como ele vai fazer o gerenciamento desses servidores consideravelmente mais fácil. Conhecer e utilizar as ferramentas e daemons que compõem systemd
irá ajudá-lo a apreciar melhor o poder, flexibilidade e capacidades de que dispõe, ou pelo menos ajudá-lo a fazer o seu trabalho com o mínimo de confusão.
Neste guia, vamos discutir o
systemctl
comando, que é a ferramenta de gerenciamento central para controlar o sistema de inicialização. Nós vamos cobrir como gerenciar serviços, status de verificação, os estados do sistema mudança, e trabalhar com os arquivos de configuração.Gestão de Serviços
O objetivo fundamental de um sistema de inicialização é inicializar os componentes que devem ser iniciados após o kernel Linux é inicializado (tradicionalmente conhecido como componentes "userland"). O sistema de inicialização também é usado para gerenciar serviços e daemons para o servidor a qualquer momento enquanto o sistema está em execução. Com isso em mente, vamos começar com algumas operações de gerenciamento de serviços simples.
Em
systemd
, o alvo da maioria das ações são "unidades", que são recursos que systemd
sabe gerir. As unidades são classificados pelo tipo de recurso que representam e são definidas com arquivos conhecidos como arquivos de unidade. O tipo de cada unidade pode ser inferida a partir do sufixo no fim do ficheiro.
Para tarefas de gerenciamento de serviços, a unidade de destino será unidades de serviços, que têm arquivos de unidades com um sufixo de
.service
. No entanto, para a maioria dos comandos de gerenciamento de serviços, você pode realmente deixar de fora o .service
sufixo, como systemd
é inteligente o suficiente para saber que você provavelmente vai querer operar em um serviço ao usar comandos de gerenciamento de serviços.Iniciar e parar serviços
Para iniciar uma
systemd
serviço, executando instruções no arquivo de unidade do serviço, use ostart
de comando. Se você estiver executando como um usuário não-root, você terá que usar o sudo
uma vez que este irá afectar o estado do sistema operacional: sudo systemctl start application .service
Como mencionado acima,
systemd
sabe que procurar *.service
arquivos para os comandos de gerenciamento de serviços, portanto, o comando poderia facilmente ser digitado como este: sudo systemctl start application
Embora você possa usar o formato acima para administração geral, para maior clareza, vamos usar o
.service
sufixo para o restante dos comandos para ser explícito sobre o alvo estamos operando por diante.
Para parar um serviço em execução, você pode usar a
stop
de comando em vez disso: sudo systemctl stop application .service
Reiniciando e reinicializando
Para reiniciar um serviço em execução, você pode usar o
restart
comando: sudo systemctl restart application .service
Se a aplicação em questão é capaz de recarregar seus arquivos de configuração (sem reiniciar), você pode emitir o
reload
comando para iniciar esse processo: sudo systemctl reload application .service
Se você não tem certeza se o serviço tem a funcionalidade para recarregar sua configuração, você pode emitir o
reload-or-restart
comando. Isto irá recarregar a configuração no local, se disponível. Caso contrário, ele irá reiniciar o serviço para que a nova configuração é captado: sudo systemctl reload-or-restart application .service
Como ativar e desativar serviços
Os comandos acima são úteis para iniciar ou parar comandos durante a sessão atual. Para dizer
systemd
para iniciar os serviços automaticamente no boot, você deve habilitá-los.
Para iniciar um serviço no boot, utilize o
enable
comando: sudo systemctl enable application .service
Isto irá criar um link simbólico de cópia do sistema do arquivo de serviço (normalmente em
/lib/systemd/system
ou /etc/systemd/system
) para o local no disco onde systemd
procura por arquivos de inicialização automática (geralmente /etc/systemd/system/ some_target.target.wants
. Vamos repassar o que uma meta é mais adiante neste guia).
Para desativar o serviço seja iniciado automaticamente, você pode digitar:
sudo systemctl disable application .service
Isto irá remover o link simbólico que indica que o serviço deve ser iniciado automaticamente.
Tenha em mente que permitir que um serviço não iniciá-lo na sessão atual. Se você deseja iniciar o serviço e habilitá-lo no boot, você terá que emitir tanto o
start
e enable
comandos.Verificando o status de Serviços
Para verificar o status de um serviço em seu sistema, você pode usar o
status
comando: systemctl status application .service
Isto irá fornecer-lhe com o estado do serviço, a hierarquia cgroup, e as primeiras linhas de log.
Por exemplo, ao verificar o status de um servidor Nginx, você poderá ver uma saída como esta:
● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled) Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago Main PID: 495 (nginx) CGroup: /system.slice/nginx.service ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr; └─496 nginx: worker process Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server... Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.
Isso lhe dá uma boa visão geral do status atual da aplicação, notificando-o de todos os problemas e quaisquer ações que possam ser necessárias.
Existem também métodos para a verificação de estados específicos. Por exemplo, para verificar se a unidade está ativa (em execução), você pode usar o
is-active
comando: systemctl is-active application .service
Isto fará voltar o estado de unidade actual, que é geralmente
active
ou inactive
. O código de saída será "0" se ele estiver ativo, tornando o resultado mais simples para analisar programaticamente.
Para ver se a unidade for ativada, você pode usar o
is-enabled
comando: systemctl is-enabled application .service
A saída será se o serviço está
enabled
ou disabled
e voltará a definir o código de saída para "0" ou "1", dependendo da resposta à pergunta de comando.
Um terceiro é verificar se a unidade está em um estado de falha. Isto indica que existe um problema ao iniciar o aparelho em causa:
systemctl is-failed application .service
Isso irá retornar
active
se estiver a funcionar correctamente ou failed
se ocorreu um erro. Se a unidade foi intencionalmente parou, ele pode retornar unknown
ou inactive
. Um status de saída "0" indica que ocorreu uma falha e um status de saída "1" indica qualquer outro status.Visão Geral do Sistema Estado
Os comandos até agora têm sido úteis para o gerenciamento de serviços individuais, mas eles não são muito úteis para explorar o estado atual do sistema. Há uma série de
systemctl
comandos que fornecem essas informações.Listagem Unidades atuais
Para ver uma lista de todas as unidades ativas que
systemd
conhece, podemos usar o list-units
comando: systemctl list-units
Isto irá mostrar uma lista de todas as unidades que
systemd
tem atualmente ativo no sistema. A saída será algo parecido com isto: UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running ATD daemon avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack dbus.service loaded active running D-Bus System Message Bus dcron.service loaded active running Periodic Command Scheduler dkms.service loaded active exited Dynamic Kernel Modules System getty@tty1.service loaded active running Getty on tty1 . . .
A saída possui as seguintes colunas:
- UNIT: O
systemd
nome da unidade - LOAD: Se a configuração da unidade foi analisado pelo
systemd
. A configuração de unidades carregadas é mantido na memória. - ACTIVE: Um estado de resumo sobre se a unidade está ativa. Isso geralmente é uma maneira bastante básico para dizer se a unidade foi iniciado com êxito ou não.
- SUB: Este é um estado de nível inferior que indica informações mais detalhadas sobre a unidade.Isso muitas vezes varia por tipo de unidade, estado, eo método real em que a unidade funciona.
- DESCRIPTION: Uma descrição textual aquém do que a unidade é / faz.
Uma vez que a
list-units
comando mostra apenas as unidades ativas, por padrão, todas as entradas acima irá mostrar "carregado" na coluna de carga e "ativo" na coluna ACTIVE. Esta exposição é, na verdade, o comportamento padrão do systemctl
quando chamado sem comandos adicionais, assim que você vai ver a mesma coisa se você chamar systemctl
sem argumentos: systemctl
Podemos dizer
systemctl
para a saída de informações diferentes, adicionando bandeiras adicionais.Por exemplo, para ver todas as unidades que systemd
foi carregado (ou tentou carregar), independentemente de se eles estão ativos, você pode usar o --all
bandeira, como este: systemctl list-units --all
Isto irá mostrar qualquer unidade que
systemd
carregado ou tentou carregar, independentemente do seu estado atual no sistema. Algumas unidades se tornam inativos após a execução, e algumas unidades que systemd
tentou carregar pode não ter sido encontrado no disco.
Você pode usar outras bandeiras para filtrar esses resultados. Por exemplo, podemos usar o
--state=
sinalizador para indicar os estados CARGA, ativo ou SUB que deseja ver. Você terá que manter o --all
sinalizador para que systemctl
permite que as unidades não activos a ser exibido: systemctl list-units --all --state=inactive
Outro filtro comum é o
--type=
filtro. Podemos dizer systemctl
somente unidades do tipo que estamos interessados em exibição Por exemplo, para ver as unidades do serviço apenas ativos, nós podemos usar.: systemctl list-units --type=service
Listando todos os arquivos da unidade
A
list-units
de comando exibe apenas unidades que systemd
tentou analisar e carregar na memória. Desde systemd
só vai ler unidades que acha que precisa, isso não vai necessariamente incluir todas as unidades disponíveis no sistema. Para ver todos os arquivos da unidade disponíveis dentro dossystemd
caminhos, incluindo aqueles que systemd
não tentou carregar, você pode usar os list-unit-files
de comando em vez disso: systemctl list-unit-files
Unidades são representações de recursos que
systemd
conhece. Desde systemd
não necessariamente ler todas as definições de unidade neste ponto de vista, só apresenta informações sobre os próprios arquivos. A saída tem duas colunas: o arquivo de unidade e o estado. UNIT FILE STATE 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 static sys-kernel-debug.mount static tmp.mount static var-lib-nfs-rpc_pipefs.mount static org.cups.cupsd.path enabled . . .
O estado geralmente será "ativado", "deficientes", "estático", ou "mascarado". Neste contexto, estática significa que o arquivo unidade não contém uma secção de "instalar", que é usado para activar uma unidade. Como tal, estas unidades não pode ser ativado. Geralmente, isto significa que a unidade efectua uma acção de uma única vez ou é utilizado apenas como uma dependência de outra unidade e não deve ser administrado por si só.
Nós vamos cobrir o que "mascarada" significa momentaneamente.
Gestão de unidade
Até agora, temos vindo a trabalhar com os serviços e exibir informações sobre os arquivos e unidade que
systemd
conhece. No entanto, podemos encontrar informações mais específicas sobre as unidades que usam alguns comandos adicionais.Exibindo um arquivo Unit
Para exibir o arquivo de unidade que
systemd
foi carregado no seu sistema, você pode usar o cat
de comando (este foi adicionado em systemd
versão 209). Por exemplo, para ver o arquivo unidade doatd
daemon programação, poderíamos escrever: systemctl cat atd.service
[Unit] Description=ATD daemon [Service] Type=forking ExecStart=/usr/bin/atd [Install] WantedBy=multi-user.target
A saída é o ficheiro de unidade como é conhecido na actualmente em execução
systemd
processo. Isso pode ser importante se você tiver modificado arquivos da unidade recentemente ou se você está substituindo determinadas opções em um fragmento de arquivo de unidade (que vai cobrir isso mais tarde).Exibindo Dependências
Para ver árvore de dependência de uma unidade, você pode usar a
list-dependencies
comando: systemctl list-dependencies sshd.service
Isto irá exibir uma hierarquia mapear as dependências que devem ser tratadas com a fim de iniciar a unidade em questão. Dependências, neste contexto, incluem as unidades que são ou necessárias ou que queriam pelas unidades acima dela.
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 . . .
As dependências recursivas são exibidos apenas para
.target
unidades, que indicam estados do sistema. Para listar recursivamente todas as dependências, inclua o --all
bandeira.
Para mostrar dependências reversas (unidades que dependem da unidade especificada), você pode adicionar o
--reverse
sinalizador para o comando. Outras opções que são úteis são a --before
e --after
sinalizadores, que pode ser usado para mostrar unidades que dependem da unidade especificada, começando antes e depois de si, respectivamente.Verificação das propriedades da unidade
Para ver as propriedades de baixo nível de uma unidade, você pode usar o
show
comando. Isto irá exibir uma lista de propriedades que estão definidas para a unidade especificada usando uma key=value
formato: systemctl show sshd.service
Id=sshd.service Names=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=OpenSSH server daemon . . .
Se você quiser exibir uma única propriedade, você pode passar o
-p
bandeira com o nome da propriedade. Por exemplo, para ver os conflitos que o sshd.service
unidade tem, você pode digitar: systemctl show sshd.service -p Conflicts
Conflicts=shutdown.target
Mascaramento e Unmasking Units
Vimos na seção de gerenciamento de serviços como parar ou desativar um serviço, mas
systemd
também tem a capacidade de marcar uma unidade tão completamente unstartable, automaticamente ou manualmente, ligando-o a /dev/null
. Isto é chamado de mascaramento da unidade, e é possível com amask
de comando: sudo systemctl mask nginx.service
Isso irá impedir que o serviço seja iniciado Nginx, manual ou automaticamente, durante o tempo que ele é mascarado.
Se você verificar as
list-unit-files
, você vai ver o serviço agora está listado como mascarada: systemctl list-unit-files
. . . kmod-static-nodes.service static ldconfig.service static mandb.service static messagebus.service static nginx.service masked quotaon.service static rc-local.service static rdisc.service disabled rescue.service static . . .
Se você tentar iniciar o serviço, você verá uma mensagem como esta:
sudo systemctl start nginx.service
Failed to start nginx.service: Unit nginx.service is masked.
Para desmascarar uma unidade, tornando-o disponível para uso novamente, basta usar a
unmask
comando: sudo systemctl unmask nginx.service
Isso irá retornar a unidade ao seu estado anterior, permitindo-lhe ser habilitado.
Edição de arquivos Unit
Enquanto o formato específico para arquivos de unidade está fora do escopo deste tutorial,
systemctl
fornece mecanismos integrado para editar e modificar os arquivos da unidade se você precisar fazer ajustes. Esta funcionalidade foi adicionada no systemd
versão 218.
A
edit
de comando, por padrão, será aberto um trecho de arquivo de unidade para a unidade em questão: sudo systemctl edit nginx.service
Este será um arquivo em branco que pode ser usado para substituir ou adicionar diretrizes para a definição da unidade. Um diretório será criado dentro da
/etc/systemd/system
diretório que contém o nome da unidade com .d
anexado. Por exemplo, para o nginx.service
, um diretório chamadonginx.service.d
será criado.
Dentro deste diretório, um trecho será criado chamado
override.conf
. Quando o aparelho é carregado, systemd
vai, na memória, mesclar o trecho de substituição com o arquivo unidade completa.directivas do snippet terá precedência sobre os encontrados no arquivo unidade original.
Se você deseja editar o arquivo unidade completa em vez de criar um trecho, você pode passar o
--full
bandeira: sudo systemctl edit --full nginx.service
Isto irá carregar o arquivo de unidade atual para o editor, onde ele pode ser modificado. Ao sair do editor, o arquivo alterado será gravado em
/etc/systemd/system
, que terá precedência sobre definição de unidade do sistema (geralmente encontrado em algum lugar /lib/systemd/system
).
Para remover todas as adições que você tenha feito, exclua da unidade
.d
diretório de configuração ou o arquivo de serviço modificado a partir de /etc/systemd/system
. Por exemplo, para remover um trecho, podemos escrever: sudo rm -r /etc/systemd/system/nginx.service.d
Para remover um arquivo unidade modificada completo, deve digitar:
sudo rm /etc/systemd/system/nginx.service
Depois de excluir o arquivo ou pasta, você deve recarregar o
systemd
processo para que ele não tenta fazer referência a esses arquivos e reverte para usando o sistema copia. Você pode fazer isso digitando: sudo systemctl daemon-reload
Ajustar o Estado do Sistema (Nível de Execução) com Targets
Os alvos são arquivos de unidade especial que descrevem um ponto estado do sistema ou sincronização.Como outras unidades, os arquivos que definem os alvos podem ser identificados pela sua sufixo, que neste caso é
.target
. Alvos não fazem muito a si mesmos, mas são usadas para agrupar outras unidades em conjunto.
Isto pode ser utilizado, a fim de trazer o sistema para certos estados, bem como outros sistemas de inicialização usar níveis de execução. Eles são usados como referência para quando certas funções estão disponíveis, permitindo que você especifique o estado desejado, em vez de as unidades individuais necessárias para produzir esse estado.
Por exemplo, há um
swap.target
que é usado para indicar que troca está pronto para uso. Unidades que fazem parte deste processo pode sincronizar com esta meta, indicando na sua configuração que eles são WantedBy=
ou RequiredBy=
o swap.target
. Unidades que requerem troca de estar disponível pode especificar esta condição usando os Wants=
, Requires=
, e After=
especificações para indicar a natureza de seu relacionamento.Obter e definir o destino padrão
O
systemd
processo tem um destino padrão que ele usa durante a inicialização do sistema. Satisfazendo a cascata de dependências a partir desse único alvo vai trazer o sistema para o estado desejado. Para encontrar o destino padrão para o seu sistema, digite: systemctl get-default
multi-user.target
Se você deseja estabelecer uma meta padrão diferente, você pode usar o
set-default
. Por exemplo, se você tem um desktop gráfico instalado e você desejar o sistema para inicializar em que, por padrão, você pode mudar seu destino padrão em conformidade: sudo systemctl set-default graphical.target
Listagem Destinos Disponíveis
Você pode obter uma lista dos alvos disponíveis no seu sistema digitando:
systemctl list-unit-files --type=target
Ao contrário de níveis de execução, alvos múltiplos podem estar ativos ao mesmo tempo. Um alvo ativa indica que
systemd
tentou começar a todas as unidades ligadas ao alvo e não tentou derrubá-las novamente. Para ver todos os alvos ativos, digite: systemctl list-units --type=target
isolando Targets
É possível iniciar todas as unidades associadas com um alvo e parar todas as unidades que não são parte da árvore de dependência. O comando que nós precisamos de fazer isso é chamado, apropriadamente,
isolate
. Isto é semelhante ao alterar o nível de execução em outros sistemas de inicialização.
Por exemplo, se você estiver operando em um ambiente gráfico com
graphical.target
ativa, você pode desligar o sistema gráfico e colocar o sistema em um estado de linha de comando multi-utilizador, isolando o multi-user.target
. Desde graphical.target
depende multi-user.target
mas não o contrário, todas as unidades gráficas será interrompido.
Você pode querer dar uma olhada nas dependências do alvo que você está isolando antes de realizar este procedimento para garantir que você não está parando serviços vitais:
systemctl list-dependencies multi-user.target
Quando estiver satisfeito com as unidades que serão mantidos vivos, você pode isolar o alvo digitando:
sudo systemctl isolate multi-user.target
Usando atalhos para eventos importantes
Há metas definidas para eventos importantes como desligar ou reiniciar. No entanto,
systemctl
também tem alguns atalhos que adicionar um pouco de funcionalidade adicional.
Por exemplo, para colocar o sistema no modo de recuperação (de um único usuário), você pode simplesmente usar o
rescue
comando em vez de isolate rescue.target
: sudo systemctl rescue
Isto irá fornecer a funcionalidade adicional de alertar todos os usuários logados sobre o evento.
Para parar o sistema, você pode usar o
halt
comando: sudo systemctl halt
Para iniciar um desligamento completo, você pode usar o
poweroff
comando: sudo systemctl poweroff
Uma reinicialização pode ser iniciado com a
reboot
de comando: sudo systemctl reboot
Todos estes alerta usuários logados que o evento está ocorrendo, algo que simplesmente executando ou isolar o alvo não vai fazer. Note-se que a maioria das máquinas vai ligar os comandos mais curtos, mais convencionais para estas operações para que eles funcionem corretamente com
systemd
.
Por exemplo, para reiniciar o sistema, normalmente você pode digitar:
sudo reboot
Conclusão
Até agora, você deve estar familiarizado com alguns dos recursos básicos do
systemctl
comando que lhe permitem interagir com e controlar o seu systemd
instância. O systemctl
utilitário será o seu principal ponto de interação para gerenciamento de serviços e sistema estatal.
Enquanto
systemctl
opera principalmente com o núcleo systemd
processo, existem outros componentes para o systemd
ecossistema que são controladas por outros utilitários. Outros recursos, como sessões de gerenciamento de log e de usuário são manipulados por daemons separados e utilitários de gerenciamento ( journald
/ journalctl
e logind
/ loginctl
respectivamente). Ter tempo para se familiarizar com esses outros instrumentos e daemons farão a gestão uma tarefa mais fácil.
Nenhum comentário:
Postar um comentário