Aciona um script de inicialização quando um dispositivo específico está ativo e um módulo do kernel foi carregado

Question

Nos meus servidores Ubuntu 12.04, eu preciso escrever um script init.d que aguarde até a interface infiniband (device: mlx4_0 , interface: ib0 ) está completamente ativo, e até que o módulo do kernel knem seja carregado.

Eu tenho um script init.d que funciona se eu esperar até que o sistema esteja ativo e service myscript start manualmente, mas isso não funcionará se eu carregá-lo normalmente no momento da inicialização. Estou usando a ordem de inicialização 99 , mas ela não inicia corretamente porque eu preciso esperar até que esses recursos estejam em execução.

Qual é a sintaxe correta em um init.d para conseguir isso (um módulo do kernel e)? Eu acho que deve haver alguma palavra-chave como # Required-Start: $remote_fs $syslog $network , mas não consigo encontrar as corretas para interface específica e módulos do kernel.

Como plano de fundo: o script de inicialização está relacionado às interações SLURM , openMPI e infiniband . Eu compilei SLURM com o suporte do Mellanox infiniband driver , e openMPI está vinculada a esta versão do SLURM. O resultado é que o openMPI está usando diretamente o driver infiniband do mellanox, que é muito mais poderoso que o ipob (ip over inifiniband). Para fazer isso, ele precisa usar a memória registrada do sistema, que deve ser definida como ilimitado .

SO:

Eu adicionei algumas logger de saídas no meu script init.d . Percebo que, de fato, os módulos estão funcionando. Então eu não entendo completamente o problema. É estranho, talvez relacionado a algumas variáveis de ambiente necessárias e que são configuradas apenas em um espaço de usuário completo e não no momento do init.

O problema diz respeito aos limites de memlock definidos em /etc/security/limits.conf . Para fazer isso funcionar eu tive que definir

*             -   memlock       unlimited
root          -   memlock       unlimited

e desta forma, quando eu lanço o deamon slurm com uma conexão ssh tudo funciona, e quando é o processo init que inicia o daemon, é como se ele não considerasse as regras em /etc/security/limits.conf .

    

Answer 1

Eu não sei especificamente sobre um arquivo init.d , mas uma regra de udev para executar um script em um dispositivo add pode ser semelhante:

ACTION=="add", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", RUN+="/path/to/executable"

Você deve investigar em udevadm para saber mais sobre como o dispositivo é normalmente adicionado e seus módulos carregados. Você também encontrará os valores corretos para VID e PID .

Aceita uma combinação do dispositivo e do módulo do kernel?

Sim. Bem não. Talvez? A resposta a essa pergunta depende inteiramente do nível em que você intercepta o dispositivo. udev tem que fazer muitas coisas desde o ponto em que inicialmente detecta um dispositivo até o ponto em que ele carregou e inicializou completamente o dispositivo e pode ser considerado para cima .

Algumas dessas coisas são prováveis:

• detectando inicialmente o hardware em seu barramento / dispositivo / subsistema pai

• encontrando e carregando o módulo do kernel apropriado

• preenchendo o sistema de arquivos /dev devfs com o arquivo especial de dispositivo apropriado

• detectando qualquer dispositivo filho que o dispositivo atual adicione e enxague, repita

Você pode especificar uma regra para todos ou alguns desses níveis de ação. Você também pode udevadm trigger ou monitor ou várias outras coisas diretamente em tempo real para determinar exatamente quais podem ser esses níveis de ação.

Eu recomendo que você analise atentamente esta informação se quiser se familiarizar com ela.

    

Answer 2

Use um trabalho Upstart para isso:

# Ensures that the device is up and filesystem is too
start on filesystem and net-device-up IFACE=ib0
stop on runlevel [016]

# Ensures that module is loaded
pre-start exec modprobe -q knem

exec /path/to/exec