Início / server / Perguntas / 1036195
Accepted
zwol
Asked: 2020-10-03 12:28:47 +0800 CST

Passando soquetes 8192 via ativação de soquete systemd - falha com E2BIG

  • 772

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.)

socket systemd max-file-descriptors

1 respostas

  1. Best Answer

    Ao olhar um pouco mais para as manpages do systemd, percebi que existe algo que o systemd coloca na argvárea cujo tamanho é proporcional ao número de sockets de escuta:

    sd_listen_fds_with_names()é como sd_listen_fds(), mas opcionalmente também retorna um array de strings com nomes de identificação para os descritores de arquivo passados, se estiver disponível e o parâmetro names for diferente de NULL. Essas informações são lidas da $LISTEN_FDNAMESvariável [environment], que pode conter uma lista de nomes separados por dois pontos. Para serviços ativados por soquete, esses nomes podem ser configurados com a FileDescriptorName= configuração nos arquivos da unidade de soquete, consulte systemd.socket(5)para detalhes.

    (negrito - ênfase minha) O que isso significa é que, se você tiver 8192 ListenStreamentradas em um arquivo de unidade de soquete, o systemd tentará colocar LISTEN_FDNAMES=[name]:[name]:..., com 8192 repetições, onde nameestá a FileDescriptorNameconfiguração, no ambiente para o serviço. FileDescriptorNameo padrão é o nome base completo do arquivo de unidade de soquete. Isso pode facilmente ultrapassar o limite fixo bastante baixo do Linux no comprimento de uma única variável de ambiente nome + valor ( MAX_ARG_STRLEN, geralmente 128k) e, portanto, causar execve(2)falha com E2BIG.

    Para um daemon que não liga para os nomes, a cura é colocar

    UnsetEnvironment=LISTEN_FDNAMES

    no arquivo de serviço ( [Service]seção). Isso elimina a variável de ambiente problemática e deixa o kernel feliz.

    Não sei o que você faz se realmente precisar dos nomes fd para algo e atingir esse limite.

    • 1

relate perguntas