Wir hatten auf unserem Webserver die Notwendigkeit, sowohl Apache als auch Nginx verwenden zu müssen. Da beide Dämonen jeweils auf Port 80 (HTTP) lauschen sollten, muss jeder Dämon jeweils an eine eigene IP-Adresse gebunden werden. Das bedeutet, dass Apache mittels "Listen 1.2.3.4:80" und Nginx mittels "listen 1.2.3.5:80" konfiguriert wurden. Der Seiteneffekt dieser Konfiguration war, dass sehr häufig beim Start des Systems beide Dämonen nicht korrekt gestartet wurden. Ein nachträglicher, manueller Start funktionierte immer. Die erste Behelfslösung bestand darin, in /etc/rc.local folgendes zu tun: sleep 30 systemctl start nginx systemctl start apache2 Tatsächlich stellte sich heraus, dass beide Dämonen zu früh gestartet wurden. Im Systemd-Journal (journalctl -x) war sichtbar, dass das Netzwerkinterface erst aktiv wurde, nachdem die Dämonen bereits angelaufen waren: fatty.congenio.de nginx[1343]: nginx: [emerg] bind() to 1.2.3.5 fatty.congenio.de nginx[1343]: nginx: configuration file /etc/nginx/ fatty.congenio.de systemd[1]: nginx.service: Control process exited, fatty.congenio.de systemd[1]: nginx.service: Failed with result 'exi fatty.congenio.de systemd[1]: Failed to start A high performance web -- Subject: Unit nginx.service has failed -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit nginx.service has failed. -- -- Unit systemd-networkd.service has begun starting up. fatty.congenio.de systemd-networkd[27544]: eth0: Gained IPv6LL fatty.congenio.de systemd-networkd[27544]: Enumeration completed fatty.congenio.de systemd-timesyncd[667]: Network configuration chan fatty.congenio.de systemd[1]: Started Network Service. -- Subject: Unit systemd-networkd.service has finished start-up -- Defined-By: systemd -- Support: http://www.ubuntu.com/support -- -- Unit systemd-networkd.service has finished starting up. -- -- The start-up result is RESULT. fatty.congenio.de systemd-networkd[27544]: eth0: IPv6 successfully e fatty.congenio.de systemd-networkd[27544]: lo: Link is not managed b fatty.congenio.de systemd-timesyncd[667]: Synchronized to time serve Grund ist, dass überraschenderweise das Systemd-Target "network.target" nicht bedeutet, dass das Netzwerk komplett initialisiert ist, sondern nur, dass es gestartet wurde. Um wirklich auf das Netzwerk zu warten, müsste man das Target "network-online.target" verwenden ( siehe hier). In Ubuntu sind die meisten Dämonen aber an "network.target" gebunden, z.B. /lib/systemd/system/nginx.service: [Unit] Description=A high performance web server and a reverse proxy server Documentation=man:nginx(8) After=network.target [Service] Type=forking PIDFile=/run/nginx.pid ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;' ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;' ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid TimeoutStopSec=5 KillMode=mixed [Install] WantedBy=multi-user.target Dummerweise wird dieses Problem in Ubuntu absichtlich nicht beseitigt, weil es in einer normalen Konfiguration nicht auftritt. Wenn man nämlich auf die Default-Adresse 0.0.0.0/0 lauscht, müssen die zugehörigen IPs und Interfaces noch nicht aktiv sein. Man kann mittels "systemctl edit nginx" eine Zusatzdefinition für Systemd hinzufügen: [Unit] After=network-online.target Das bewirkt dann, dass der entprechende Dämon erst nach erfolgreicher Netzwerkinitialisierung gestartet wird.