AnyDev's questions

Ambiente:

Estou usando um CentOS-7 como hipervisor para executar vários LXCs em libvirt. Cada contêiner executa uma instalação mínima do CentOS-7 com FreePBX reduzido (Asterisco, Apache, MySQL + bits).

Sintomas:

São 16 containers rodando sem problemas. Quando eu começo mais um, ele começa, mas depois que o 17º contêiner começa, não consigo fazer systemctl start/restart/stop <anything>em NENHUM dos contêineres:

[root@test-lxc ~]# systemctl restart dnsmasq
Error: Too many open files

Diagnósticos:

Os seguintes diagnósticos e contagens são feitos enquanto o 17º LXC está em execução e systemctl restart blablaestá falhando:

Posso ssh em qualquer LXC e executar os comandos mais básicos, por exemplo, ls, etc. Suspeito que o limite de alguma forma afete apenas o arquivo systemd.

Estou tentando entender onde/por que atingi o limite.

[root@lxc-hypervisor]# sysctl fs.file-nr
fs.file-nr = 29616      0       12988463

Isso não foi ajustado, é exatamente o que aconteceu com a instalação padrão. Igual ao valor máximo (último) acima = 12988463 é relatado pelo hypervisor e também dentro de cada LXC. O primeiro valor muito semelhante, pouco abaixo de 30.000, também é relatado em cada LXC.

Quando tento contar os descritores de arquivo em todo o processo dentro de cada LXC, recebo na ordem 400 ~ 500 em cada LXC.

for pid in $( ls /proc/ | grep -E -e "^[0-9][0-9]*\$" ); do
    ls -l /proc/${pid}/fd/ 2> /dev/null | wc -l
done

A soma totaliza cerca de 9000 (9k) sem o hipervisor propriamente dito. Quando executo isso no hipervisor, geralmente obtenho valores suspeitosamente próximos de pouco mais de 10.000, por exemplo, 10.005.

Questões:

Q1. De onde o limite é definido ou herdado?

Q2. Por que o limite afeta systemctl start/stop/restart blahos comandos, mas ainda posso ssh em LXCs, executar comandos como scripts bash com loops que bifurcam muito, embora como root.

Q3. Como ajustar os limites para permitir a execução de mais LXCs. Pelo que entendi, a RAM e outros recursos não são o limite.

Eu li muitos artigos e respostas sobre o assunto dos limites do descritor de arquivo, mas não consigo ver onde meu sistema atinge os limites.

Qualquer outra informação relevante também é bem-vinda.

Eu preciso apontar dispositivos para sincronizar seus relógios com meu servidor CentOS-7 rodando dentro do LXC. No servidor estou tentando usar ntpddo ntppacote, mas aberto para outros produtos. Esta pergunta é sobre a configuração do ntpdou equivalente no servidor.

Até agora eu tentei isso em/etc/ntp.conf

driftfile /var/lib/ntp/drift
restrict default nomodify notrap nopeer noquery

restrict 127.0.0.1
restrict ::1

server 127.127.1.1 iburst
fudge  127.127.1.1 stratum 8

disable monitor

Há DOIS problema aqui.

1. ntpdtermina após o logcap_set_proc() failed to drop root privileges: Operation not permitted
2. ntpdestá tentando ajustar a hora local. Ele falha, mas tenta. Se este fosse o único problema e eu tivesse uma mensagem de erro no log, eu poderia aceitar isso.

A saída completa /var/log/messagescausada pela tentativa de iniciar o ntpd:

systemd: Starting Network Time Service...
ntpd[20154]: ntpd [email protected] Wed Apr 12 21:24:06 UTC 2017 (1)
ntpd[20155]: proto: precision = 0.120 usec
ntpd[20155]: ntp_adjtime() failed: Operation not permitted
systemd: Started Network Time Service.
ntpd[20155]: 0.0.0.0 c01d 0d kern kernel time sync enabled
ntpd[20155]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
ntpd[20155]: Listen and drop on 1 v6wildcard :: UDP 123
ntpd[20155]: Listen normally on 2 lo 127.0.0.1 UDP 123
ntpd[20155]: Listen normally on 3 eth0 hidden:A.B.C.D UDP 123
ntpd[20155]: Listen normally on 4 tun0 hidden:E.F.G.H UDP 123
ntpd[20155]: Listening on routing socket on fd #21 for interface updates
ntpd[20155]: 0.0.0.0 c016 06 restart
ntpd[20155]: ntp_adjtime() failed: Operation not permitted
ntpd[20155]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
ntpd[20155]: 0.0.0.0 c011 01 freq_not_set
ntpd[20155]: cap_set_proc() failed to drop root privileges: Operation not permitted
systemd: ntpd.service: main process exited, code=exited, status=255/n/a
systemd: Unit ntpd.service entered failed state.
systemd: ntpd.service failed.

Estou tentando usar nf_conntrack_sip em caixa que está rodando Asterisk, ou seja, não roteando tráfego para outra caixa VoIP. A instalação funciona até eu reiniciar. Após a reinicialização, o nf_conntrack_sip QUASE sempre para de funcionar e o tráfego de mídia é descartado.

conntrack --dump | grep -E 'sip|helper'
# No output matching 'sip' nor 'helper' while a call is in progress (albeit no audio)

As regras do iptables são carregadas corretamente confirmadas por iptables-save.

Então eu faço systemctl restart iptablese 9/10 vezes isso corrige. Se isso não acontecer, eu reinicio, repita o reinício do iptables.

conntrack --dump | grep -E 'sip|helper'
conntrack v1.4.4 (conntrack-tools): 9 flow entries have been shown.
udp      17 3597 src=10.7.0.38 dst=10.47.1.11 sport=5063 dport=5060 src=10.47.1.11 dst=10.7.0.38 sport=5060 dport=5063 [ASSURED] mark=0 secctx=system_u:object_r:unlabeled_t:s0 helper=sip use=2

Simplesmente recarregar as regras com iptables-restore < /etc/sysconfig/iptablesnão ajuda. Eu suspeito que descarregar/carregar conntrack ou alguns módulos fazem o truque.

Ocasionalmente, funciona na inicialização, mas muito raro. Asterisk iniciar rapidamente. Dar-lhe mais tempo para "terminar de começar algo" não ajuda.

Atualização: reiniciar o iptables enquanto nf_conntrack_sip está funcionando como esperado, pode, raramente, quebrá-lo.

A configuração:

Atualização: Inicialmente, o problema foi descrito como ocorrendo em uma VM, mas desde então reinstalei em hardware real (CPU i5-6500 @ 3,20 GHz com 8 Gb de RAM) com exatamente o mesmo problema ainda ocorrendo. Todos os pacotes idênticos (mesmo script de provisionamento) da VM inicial.

O sistema operacional é CentOS-7.4 Minimal + atualizações, kernel 3.10.0-693.21.1.el7.x86_64. É tudo instalado a partir de RPMs, sem kernels ou módulos personalizados. Atualização: também fiz yum updateos pacotes estáveis ​​e o kernel mais recentes disponíveis no CentOS em 2018-08-10. O problema persiste.

eu fiz yum autoremove firewallde yum install iptables-services.

Difere de /etc/sysconfig/iptables-config(outros valores são padrões por RPM)

-IPTABLES_MODULES=""
+IPTABLES_MODULES="nf_conntrack_sip"

Arquivo adicionado /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack nf_conntrack_helper=0

O todo /etc/sysconfig/iptablesé muito simples:

*raw
-A PREROUTING -p udp --dport 5060 -j CT --helper sip
COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p udp -m state --state NEW -m udp --dport 5060 -j ACCEPT
-A INPUT -j LOG --log-level 7 --log-prefix "REJECT in filter.INPUT:"
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

Atualização: Definir as opções do módulo options nf_conntrack nf_conntrack_helper=1e NÃO usar a regra iptables ... -j CT --helper sipNÃO corrige isso e o comportamento permanece não determinístico.

Não é relevante para o problema, apenas para confirmar que os pacotes foram descartados, em vez de ter problemas de NAT,/etc/rsyslog.d/kern-debug.conf

kern.=debug /var/log/kernel-debug

Testando com um telefone Cisco SPA504G que disca para o PBX e recebe música em espera. Não tentando fazer nada complicado com a mídia. A sinalização SIP e a mídia são trocadas com o mesmo endereço IPv4. A chamada de teste é apenas entre o telefone e o PBX. Nenhuma outra parte envolvida.

Minha tentativa de diagnosticá-lo:

Eu fiz um pequeno script que tenta capturar o estado de várias coisas antes e depois da correção reiniciando o iptables, para comparar por diff. O roteiro:

for f in $( find /proc/sys/net/netfilter -type f ); do
  echo f=${f}
  cat "${f}"
done

echo cat /sys/module/nf_conntrack/parameters/*
cat /sys/module/nf_conntrack/parameters/*

echo ls /sys/module/nf_conntrack/holders/
ls /sys/module/nf_conntrack/holders/

echo cat /sys/module/nf_conntrack_sip/parameters/*
cat /sys/module/nf_conntrack_sip/parameters/*
echo ls /sys/module/nf_conntrack_sip/holders/
ls /sys/module/nf_conntrack_sip/holders/

echo ls /sys/module/ip*/holders/
ls /sys/module/{ip,nf_}*/holders/

echo sysctl -a
sysctl -a

echo lsmod
lsmod

echo iptables-save
iptables-save

A única coisa que noto é que o módulo FREQUENTEMENTE nf_conntrack_netlinkESTÁ listado como carregado após a inicialização, enquanto há um problema. Às vezes, NÃO é listado lsmodAPÓS a inicialização, mas ainda há o problema. Depois de reiniciar o iptables, até onde sei, nunca é listado como carregado. Suspeito que não esteja relacionado porque não há ligação direta entre ele ser carregado e o problema se manifestar.