openvpn per systemd-nspawn startert erst nach 2. Boot

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Zwierbel
Beiträge: 8
Registriert: 10.06.2017 21:17:17

openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von Zwierbel » 10.06.2017 21:28:30

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

Re: openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von TomL » 10.06.2017 23:29:39

Zwierbel hat geschrieben: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
Beiträge: 8
Registriert: 10.06.2017 21:17:17

Re: openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von Zwierbel » 11.06.2017 12:50:23

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
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von rendegast » 11.06.2017 14:17:53

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.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

TomL

Re: openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von TomL » 11.06.2017 17:18:27

Zwierbel hat geschrieben:
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.

Benutzeravatar
ThorstenS
Beiträge: 2875
Registriert: 24.04.2004 15:33:31

Re: openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von ThorstenS » 12.06.2017 17:40:10

rendegast hat geschrieben:systemd-nspawn ist in jessie-backports schon nicht mehr vorhanden,
Es steckt aber in Debiansystemd-container

Zwierbel
Beiträge: 8
Registriert: 10.06.2017 21:17:17

Re: openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von Zwierbel » 12.06.2017 20:04:45

TomL hat geschrieben: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
Beiträge: 8
Registriert: 10.06.2017 21:17:17

Re: openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von Zwierbel » 12.06.2017 21:00:33

Zwierbel hat geschrieben: 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
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: openvpn per systemd-nspawn startert erst nach 2. Boot

Beitrag von rendegast » 13.06.2017 02:20:45

ThorstenS hat geschrieben:
systemd-nspawn ist in jessie-backports schon nicht mehr vorhanden,
Es steckt aber in Debiansystemd-container
Yepp, Du hast natürlich Recht,
https://packages.debian.org/file:systemd-nspawn gibt das leider nicht wieder.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

Antworten