Systemctl para gerenciar serviços Systemd e Unidades

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 sudouma 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 systemdpara 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-unitscomando:

 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 --allsinalizador 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 quesystemd 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=valueformato:

 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 systemdtambé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 unmaskcomando:

 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, systemctlfornece 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.