SysV scripts init para migração do systemd no RHEL7

Navegue suas respostas
1

Por favor, encontre os scripts Sys V Init para o agente (Agente de processos do usuário) e o daemon de segurança no Linux.

  1. Script de inicialização do Daemon do agente /etc/rc.d/init.d/Agentdaemon /etc/rc.d/rc5.d/S91Agentdaemon

  2. Script de inicialização do Daemon de segurança /etc/rc.d/init.d/Securitydaemon /etc/rc.d/rc5.d/S91Securitydaemon

Vamos supor que os daemons agent e securiy precisam de um pai comum, o common agent. Se o agente comum não for iniciado no momento da reinicialização, qualquer um dos outros daemons iniciará o agente comum e o outro daemon pule para iniciar o agente comum. Há uma verificação de comando 'ps' para ver se o agente comum está em execução ou não para ignorar a criação nos scripts Agentdaemon e Securitydaemon. Isso funcionou bem no RHEL 6.2. Mas no RHEL 7, estou vendo dois agentes comuns sendo executados.

E também duvido que o systemd tenha iniciado o agente e o daemon de segurança paralelamente. De alguma forma, 'ps' não mostrou o agente comum em execução.

Ex: ps -ef | grep common | grep -v grep | O awk '{print $ 2}' não está mostrando o processo comum iniciado por outro script e, portanto, o outro script também inicia o agente comum.

Existe alguma maneira de evitar que os scripts de inicialização sejam executados em paralelo ou devo migrar os scripts para o formato systemd? A solução rápida é mais interessante do que migrar todos os scripts do tipo de inicialização do Sys V para o systemd.

    
por Srikanth Ganesan 02.06.2015 / 11:32

1 resposta

2

Should I migrate the scripts to systemd format?

Sim.

Você está sendo mordido por uma falha bem conhecida nos scripts System 5 rc . Não é realmente nada a ver com o systemd. Você poderia ter atingido a falha se tivesse conseguido iniciar os scripts em paralelo de alguma outra forma, como por exemplo com startpar .

É bem conhecido que o grepping da saída de ps é propenso a raças, tanto contra grep quanto contra o estado do sistema em andamento, e pode-se encontrar décadas de pessoas relatando acertar essas mesmas falhas e mais uma vez com scripts de shell diferentes. É maluco e equivocado, e mencionado na seção "BUGS" da página de manual do BSD para ps . O mundo deveria saber melhor agora.

O mundo sabe melhor e já existe há algum tempo. Tivemos gerenciadores de serviço que funcionam corretamente, sem todos esses mecanismos que envolvem a lista de processos e arquivos que podem ou não conter o número correto, desde o início dos anos 90. Você deve definitivamente , se você está sendo atingido por esta e outras condições de corrida, jogue fora esses scripts System 5 rc frágeis, propensos a falhas, idiossincráticos e confusos e use o gerenciamento de serviço adequado. Nenhum ifs; Sem desculpas; não há "soluções rápidas" nas caixas que você já está usando (os grep s extras sendo eles mesmos uma loja em primeiro lugar).

Existem muitos desses gerenciadores de serviços disponíveis. Você não tem para usar o systemd. Os vários scripts que alguém escreveria para runit, nosh ou perp são tão simples quanto os arquivos unitários que se escreveria para o systemd.

Na maneira mais prática e sistemática de fazer as coisas, você não tem os dois serviços principais procurando e executando o secundário. Esse é o trabalho do sistema de gerenciamento de serviços. Em vez disso, simplesmente declara uma dependência dos dois serviços primários no secundário, para que o sistema de gerenciamento de serviços saiba que, quando for solicitado a iniciar Agentdaemon.service e Securitydaemon.service , ele deverá iniciar common.service também. Em unidades de serviço do systemd, isso seria uma configuração Requires= ou Wants= .

Leitura adicional

por 03.06.2015 / 21:20

Tags

Não é possível conectar-se ao ssh A placa wireless 6300 da Intel não funciona no CentOS 7 - funcionou durante a instalação!