como executar o script com um shell de login limpo

1

Estou conectado à máquina remota Linux RH6 diretamente via ssh (chave importada no servidor), quando executo um script shell com argumentos para reiniciar o serviço java, tenho um problema estranho com o ulimit:

  • quando executo manualmente ./script.sh stop;./catalina.sh start , vejo que o número de arquivos abertos não está OK (1024), conforme definido no arquivo de sistema limits.conf ;
  • quando uma tarefa semanal é executada, a qual eu configurei em cron , tenho o valor correto de limits.conf (16.384);
  • quando eu faço /bin/su - user e, em seguida, reinicio, tenho o valor correto
    também.

Eu preciso de uma solução para modificar o script para de alguma forma obter o valor do meu sistema e ter um shell de login real no script bash e ter o número correto de arquivos abertos quando eu precisar reiniciar o serviço manualmente.

Limite rígido para o shell atual:

ulimit -Ha
open files                      (-n) 4096

Global:

cat /etc/security/limits.conf
oracle hard nofile 16384

Problema: quando a tarefa do cron é executada, o número de arquivos abertos é 16384 bom !, quando executo o script do shell atual. /script.sh stop; ./script.sh start i tem 4096. A pergunta é como obter 16384 quando executo o script manualmente?

A edição em ps de bashrc e bash_profile com ulimit -n <number> não ajuda.

    
por klerk 04.05.2015 / 16:01

2 respostas

1

Apenas o root pode aumentar o limite rígido atual. Presumivelmente, o limite padrão para esse usuário, como definido em /etc/security/limits.conf , é 16384, mas há algo em um arquivo de inicialização que define o limite como 4096.

Se puder, altere este arquivo de inicialização para definir apenas o limite flexível. O limite flexível pode ser alterado em qualquer direção a qualquer momento por qualquer usuário, a única restrição é que não pode ser maior que o limite rígido. Ou seja, substitua ulimit -a 4096 por ulimit -Sa 4096 .

O que você está fazendo é desonesto de qualquer maneira. Você provavelmente não deve estar executando um shell como o usuário que executa o serviço, você deve fazer manutenção de sua conta, usando sudo para executar comandos com privilégios diferentes, conforme necessário. Então, para iniciar o serviço, você não deveria estar usando ./script.sh stop;./catalina.sh start , mas

sudo -u user ./script.sh stop; sudo -u user ./catalina.sh start

Isso não executará arquivos de inicialização que possam definir o limite.

Em princípio, é possível que a configuração do seu sistema defina limites diferentes, dependendo de como você efetua login, definindo regras diferentes via PAM ( /etc/pam.conf ou /etc/pam.d/* ). No entanto, isso seria uma configuração estranha e incomum.

    
por 06.05.2015 / 01:59
0

Em vez de executar manualmente ./script.sh stop;./catalina.sh start e separadamente ter um cronjob que faz o mesmo, use um script /etc/init.d/catalina que possa configurar todos os seus limites, env vars, etc; em seguida, para iniciar / parar, basta executar sudo /etc/init.d/catalina start (ou stop , restart , etc); ou, mais simplesmente (se disponível) sudo service catalina start (etc). É um erro propenso a iniciar / parar processos de env diferentes, como você encontrou; Colocar tudo em um script de inicialização ajudará a obter processos iniciados / interrompidos de forma consistente e limpa (e registrados corretamente).

Edite: e, se você não estiver usando sudo e não estiver usando scripts init, apenas escreva este mesmo script (como se estivesse criando um script de inicialização), mantenha-o em $HOME/bin (ou onde) e dentro deste script configure o env (limits, env vars, etc) conforme desejado; Chame isso de cron, o shell, ssh remoto, fantoche, etc. Mais tarde, se você quiser configurar isso como um serviço, como é tipicamente o caso, este trabalho já terá sido feito.

    
por 07.05.2015 / 09:03