systemd “ativação de soquete” x xinetd

Question

Eu uso xinetd e funciona para os meus propósitos. No entanto, descobri recentemente que o systemd possui algo chamado "ativação de soquete".

Estes dois parecem muito semelhantes, mas systemd é "oficial" e parece ser a melhor escolha.

No entanto, antes de usá-lo, eles são realmente os mesmos? Existem diferenças que eu deveria estar ciente?

Por exemplo, eu quero iniciar alguns serviços dockerised somente quando eles forem solicitados pela primeira vez - meu primeiro pensamento seria usar o xinetd. Mas a ativação do soquete é melhor / mais rápida / estável / o que for?

    

Answer 1

Eu não acho que a ativação do soquete do systemd seja significativamente melhor do que xinetd de ativação, quando considerada isoladamente; o último também é estável e existe há mais tempo. A ativação do soquete é realmente interessante para o desacoplamento de serviço: ele permite que os serviços sejam iniciados em paralelo, mesmo que precisem se comunicar, e permite que os serviços sejam reiniciados independentemente.

Se você tiver um serviço que suporte a ativação xinetd , ele poderá ser usado com a ativação de soquete: a .socket description com Accept=true se comportará da mesma maneira que xinetd . Você também precisará de um arquivo .service para descrever o serviço. Os benefícios completos da ativação do soquete systemd requerem suporte no serviço que fornece o serviço. Veja a postagem do blog sobre o assunto .

Meu conselho tende a ser "se não estiver corrompido, não conserte", mas se você quiser converter um serviço xinetd -based em systemd, certamente é possível.

    

Answer 2

Você pode usar xinetd ou systemd para ativação de soquete, ambos funcionarão. Eu pessoalmente acho xinetd mais fácil de usar porque tudo está em um arquivo, mas também usei systemd porque é mais flexível, especialmente com escuta em vários endereços e encaminhamento de soquete para soquetes UNIX e não apenas para soquetes IP.

Aqui, como exemplo, usei a conexão TCP para o soquete do arquivo MySQL:

/etc/systemd/system/mysql-proxy.service

[Unit]                                                  
Description=MySql Proxy Service
Requires=mysql-proxy.socket

[Service]
Environment=MYSQL_PROXY_TARGET=/var/run/mysql/mysql.sock
EnvironmentFile=-/etc/sysconfig/mysql-proxy
ExecStart=/usr/lib/systemd/systemd-socket-proxyd ${MYSQL_PROXY_TARGET}

/etc/systemd/system/mysql-proxy.socket

[Unit]                                                  
Description=MySql Proxy Socket

[Socket]
ListenStream=192.168.1.1:3306
ListenStream=192.168.2.1:3306
NoDelay=true
FreeBind=true

[Install]
WantedBy=sockets.target

Necessidades de encaminhamento tradicionais Accept=true , systemd processos conscientes devem manipular várias conexões em um processo ou aplicar processos adicionais conforme necessário.