Como iniciar automaticamente serviços na inicialização no RHEL / CentOS 7?

Pensando em como gerenciar serviços em segundo plano ou na inicialização?


O mecanismo para gerenciar e iniciar processos na inicialização foi alterado. Até o RHEL / CentOS 6.x, você teria criado um script em /etc/init.d/ e ativado com a ajuda do chkconfig, mas as coisas são diferentes em RHEL 7.

Ele é substituído pelo systemd e, como é mais ou menos o gerenciador de processos padrão nas principais versões do Linux, o System Admin versado em outros sabores se sentirá em casa. Neste artigo, exploraremos o que é systemd, quais foram as razões para o switch e como usá-lo para configurar, executar e gerenciar processos em segundo plano com ele.

O que é systemd?

Como todo processo no Linux é visível de forma transparente, vamos ver onde o systemd está à espreita. No meu sistema, recebo o seguinte:

~ $ ps -ef | grep systemd
raiz 1 0 0 Nov11? 00:01:02 / lib / systemd / systemd –system –deserialize 22
mensagem + 768 1 0 nov11? 00:05:46 / usr / bin / dbus-daemon –system –address = systemd: –nofork –nopidfile –systemd-activation –syslog-only
root 805 1 0 Nov11? 00:10:22 / lib / systemd / systemd-logind
ankush 1132 1 0 nov11? 00:00:00 / lib / systemd / systemd –user
ankush 1176 1132 0 nov11? 00:04:50 / usr / bin / dbus-daemon –session –address = systemd: –nofork –nopidfile –systemd-activation –syslog-only
ankush 9772 20029 0 21:11 pts / 6 00:00:00 grep –color = auto systemd
systemd + 17298 1 0 nov19? 00:00:12 / lib / systemd / systemd-resolved
systemd + 17303 1 0 nov19? 00:00:00 / lib / systemd / systemd-timesyncd
root 17307 1 0 Nov19? 00:00:02 / lib / systemd / systemd-journald
raiz 18182 1 0 Nov19? 00:00:00 / lib / systemd / systemd-udevd

Aposto que você percebeu instantaneamente. o primeiro processo na listagem foi lançado como raiz do usuário e possui o pid 1.

Com certeza, esse foi o primeiro processo que o sistema iniciou na inicialização. Diga olá ao systemd. ��

Portanto, simplesmente, systemd é o processo “mãe” que inicia, gerencia e encerra outros processos no sistema, além de fornecer informações sobre o log, status do sistema de arquivos, etc..

Uma nota sobre o nome, no entanto. O nome é realmente systemd e não System D ou qualquer outra coisa. O “d” significa daemon, um processo padrão do Linux que funciona (se esconde?) Em segundo plano e não está anexado a nenhuma sessão do terminal.

Por que o RHEL mudou para systemd?

Como já discutimos, o systemd é um gerenciador de sistemas e processos e, no RHEL 7, substitui o conhecido programa Upstart. Por que o RHEL (Oracle?) Tomou essa decisão? Bem, existem boas razões para isso, então vamos dar uma olhada rápida.

Inicialização de serviço paralelo

Diferentemente do programa init do SysV, o systemd é capaz de iniciar serviços em paralelo. O programa init, por outro lado, lança-os um por um. Em uma época em que até dispositivos móveis possuem CPUs com vários núcleos, a falta de inicialização paralela é um grande problema..

Gerenciamento de serviço dinâmico (quente)

Se você notou que as unidades USB precisam ser montadas explicitamente nos sistemas Fedora anteriores, enquanto elas se abrem automaticamente no Ubuntu e em distribuições similares, o motivo é systemd. É capaz de detectar alterações ao vivo no hardware e finalizar / iniciar serviços, conforme necessário. Alguns podem argumentar que é desnecessário, mas para muitos, qualquer coisa que reduza a carga cognitiva é bem-vinda.

Lançamento de serviço diferido

O systemd reduz o tempo de inicialização, pois adia o lançamento do serviço para quando é realmente necessário. Um exemplo simples são os serviços relacionados ao sistema de arquivos de rede. Se não houver disco em rede disponível, não faz sentido ter um serviço instalado e em execução.

Comunicação de processo mais rápida

Os recursos paralelos do systemd são transferidos para a comunicação entre processos. O systemd pode oferecer acesso paralelo a soquetes e barramento do sistema, reduzindo significativamente os tempos de espera do processo para recursos de comunicação.

Reinício automático

Se um serviço falhar, o systemd poderá detectá-lo e tentar reiniciá-lo. Na maioria das vezes, basta uma reinicialização simples para que um aplicativo comece a funcionar novamente, a menos que haja problemas mais fundamentais.

De qualquer forma, o systemd facilita a vida de um administrador de sistemas aqui.

systemd no RHEL7 – O que muda para os administradores de sistemas?

Se você tem uma sensação incômoda de que o sistema não será totalmente sinistro, você está certo. Existem algumas incompatibilidades significativas que podem pegar o RHEL sysadmin de surpresa. Vamos dar uma olhada rápida.

Suporte limitado ao nível de execução

O systemd tem um reconhecimento e um gasto bastante ruins de níveis de execução. Nem todos os níveis de execução são suportados e, para alguns destinos, pode até não haver nenhum. Nesses casos, o systemd retorna “N” como uma resposta aos comandos do nível de execução, significando que ele não possui um nível de execução correspondente a este destino. Em suma, a Red Hat nos aconselha a não usar (!) Os comandos runlevel.

Nenhum comando personalizado

Este vai doer. Uma grande vantagem do SysV foi a capacidade de definir comandos personalizados para fornecer melhor funcionalidade ao gerenciamento de processos. Com o systemd, não existe essa opção e você fica preso com iniciar, parar, status, reiniciar etc..

Somente para família e não interativo

O systemd (é claro) mantém um controle dos processos lançados e armazena seus PIDs. O desafio, no entanto, é que o systemd não pode lidar com processos não lançados por ele. Além disso, não é possível que um usuário interaja com um processo iniciado pelo systemd. Toda a saída vai para / dev / null, efetivamente interrompendo todas as esperanças que você possa ter de capturar a saída.

Sem contexto

Diferentemente dos serviços init, aqueles iniciados pelo systemd não herdam nenhum ambiente de nenhum usuário no sistema. Em outras palavras, informações como PATH e outras variáveis ​​do sistema não estão disponíveis e todo novo processo é iniciado em um contexto vazio.

Se essa lista de limitações fizer você chorar, novamente, você não está sozinho. O systemd tem sido uma força polarizadora no mundo do Linux, e pesquisar no “systemd sucks” descobrirá bastante material de leitura. ��

Como iniciar o serviço automaticamente quando inativo?

Aqui está um caso de uso bastante comum em implantações. Precisamos daemonizar um programa em uma linguagem que não tenha processos de execução longa: PHP! Vamos supor que eu escreva um script PHP para lidar com as conexões de entrada do websocket (criamos um aplicativo de bate-papo, afinal!) E o script é colocado em /home/ankush/chat_server/index.php.

Como as conexões do websocket podem atingir o servidor a qualquer momento, esse processo precisa estar sempre ativo e monitorar as conexões de entrada. Não podemos ter o ciclo de vida tradicional do PHP aqui porque os WebSockets são conexões com estado e, se o script morrer, a conexão será uma lista. Enfim, o suficiente em websockets; vamos ver como iremos daemonizar esse script via systemd.

Todos os serviços systemd residem em / etc / systemd / system, então vamos criar um arquivo para descrever o script do servidor websocket. Supondo que você esteja logado como usuário root.

# vi /etc/systemd/system/chat_server.service

e então o seguinte é necessário.

[Unidade]
Descrição = Serviço do Servidor de Chat
Depois = network.target

[Serviço]
Tipo = simples
Usuário = ankush
ExecStart = php /home/ankush/chat_server/index.php
Reiniciar = na interrupção

[Instalar]
WantedBy = multi-user.target

Salve o arquivo e a próxima etapa é recarregar o daemon systemd

# systemctl daemon-reload

e para iniciar o serviço que acabamos de criar:

# systemctl start chat_server

Se você não vê erros, foi isso!

Vamos dar uma olhada rápida no significado das várias diretivas no arquivo:

  • A parte [Unit] define uma nova unidade de serviço para systemd. Na linguagem do sistema, todos os serviços são conhecidos como unidades de serviço.
  • A diretiva After (previsivelmente) diz ao systemd para iniciar este serviço somente após o lançamento dos serviços de rede (caso contrário, quem fará o tratamento de nível mais baixo das conexões de soquete ?!).
  • O Type = simple informa ao systemd que esse serviço não deve se bifurcar-se. Em outras palavras, apenas uma instância estará em execução a qualquer momento.
  • Usuário = ankush significa que este serviço será executado como o usuário “ankush”. Nós podemos mudar isso para “root”, mas é altamente recomendado do ponto de vista da segurança.
  • ExecStart, como você pode ver, é o comando real a ser executado.
  • Reiniciar = na interrupção significa que o serviço deve ser reiniciado quando for interrompido. No PHP, processos de longa execução vazam memória e eventualmente explodem, portanto, isso é necessário.
  • A diretiva WantedBy = informa ao systemd de qual destino (pense em grupos) esse serviço faz parte. Isso resulta na criação de links simbólicos dentro desse destino para apontar para o serviço.

Geralmente, isso é suficiente para executar processos em segundo plano usando systemd no RHEL 7.

Mais opção para Reiniciar lógica

No exemplo acima, configurei Reiniciar = na interrupção, mas essa não é a única opção. Há mais e escolha com base na exigência.

  • em falha – será reiniciado quando o código ou sinal de saída não limpo
  • sempre – reinicie quando encontrado, sinal limpo ou sujo
  • anormal – sinal sujo, watchdog ou timeout
  • com sucesso – somente quando foi parado por um sinal limpo ou código de saída

Configurando o serviço para iniciar na inicialização

Quando estiver satisfeito com o script e garantir que ele funcione, em seguida, você deseja configurá-lo para que seja acionado na inicialização e inicie.

Vá para / etc / systemd / system e execute o comando enable abaixo (não esqueça de alterar o nome do arquivo .service pelo nome que você possui)

# systemctl enable chat_server.service

Você verá uma confirmação de que ele criou um link simbólico.

Criou o link simbólico de /etc/systemd/system/multi-user.target.wants/chat_server.service para /etc/systemd/system/chat_server.service.

Reinicie o servidor e você verá o serviço iniciar na inicialização.

Essa foi fácil! Não é?

Socorro! Eu investi maciçamente no Upstart. ��

Entendo que você confia em mim, seu caso é a norma e não a exceção. O RHEL usa o Upstart há tanto tempo que o switch quase parece uma traição. Mas ei, os sistemas continuam mudando, e não devemos brigar por ninharias. A Red Hat reconhece que muitas pessoas estão presas a versões mais antigas e criaram um guia de migração que você definitivamente deveria se referir.

Uma graça salvadora em tudo isso é que systemd é compatível com os scripts de inicialização do SysV; portanto, na maioria das vezes, você simplesmente precisa mover seus arquivos e executar os mesmos serviços.

Interessado em aprender mais sobre Administração e Solução de Problemas do Linux? Veja isso curso online.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map