Ulicitos práticos

Question

Um dos projetos em que estou trabalhando está migrando determinadas configurações de ulimit aplicadas por marionetes de "que parece certo" para alocado dinamicamente com base no ambiente. Isso é para ambientes de aplicativo único, por isso estou preocupado principalmente em evitar que o aplicativo perca recursos, mantendo o kernel e os espaços utilitários com identificadores e manipulações suficientes para fazer o que deveriam.

Recebemos solicitações persistentes de equipes de aplicativos para os identificadores de arquivo moar! , por isso estou tentando encontrar uma maneira de lidar com isso. Então eu fiz um fato fantoche:

Facter.add('app2_nofile') do
  confine :kernel => 'Linux'
  setcode do
    kernel_nofile = '/bin/cat /proc/sys/fs/file-max'.chomp
    app2_limit = (kernel_nofile.to_i * 0.85).round
    app2_limit
  end
end

Que faz o que diz na lata. Ele pega o valor do kernel definido em /proc/sys/fs/file-max e ocupa 85% dele, deixando 15% para uso do sistema. Defina um ulimit de nofile macio e duro usando este ::app2_nofile fact em outro recurso de marionetes, então o /etc/security/limits.conf é atualizado, e tada! Simples! Se eles querem mais identificadores de arquivos, eles precisarão ser mais inteligentes para escrever o aplicativo.

Exceto, não funcionou. Ao tentar abrir uma sessão de usuário ( su app2_user - ) com o usuário com esse nofile ulimit, recebemos a mensagem de erro:

Could not open session

O que é ruim.

Claramente, existe um limite superior em algum lugar independente de ulimits simples. Ou talvez eu esteja entendendo como eles fundamentalmente funcionam. Como os limites de nofile interagem entre si e o que faria com que a sessão não pudesse ser criada?

Mais testes sugerem que o limite superior pode ser um limite estático ou mais complexo do que porcentagens simples. Um sistema de RAM pequeno com um arquivo máximo de 797.567 pode ter esse ulimit definido muito alto e eu não obtenho nenhuma reprodução. Em um sistema maior com 1.619.938, posso ter esse ulimit definido para cerca de 63% antes que eu "não consiga abrir a sessão". Eu não tenho nada maior agora para testar para ver se essa porcentagem se move com maior RAM.

Eu recebo uma entrada audit.log:

type=USER_START msg=audit(1416420909.479:511331): user pid=5022 uid=0 auid=1194876420 ses=44826 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open 
acct="app2" exe="/bin/su" hostname=? addr=? terminal=pts/0 res=failed'

O op foi uma operação PAM.

    

Answer 1

Isso parece ser um recurso do PAM:

link

Embora não seja definitivo, a fonte seria o lugar certo para isso, é strongmente sugestivo de que o PAM esteja impondo um teto de algum tipo em certos recursos. A quebra veio quando eu estava usando strace no comando su para ver o que estava tentando fazer que estava sendo negado, e vi esta linha:

setrlimit(RLIMIT_NOFILE, {rlim_cur=1049000, rlim_max=1049000}) = -1 EPERM (Operation not permitted)

Nada é registrado em audit.log além da falha do PAM, o syslog não mostra nada, é apenas uma falha.

Para os meus propósitos, escreverei esse fato para obter o valor mais baixo de um valor estático ou 85% dos arquivos máximos do kernel. Eu preciso fazer mais testes para descobrir o que esse valor estático será, mas parece que este método híbrido será melhor suportado pelo ferramental.