openvpn per systemd-nspawn startert erst nach 2. Boot

[Zwierbel]

Hallo,

ich haben ein OpenVPN per systemd-nspawn am Laufen.

Wenn ich mein richtiges System reboote startet er zwar die Systeme per nspawn, aber bei OpenVPN kommt eine Fehlermeldung:

Code: Alles auswählen

openvpn openvpn[53]: TCP/UDP: Socket bind failed on local address [AF_INET]192.168.178.43:1194: Cannot assign requested address

Ich vermute mal, dass beim Start vom richtigen Rechner das Netzwerk noch nicht richtig da ist und es deswegen nicht funktioniert. Wenn ich den Container erneut starte funktioniert es. Bei nspawn nutze ich --network-bridge=br0.

Ich habe dem nspawn schon

Code: Alles auswählen

[Unit]
After=network-online.target

hinzugefügt. Hat leider auch nicht geholfen.

Jemand noch eine gute Idee?

Ist es eigentlich normal, dass systemd meint, dass das Booten 1,5 Minuten dauert? Mein System ist nach wenigen Sekunden da:

Code: Alles auswählen

# systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1min 30.189s
└─multi-user.target @1min 30.189s
  └─proftpd.service @1.195s +2.332s
    └─nss-lookup.target @1.190s
      └─dnsmasq.service @1.070s +115ms
        └─basic.target @955ms
          └─sockets.target @955ms
            └─ssh.socket @955ms
              └─sysinit.target @953ms
                └─systemd-timesyncd.service @851ms +101ms
                  └─systemd-tmpfiles-setup.service @844ms +5ms
                    └─local-fs.target @842ms
                      └─run-user-1000.mount @2.066s
                        └─local-fs-pre.target @588ms
                          └─keyboard-setup.service @88ms +500ms
                            └─system.slice @83ms
                              └─-.slice @77ms

Unten noch einige System-Ausgaben.

Dank euch!

Grüße

Code: Alles auswählen

# systemctl cat systemd-nspawn@openvpn.service
# /lib/systemd/system/systemd-nspawn@.service
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Container %i
Documentation=man:systemd-nspawn(1)
PartOf=machines.target
Before=machines.target
After=network.target

[Service]
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-veth -U --settings=override --machine=%i
KillMode=mixed
Type=notify
RestartForceExitStatus=133
SuccessExitStatus=133
Slice=machine.slice
Delegate=yes
TasksMax=16384

# Enforce a strict device policy, similar to the one nspawn configures
# when it allocates its own scope unit. Make sure to keep these
# policies in sync if you change them!
DevicePolicy=closed
DeviceAllow=/dev/net/tun rwm
DeviceAllow=char-pts rw

# nspawn itself needs access to /dev/loop-control and /dev/loop, to
# implement the --image= option. Add these here, too.
DeviceAllow=/dev/loop-control rw
DeviceAllow=block-loop rw
DeviceAllow=block-blkext rw

[Install]
WantedBy=machines.target

# /etc/systemd/system/systemd-nspawn@openvpn.service.d/override.conf
[Unit]
After=network-online.target

[Service]
ExecStart=
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --network-bridge=br0 --settings=override --machine=%i

Code: Alles auswählen

Jun 09 21:44:54 openvpn openvpn[53]: OpenVPN 2.4.0 [git:master/d73f7253d939e293+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 22 2017
Jun 09 21:44:54 openvpn openvpn[53]: library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Jun 09 21:44:54 openvpn openvpn[53]: Diffie-Hellman initialized with 2048 bit key
Jun 09 21:44:54 openvpn openvpn[53]: ROUTE: default_gateway=UNDEF
Jun 09 21:44:54 openvpn openvpn[53]: TUN/TAP device tun0 opened
Jun 09 21:44:54 openvpn openvpn[53]: TUN/TAP TX queue length set to 100
Jun 09 21:44:54 openvpn openvpn[53]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Jun 09 21:44:54 openvpn openvpn[53]: /sbin/ip link set dev tun0 up mtu 1500
Jun 09 21:44:54 openvpn openvpn[56]: TUN/TAP device tun1 opened
Jun 09 21:44:54 openvpn openvpn[56]: TUN/TAP TX queue length set to 100
Jun 09 21:44:54 openvpn openvpn[56]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Jun 09 21:44:54 openvpn openvpn[56]: /sbin/ip link set dev tun1 up mtu 1500
Jun 09 21:44:54 openvpn openvpn[53]: /sbin/ip addr add dev tun0 local 192.0.2.1 peer 192.0.2.2
Jun 09 21:44:54 openvpn systemd-networkd[20]: tun0: Gained carrier
Jun 09 21:44:54 openvpn systemd-networkd[20]: tun0: Gained IPv6LL
Jun 09 21:44:54 openvpn openvpn[56]: /sbin/ip addr add dev tun1 local 192.0.2.129 peer 192.0.2.130
Jun 09 21:44:54 openvpn systemd-networkd[20]: tun1: Gained carrier
Jun 09 21:44:54 openvpn systemd-networkd[20]: tun1: Gained IPv6LL
Jun 09 21:44:54 openvpn openvpn[56]: /sbin/ip route add 192.0.2.128/26 via 192.0.2.130
Jun 09 21:44:54 openvpn openvpn[56]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jun 09 21:44:54 openvpn openvpn[56]: Socket Buffers: R=[87380->87380] S=[65536->65536]
Jun 09 21:44:54 openvpn openvpn[56]: TCP/UDP: Socket bind failed on local address [AF_INET]192.168.178.43:443: Cannot assign requested address
Jun 09 21:44:54 openvpn openvpn[56]: Exiting due to fatal error
Jun 09 21:44:54 openvpn openvpn[56]: /sbin/ip route del 192.0.2.128/26
Jun 09 21:44:54 openvpn openvpn[53]: /sbin/ip route add 192.0.2.0/26 via 192.0.2.2
Jun 09 21:44:54 openvpn openvpn[56]: Closing TUN/TAP interface
Jun 09 21:44:54 openvpn openvpn[56]: /sbin/ip addr del dev tun1 local 192.0.2.129 peer 192.0.2.130
Jun 09 21:44:54 openvpn systemd-networkd[20]: tun1: Lost carrier
Jun 09 21:44:54 openvpn openvpn[53]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Jun 09 21:44:54 openvpn openvpn[53]: Socket Buffers: R=[16777216->16777216] S=[16777216->16777216]
Jun 09 21:44:54 openvpn openvpn[53]: TCP/UDP: Socket bind failed on local address [AF_INET]192.168.178.43:1194: Cannot assign requested address
Jun 09 21:44:54 openvpn openvpn[53]: Exiting due to fatal error
Jun 09 21:44:54 openvpn openvpn[53]: /sbin/ip route del 192.0.2.0/26
Jun 09 21:44:54 openvpn openvpn[53]: Closing TUN/TAP interface
Jun 09 21:44:54 openvpn openvpn[53]: /sbin/ip addr del dev tun0 local 192.0.2.1 peer 192.0.2.2
Jun 09 21:44:54 openvpn systemd-networkd[20]: tun0: Lost carrier
Jun 09 21:44:54 openvpn systemd[1]: mein-openvpn@server-tcp443.service: Main process exited, code=exited, status=1/FAILURE
Jun 09 21:44:54 openvpn systemd[1]: Failed to start OpenVPN service for server/tcp443.
Jun 09 21:44:54 openvpn systemd[1]: mein-openvpn@server-tcp443.service: Unit entered failed state.
Jun 09 21:44:54 openvpn systemd[1]: mein-openvpn@server-tcp443.service: Failed with result 'exit-code'.
Jun 09 21:44:54 openvpn systemd[1]: mein-openvpn@server-udp1194.service: Main process exited, code=exited, status=1/FAILURE
Jun 09 21:44:54 openvpn systemd[1]: Failed to start OpenVPN service for server/udp1194.
Jun 09 21:44:54 openvpn systemd[1]: mein-openvpn@server-udp1194.service: Unit entered failed state.
Jun 09 21:44:54 openvpn systemd[1]: mein-openvpn@server-udp1194.service: Failed with result 'exit-code'.

[TomL]

Ist es eigentlich normal, dass systemd meint, dass das Booten 1,5 Minuten dauert? Mein System ist nach wenigen Sekunden da:

Schau Dir mit einem Picture-Viewer die Ausgabe von

Code: Alles auswählen

systemd-analyze plot >~/bootplot.svg

an. Da erkennst Du grafisch, welcher Job länger braucht. Und ich vermute mal, nach 1,5 Minuten ist tatsächlich die letzte Unit zum Starten des Systems fertig. Das hat aber nix mit dem Desktop zu tun, der wird Dir halt vorher angezeigt. Wenn Du direkt nach der Anmeldung mit

Code: Alles auswählen

systemd-analyze

nachsiehst, wird er dir vermutlich sagen, dass er halt noch nicht fertig ist. Und ja, ich glaube auch, dass das am Netzwerk liegt, welches anscheinend länger braucht.

[Zwierbel]

systemd-analyze plot >~/bootplot.svg

Hatte ich vergessen zu erwähnen. Habe ich schon gemacht. Werde daraus nicht schlauer. multi-user.target ist erst nach 93s fertig.
https://pastebin.com/ePHSW1vd
Keine Ahnung auf was das wartet. Im Log dazu sieht man nichts....

[rendegast]

systemd-nspawn ist in jessie-backports schon nicht mehr vorhanden,
suche Dir besser eine andere Lösung.

Vielleicht gleich auf Basis von systemd / udev 230 jessie-backports.

[TomL]

systemd-analyze plot >~/bootplot.svg

Hatte ich vergessen zu erwähnen. Habe ich schon gemacht. Werde daraus nicht schlauer. multi-user.target ist erst nach 93s fertig.
https://pastebin.com/ePHSW1vd
Keine Ahnung auf was das wartet. Im Log dazu sieht man nichts....

mein-powertop.service sieht anders aus, als die anderen... als hätte er sich zwar beendet, aber es fehlt ein ordentlicher Exit-Code. Was ist das für ein Ding? Was tut es? Plan den doch als Versuch einfach mal aus und teste, ob es was ändert.

[ThorstenS]

systemd-nspawn ist in jessie-backports schon nicht mehr vorhanden,

Es steckt aber in systemd-container

[Zwierbel]

mein-powertop.service sieht anders aus, als die anderen... als hätte er sich zwar beendet, aber es fehlt ein ordentlicher Exit-Code. Was ist das für ein Ding? Was tut es? Plan den doch als Versuch einfach mal aus und teste, ob es was ändert.

Ja, der ist etwas "anders". Ist ein eigener Service, der per powertop die Energiesparfunktionen aktiviert (und noch etwas mehr).
Sieht im Detail so aus:

Code: Alles auswählen

# systemctl cat mein-powertop.service 
# /etc/systemd/system/mein-powertop.service
[Unit]
Description=Powertop tunings
#After=network.target
#After=network-online.target
#After=sys-subsystem-net-devices-wlan0.device
#Requires=sys-subsystem-net-devices-wlan0.device


[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/local/bin/mein-powersaving

[Install]
WantedBy=multi-user.target

Code: Alles auswählen

# cat /usr/local/bin/mein-powersaving
#!/bin/bash

powertop --auto-tune
for DEVICES in $(find /sys/devices/pci0000:00 -name manufacturer)
do
    grep -q  Logitech $DEVICES && echo on > $(echo $DEVICES |sed 's#/manufacturer#/power/control#')
done

echo 'max_performance' > '/sys/class/scsi_host/host0/link_power_management_policy'



#echo '0' > '/proc/sys/kernel/nmi_watchdog'
#echo '1' > '/sys/module/snd_hda_intel/parameters/power_save'
exit 0

Da kein Daemon mehr läuft sonder das Script sich beendet (mit Status 0) ist es in der Grafik auch nicht mehr "Active" sondern hört auf.

Ich habe alle mein* services mal deaktiviert. Keine Besserung. Weder bei nspawn noch bei bei systemd Startzeitanzeige.

Für weitere Ideen bin ich offen

[Zwierbel]

Ich habe alle mein* services mal deaktiviert. Keine Besserung. Weder bei nspawn noch bei bei systemd Startzeitanzeige.

Jetzt geht es. Den "schnelleren" systemd start habe ich mit nftables.service in den Griff bekommen. Habe ihn einmal deaktiviert und neu gestartet und dann wieder aktiviert und seit dem startet das System schnell:

Code: Alles auswählen

# systemd-analyze 
Startup finished in 2.556s (kernel) + 5.351s (userspace) = 7.907s

Keine Ahnung was das Problem von nftables war, aber jetzt geht es.

nspawn habe ich jetzt mit

Code: Alles auswählen

[Unit]
After=multi-user.target

So weit nach "hinten" geschoben, dass es reicht. Scheinbar ist bei network-online.target das Netzwerk noch nicht 100% online.
Mir reicht es jetzt, auch wenn mich die Details schon interessieren würden.

Vielen Dank an alle Beteiligten!

[rendegast]

systemd-nspawn ist in jessie-backports schon nicht mehr vorhanden,

Es steckt aber in systemd-container

Yepp, Du hast natürlich Recht,
https://packages.debian.org/file:systemd-nspawn gibt das leider nicht wieder.