JK Laiho's questions

Eu tenho um servidor Debian 10 rodando Apache2 2.4.38. Recentemente, substituí o arquivo de certificado SSL usado por todos os vhosts HTTPS configurados e executei systemctl reload apache2.service, que é executado /usr/sbin/apachectl gracefulpor meio do arquivo systemd unit.

De acordo com os documentos do Apache 2,

O USR1 ou sinal normal faz com que o processo pai avise os filhos para sair após a solicitação atual (ou sair imediatamente se não estiver atendendo a nada). O pai relê seus arquivos de configuração e reabre seus arquivos de log. À medida que cada filho morre, o pai o substitui por um filho da nova geração da configuração, que começa a atender novas solicitações imediatamente.

Em um servidor ocupado, é compreensível que ocorram atrasos na substituição de um processo filho. No entanto, hoje notei que raramente o servidor ainda responderá com o antigo certificado SSL pré-substituição. Eu fui e dei uma olhada nos processos:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     13559  0.0  0.2  15640 10356 ?        Ss    2022  18:53 /usr/sbin/apache2 -k start
www-data 16834  0.7  0.6 1232452 27780 ?       Sl   06:00   3:47 /usr/sbin/apache2 -k start
www-data 17415  0.9  0.6 1231844 26532 ?       Sl   10:22   2:32 /usr/sbin/apache2 -k start
www-data 17552  0.7  0.6 1231736 26376 ?       Sl   10:53   1:47 /usr/sbin/apache2 -k start
www-data 17612  0.6  0.6 1232000 26840 ?       Sl   10:54   1:34 /usr/sbin/apache2 -k start
www-data 17641  0.6  0.5 1231980 22732 ?       Sl   10:54   1:36 /usr/sbin/apache2 -k start
www-data 17642  0.8  0.6 1231848 24728 ?       Sl   10:54   1:59 /usr/sbin/apache2 -k start
www-data 26704  0.5  0.6 1232216 24748 ?       Sl   Jan18  89:53 /usr/sbin/apache2 -k start

O último processo da lista se destaca nas colunas STARTe TIME. Executei o comando reload em 24 de janeiro, mas agora, seis dias depois, esse processo ainda está em andamento. O servidor está respondendo às solicitações muito bem, no entanto - não se sabe se esse trabalhador está realmente atendendo a novas solicitações ou não, mas os outros estão.

A configuração do servidor é simples e padrão o suficiente para não ser incluída aqui (por enquanto – se precisar de alguma informação específica, pergunte). A única característica interessante sobre ele é que ele está rodando mod_jk, ou seja, as várias VirtualHostdiretivas possuem JkMount /* workername(onde workernameestá definido em /etc/libapache2-mod-jk/workers.properties). mod_jk usa ajp13para se conectar a um dos dois servidores de aplicativos com balanceamento de carga executando o Tomcat.

Esta não é a primeira vez que tivemos um trabalhador Apache2 travado, mas nunca consegui determinar o motivo pelo qual acabou dessa forma. Pode ter algo a ver com mod_jk e os aplicativos Java (muito) herdados, possivelmente havendo alguma solicitação que causou um raro bug de caso extremo no nível Java/mod_jk e está impedindo que o trabalhador seja capaz de sair por meio do USR1 sinal. Os logs do aplicativo Java não estão sob meu controle; eles são extremamente detalhados com informações inúteis, muitas vezes faltando carimbos de data/hora e são praticamente inúteis para fins de solução de problemas, a menos, talvez, se você os estivesse olhando no momento exato em que o erro ocorreu.

Terei que fazer uma reinicialização não otimizada, mesmo que isso cause uma pequena interrupção na produção, mas estou interessado em outros métodos para depurar esse problema no futuro, para que possamos fazer com que os trabalhadores sempre executem uma reinicialização otimizada de maneira confiável quando necessário. Como podemos analisar melhor o que faz um trabalhador ficar preso assim?

Os resultados de apachectl -V:

Server version: Apache/2.4.38 (Debian)
Server built:   2021-12-21T16:50:43
Server's Module Magic Number: 20120211:84
Server loaded:  APR 1.6.5, APR-UTIL 1.6.1
Compiled using: APR 1.6.5, APR-UTIL 1.6.1
Architecture:   64-bit
Server MPM:     event
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/etc/apache2"
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="mime.types"
 -D SERVER_CONFIG_FILE="apache2.conf"

apachectl -Scom subdomínios de produção redigidos:

VirtualHost configuration:
*:443                  is a NameVirtualHost
         default server vhost1.domain.example (/etc/apache2/sites-enabled/00_vhost1.domain.example-ssl.conf:2)
         port 443 namevhost vhost1.domain.example (/etc/apache2/sites-enabled/00_vhost1.domain.example-ssl.conf:2)
         port 443 namevhost vhost2.domain.example (/etc/apache2/sites-enabled/01_vhost2.domain.example-ssl.conf:2)
         port 443 namevhost vhost3.domain.example (/etc/apache2/sites-enabled/02_vhost3.domain.example-ssl.conf:2)
         port 443 namevhost vhost4.domain.example (/etc/apache2/sites-enabled/03_vhost4.domain.example-ssl.conf:2)
                 alias alias1.domain.example
*:80                   is a NameVirtualHost
         default server vhost1.domain.example (/etc/apache2/sites-enabled/00_vhost1.domain.example.conf:1)
         port 80 namevhost vhost1.domain.example (/etc/apache2/sites-enabled/00_vhost1.domain.example.conf:1)
         port 80 namevhost vhost2.domain.example (/etc/apache2/sites-enabled/01_vhost2.domain.example.conf:1)
                 alias 172.16.33.63
         port 80 namevhost vhost3.domain.example (/etc/apache2/sites-enabled/02_vhost3.domain.example.conf:1)
         port 80 namevhost vhost4.domain.example (/etc/apache2/sites-enabled/03_vhost4.domain.example.conf:1)
                 alias alias1.domain.example
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www/html"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex default: dir="/var/run/apache2/" mechanism=default 
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex proxy: using_defaults
Mutex ssl-cache: using_defaults
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

Estou encarregado de testar o ProxySQL em alguns servidores de teste Tomcat, comparando seu desempenho e utilização de recursos com o pool de conexão Apache DBCP atual. Tenho um plano de teste de carga aproximado, mas tenho experiência quase zero com monitoramento e coleta/comparação de métricas de desempenho no nível do sistema (CPU, memória, disco, rede etc.)

Meu teste de carga envolverá um manual do Ansible que executa várias tarefas preparatórias, aciona os scripts de teste de carga e, finalmente, limpa a si mesmo. Eu gostaria de adicionar "inicia e para a coleta de métricas de desempenho antes e depois do teste de carga, respectivamente", mas não sei quais ferramentas devo analisar.

A solução ideal, na minha opinião, seria algo assim:

• Executa localmente em segundo plano nas caixas do Tomcat
• Configuração simples
• As sessões de monitoramento podem ser iniciadas e interrompidas sob demanda
• Alta resolução (métricas coletadas uma vez por segundo ou até com mais frequência, se necessário)
• Os resultados do monitoramento são facilmente legíveis em algum tipo de ferramenta gráfica para comparar diferentes execuções de teste de carga.

Dadas essas especificações, que tipo de opções estou procurando, tanto para a tarefa de monitoramento em si quanto para a ferramenta gráfica para examiná-las?

Estou encarregado de reconstruir um servidor LAN que está servindo como servidor NTP para centenas de máquinas clientes. Infelizmente, está em uma máquina virtual e como demonstrado por perguntas como Quais são os limites da execução de servidores NTP em máquinas virtuais? isso está longe de ser o ideal.

No entanto, nas circunstâncias atuais, é com isso que tenho que trabalhar, até que as centenas de máquinas que dependem desse servidor sejam reconfiguradas para uma configuração NTP mais robusta, em algum lugar no futuro.

Felizmente, os clientes não confiam na precisão de milissegundos. Estou planejando rodar o Chrony no novo servidor, configurando-o para usar quatro servidores stratum 2 locais.

Sou novo no serviço NTP e novo no Chrony. Quais configurações do lado do servidor você consideraria essenciais para essa situação? O objetivo é minimizar a imprecisão dadas as restrições fundamentais de executar um servidor NTP em uma máquina virtual em primeiro lugar.

Um servidor da Web que estou administrando mostra negações estranhas de iptables de endereços IPv4 na porta de destino 443, apesar do tráfego HTTPS ser explicitamente permitido. A porta 80 também é permitida na mesma regra, mas o site é somente HTTPS e a 80 é imediatamente redirecionada para 443 pelo nginx.

Coisa é: navegar no site funciona . Você pode carregar todas as páginas, todos os recursos vêm bem, etc. Mas algo está claramente errado aqui e isso pode estar prejudicando o desempenho do carregamento da página.

Aqui estão alguns exemplos de erros registrados nas /var/log/iptables_deny.logportas 443 e 80, respectivamente. Estes podem vir individualmente ou em rajadas, a julgar pelo meu tail -farquivo de log. A grande maioria é para a porta 443:

iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x08 PREC=0x00 TTL=53 ID=61266 DF PROTO=TCP SPT=49264 DPT=443 WINDOW=0 RES=0x00 RST URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=115 ID=11186 DF PROTO=TCP SPT=58445 DPT=443 WINDOW=254 RES=0x00 ACK FIN URGP=0
iptables denied: IN=eth0 OUT= MAC=f2:3c:91:26:1e:1f:84:78:ac:0d:8f:41:08:00 SRC=(redacted IP) DST=(redacted IP) LEN=40 TOS=0x00 PREC=0x00 TTL=116 ID=16941 DF PROTO=TCP SPT=16278 DPT=80 WINDOW=255 RES=0x00 ACK FIN URGP=0

Um grep rápido diz que os tipos de pacotes nas negações podem ser pelo menos ACK, ACK FIN, ACK RST, ACK PSH e RST. Talvez outros, mas não me chamaram a atenção.

Abaixo, a saída de iptables -nvL. O padrão básico (permitir todos os relacionados e estabelecidos primeiro, depois permitir todo o novo tráfego em 80 e 443) deve ser sólido com base em tudo que li. As regras LOG & DROP são as últimas na cadeia INPUT, como deveriam ser.

Chain INPUT (policy ACCEPT 1 packets, 391 bytes)
 pkts bytes target     prot opt in     out     source          destination   
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0       0.0.0.0/0     
 8893  770K ACCEPT     all  --  *      *       0.0.0.0/0       0.0.0.0/0      ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       (redacted IP)   0.0.0.0/0      ctstate NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0       0.0.0.0/0      icmptype 8
   63  3840 ACCEPT     tcp  --  *      *       0.0.0.0/0       0.0.0.0/0      ctstate NEW multiport dports 80,443
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:137
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:138
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:139
    0     0 DROP       udp  --  *      *       0.0.0.0/0       0.0.0.0/0      udp dpt:445
    1    40 LOG        all  --  *      *       0.0.0.0/0       0.0.0.0/0      limit: avg 15/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    1    40 DROP       all  --  *      *       0.0.0.0/0       0.0.0.0/0     

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source          destination   
    0     0 DROP       all  --  *      *       0.0.0.0/0       0.0.0.0/0     

Chain OUTPUT (policy ACCEPT 1 packets, 65 bytes)
 pkts bytes target     prot opt in     out     source          destination   
 7311   19M ACCEPT     all  --  *      *       0.0.0.0/0       0.0.0.0/0

As regras relevantes reais, se forem de alguma utilidade após essa saída:

-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m conntrack --ctstate NEW -m multiport --dports 80,443 -j ACCEPT

O que está claro é que, em geral, não se trata de tráfego malicioso. Eu naveguei no site a partir de alguns endereços IP diferentes e, embora o site tenha carregado aparentemente bem, meu IP também apareceu no log de negação sem nenhum padrão que eu pudesse discernir e sem nenhuma condição de erro visível pelo usuário no navegador.

Alguma ideia do que poderia estar por trás disso?

Eu tenho um servidor de desenvolvimento rodando gunicorn/Django atrás do nginx. Como parte de uma atualização mais ampla do ambiente de servidor, tentei atualizar o gunicorn de 18.0 para 19.2.1, mas o serviço não iniciava mais. (O servidor está executando Arch e, portanto, usa systemctl.)

A configuração do gunicorn foi feita por alguém que não está mais à nossa disposição, e não conhecendo bem o gunicorn, não consegui consertar ou mesmo localizar o problema, então voltei para a versão 18.0 e está funcionando por enquanto. No entanto, gostaria de atualizá-lo eventualmente e obter a configuração em uma forma em que funcionaria. Tenho a sensação de que a configuração atual está abaixo do ideal ou redundante, mas não tenho como saber ao certo :-).

Nada mudou no ambiente (ou no virtualenv em que o gunicorn está sendo executado), apenas o próprio gunicorn foi atualizado. Systemctl produziu este erro em systemctl start gunicorn:

● gunicorn.service - gunicorn daemon (production)
   Loaded: loaded (/usr/lib/systemd/system/gunicorn.service; enabled)
   Active: failed (Result: resources) since Tue 2015-02-17 20:55:41 UTC; 8s ago
  Process: 2837 ExecStop=/bin/kill -s QUIT $MAINPID (code=exited, status=0/SUCCESS)
  Process: 9608 ExecReload=/bin/kill -s HUP $MAINPID (code=exited, status=0/SUCCESS)
  Process: 5353 ExecStart=/home/django/gunicorn/run.sh (code=exited, status=0/SUCCESS)
 Main PID: 24876 (code=exited, status=0/SUCCESS)

Feb 17 20:55:41 ashima systemd[1]: PID file /home/django/gunicorn/gunicorn.pid not readable (yet?) after start.
Feb 17 20:55:41 ashima systemd[1]: gunicorn.service never wrote its PID file. Failing.
Feb 17 20:55:41 ashima systemd[1]: Failed to start gunicorn daemon (production).
Feb 17 20:55:41 ashima systemd[1]: Unit gunicorn.service entered failed state.

Tentando executar o comando gunicorn contido em run.sh(colado abaixo) manualmente a partir do shell, ele simplesmente saiu imediatamente sem produzir nenhum erro, com um código de saída 0. Nada foi registrado. Na verdade, parece que meu antecessor desativou o log do gunicorn um tempo atrás, depois que o arquivo de log cresceu para um tamanho alarmante, mas isso é um problema para outro dia.

Aqui está o conteúdo dos arquivos relevantes:

/usr/lib/systemd/system/gunicorn.service:

[Unit]
Description=gunicorn daemon

[Service]
Type=forking
PIDFile=/home/django/gunicorn/gunicorn.pid
User=django
WorkingDirectory=/home/django/[name_withheld]/project
ExecStart=/home/django/gunicorn/run.sh
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=false

[Install]
WantedBy=multi-user.target

/home/django/gunicorn/run.sh:

#!/bin/bash

set -e

cd /home/django/[name_withheld]/project
source /home/django/.venv/bin/activate
exec gunicorn -p /home/django/gunicorn/gunicorn.pid -c /home/django/gunicorn/config.py -e HTTPS=on [name_withheld]_site.wsgi:application

/home/django/gunicorn/config.py:

bind = 'unix:/tmp/gunicorn.sock'
backlog = 2048
workers = 16
worker_class = 'egg:gunicorn#sync'
worker_connections = 1000
timeout = 30
keepalive = 2
debug = False
spew = False
daemon = True
pidfile = None
umask = 0755
user = None
group = None
tmp_upload_dir = None
raw_env = 'HTTPS=on'
errorlog = '-'
loglevel = 'info'
accesslog = None
proc_name = None

def post_fork(server, worker):
    server.log.info("Worker spawned (pid: %s)", worker.pid)

def pre_fork(server, worker):
    pass

def pre_exec(server):
    server.log.info("Forked child, re-executing.")

def when_ready(server):
    server.log.info("Server is ready. Spawning workers")