Techniquement, oui.
En 1986, le système d'exploitation Unix 4.3BSD disposait de l'adresse suivante inetd dont le rôle était simplement d'écouter les connexions TCP et de créer le vrai service en cas d'activité. Inetd n'avait pas besoin d'acheminer le trafic réel - le service lui-même hériterait du socket TCP réel et serait capable de lire/écrire directement les données du réseau. Cependant, le service a fait doivent être écrits spécifiquement pour s'attendre à ce que le socket soit déjà fourni, au lieu de tout configurer par lui-même.
De nombreux BSD ont encore inetd (bien qu'il soit le plus souvent inutilisé), et la plupart des distributions Linux ont xinetd disponible. De plus, chaque distribution Linux utilisant systemd dispose de cette fonctionnalité par l'intermédiaire de systemd.socket où il est appelé "activation de la prise".
(Il est Il est même possible de démarrer des conteneurs entiers de cette façon, mais le gestionnaire de conteneurs a besoin d'un support spécifique pour cette fonctionnalité. Par exemple, systemd-nspawn le permet - malheureusement, pour autant que je sache, Docker ne le fait pas. Cela n'a pas empêché quelques entreprises d'utiliser des conteneurs démarrés à la demande en production, cependant).
Un outil de proxy/gateway peut être utilisé pour mettre en œuvre un démarrage à la demande pour des programmes (ou des conteneurs) qui ne prennent pas en charge le passage de sockets par eux-mêmes. Par exemple, systemd a encore systemd-socket-proxyd qui démarrera la vraie chose et relaiera les connexions vers elle (il y a une exemple avec Podman sur le blog de Red Hat, et voici un exemple de Docker ) ; ceci peut aussi être implémenté avec (x)inetd en utilisant un netcat ou socat ordinaire comme relais.
