zwol's questions

Estou tentando fazer com que o systemd inicie um daemon e passe 8.192 soquetes de escuta. Eu tenho um arquivo .servicee .socketque funciona de maneira confiável com um número mais "normal" de soquetes de escuta, assim:

# a-daemon.socket
[Unit]
Description=A Daemon (sockets)
After=network.target

[Socket]
Accept=no
ListenStream=8192

# a-daemon.service
[Unit]
Description=A Daemon
After=network.target
Requires=a-daemon.socket

[Install]
WantedBy=multi-user.target

[Service]
Type=notify
ExecStart=/usr/local/sbin/a-daemon

Mas se eu trocar a-daemon.socketpor uma versão com 8.192 ListenStreamlinhas, uma para cada porta TCP de 8192 a 16383 inclusive, o daemon não iniciará mais. A unidade de soquete pode ser iniciada sem problemas, mas a unidade de serviço falha; a única mensagem de erro que recebo é

systemd[17563]: a-daemon.service: Failed to execute command: Argument list too long
systemd[17563]: a-daemon.service: Failed at step EXEC spawning /usr/local/sbin/a-daemon: Argument list too long

Pelo que entendi, isso não pode ser realmente um problema com a lista de argumentos , porque o systemd não coloca os números do soquete fd na linha de comando do daemon ou algo assim. Eu imaginei que era um problema com um limite no número de arquivos abertos simultâneos, então eu configurei DefaultLimitNOFILE=32768e /etc/systemd/system.confuma configuração equivalente /etc/security/limits.confe reiniciei. Nenhuma mudança. Em seguida, coloquei ExecStartPre=/usr/sbin/prlimit -no arquivo .service e tentei reiniciá-lo, o que confirmou que o limite aumentado havia entrado em vigor:

prlimit[18134]: RESOURCE   DESCRIPTION                             SOFT      HARD UNITS
prlimit[18134]: NOFILE     max number of open files               32768     32768 files

Mas o serviço ainda falha, da mesma forma. E agora estou sem ideias. Você pode sugerir algo que eu poderia tentar fazer para que isso funcione?

(Estou ciente de que ouvir em 8.192 portas TCP consecutivas é uma coisa estranha de se fazer. Por favor, aceite minha palavra de que tenho um bom motivo que não posso compartilhar.)

Configurei o UDel ntpd (versão 4.2.6.p5) como cliente para três servidores operados pela minha organização e (pensei) mais ninguém.

server xx.yy.zz.1 iburst
server xx.yy.zz.2 iburst
server xx.yy.zz.3 iburst

restrict default ignore
restrict xx.yy.zz.1 nomodify notrap nopeer noquery
restrict xx.yy.zz.2 nomodify notrap nopeer noquery
restrict xx.yy.zz.3 nomodify notrap nopeer noquery

Após cerca de cinco minutos de tempo de atividade, o ntpq relatou que o daemon havia descoberto e adicionado mais dois servidores de horário (também operados por minha organização, mas não em sua lista oficial de servidores de horário):

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*xx.yy.zz.1          aa.bb.cc.dd  2 u   16   64    1    0.157   -2.230   0.032
 xx.yy.zz.2          aa.bb.cc.dd  2 u   15   64    1    0.207   -2.191   0.032
 xx.yy.zz.3          aa.bb.cc.dd  2 u   14   64    1    0.211   -2.171   0.014
 xx.yy.zz.4         .INIT.       16 u    -   64    0    0.000    0.000   0.000
 xx.yy.zz.5         .INIT.       16 u    -   64    0    0.000    0.000   0.000

Como esses servidores não estavam na lista de permissões de endereços (porque eu não sabia sobre eles), a tentativa do cliente de se comunicar com eles obviamente falhou.

Não sei exatamente como isso aconteceu, mas tenho a impressão pela documentação de que há alguma maneira do Servidor A dizer ao cliente "ei, você deveria estar falando com os Servidores B, C e D também". A documentação que encontrei tem muita verborragia sobre os vários métodos para isso, mas absolutamente nada sobre como controlá-lo.

Portanto, a pergunta: como desligo isso completamente, para que o cliente apenas tente se comunicar com os servidores listados explicitamente no arquivo de configuração, aconteça o que acontecer?

Por pedido:

# ntpq -pncrv | redact
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+xx.yy.zz.1      aa.bb.cc.dd  2 u   56 1024  377    0.177   -0.010   0.070
*xx.yy.zz.2      aa.bb.cc.dd  2 u  690 1024  377    0.237    0.028   0.046
+xx.yy.zz.3      aa.bb.cc.dd  2 u  226 1024  377    0.229    0.013   0.052
 xx.yy.zz.4      .INIT.      16 u    - 1024    0    0.000    0.000   0.000
 xx.yy.zz.5      .INIT.      16 u    - 1024    0    0.000    0.000   0.000
associd=0 status=061b leap_none, sync_ntp, 1 event, leap_event,
version="ntpd [email protected] Fri Apr 10 19:04:04 UTC 2015 (1)",
processor="x86_64", system="Linux/3.16.0-4-amd64", leap=00, stratum=3,
precision=-22, rootdelay=0.405, rootdisp=38.394, refid=128.2.1.21,
reftime=d951542d.a6db3cdc  Wed, Jul 15 2015 17:50:37.651,
clock=d95156df.0d2756da  Wed, Jul 15 2015 18:02:07.051, peer=9102, tc=10,
mintc=3, offset=0.009, frequency=-5.266, sys_jitter=0.024,
clk_jitter=0.030, clk_wander=0.003

# redact < /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server aa.bb.cc.1 iburst
server aa.bb.cc.2 iburst
server aa.bb.cc.3 iburst
restrict -4 default ignore
restrict -6 default ignore
restrict aa.bb.cc.1 nomodify notrap nopeer noquery
restrict aa.bb.cc.2 nomodify notrap nopeer noquery
restrict aa.bb.cc.3 nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict ::1

Não vejo nada aqui sobre a obtenção de servidores adicionais do DHCP.