LXC Container reboot sehr langsam

[jawr]

Hallo zusammen,

ich habe mehrere LXC Container (Debian buster) in PVE 8.2.4. Bei einem habe ich beim reboot "sehr lange" Zeiten für den Vorgang. Alle anderen Container sind eigentlich nach ein paar Sekunden wieder da. Hier warte ich mindestens eine Minute oder länger. Wie kann ich rausfinden woran es liegt? Der Server antwortet noch eine ganze Zeit auf Ping Befehle, so dass ich davon ausgehe das das Problem beim beenden auftritt, nicht beim booten.

Hier mal die config:

arch: amd64
cores: 1
hostname: openvpn-gateway
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.178.1,hwaddr=4E:68:59:C9:xx:xx,ip=192.168.xxx.xxx,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-104-disk-0,size=10G
swap: 1024
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dir

Auf dem Container ist nur ein openvpn client installiert, da er als gateway dient.

Danke und Gruß

 

[Chris]

Hallo zusammen,

ich habe mehrere LXC Container (Debian buster) in PVE 8.2.4. Bei einem habe ich beim reboot "sehr lange" Zeiten für den Vorgang. Alle anderen Container sind eigentlich nach ein paar Sekunden wieder da. Hier warte ich mindestens eine Minute oder länger. Wie kann ich rausfinden woran es liegt? Der Server antwortet noch eine ganze Zeit auf Ping Befehle, so dass ich davon ausgehe das das Problem beim beenden auftritt, nicht beim booten.

Hier mal die config:

arch: amd64
cores: 1
hostname: openvpn-gateway
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.178.1,hwaddr=4E:68:59:C9:xx:xx,ip=192.168.xxx.xxx,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-104-disk-0,size=10G
swap: 1024
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dir

Auf dem Container ist nur ein openvpn client installiert, da er als gateway dient.

Danke und Gruß

Hi,
eventuell liefert das systemd journal im container aufschluss woran das liegt, journalctl -r. Ein systemd-analyze blame sollte helfen herauszufinden welche services beim boot lange brauchen, falls nicht das stoppen bevor dem reboot das problem ist.

 

[Falk R.]

Hallo zusammen,

ich habe mehrere LXC Container (Debian buster) in PVE 8.2.4. Bei einem habe ich beim reboot "sehr lange" Zeiten für den Vorgang. Alle anderen Container sind eigentlich nach ein paar Sekunden wieder da. Hier warte ich mindestens eine Minute oder länger. Wie kann ich rausfinden woran es liegt? Der Server antwortet noch eine ganze Zeit auf Ping Befehle, so dass ich davon ausgehe das das Problem beim beenden auftritt, nicht beim booten.

Hier mal die config:

arch: amd64
cores: 1
hostname: openvpn-gateway
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.178.1,hwaddr=4E:68:59:C9:xx:xx,ip=192.168.xxx.xxx,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-104-disk-0,size=10G
swap: 1024
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dir

Auf dem Container ist nur ein openvpn client installiert, da er als gateway dient.

Danke und Gruß

Ich habe auch schon gelesen, dass oft IPv6 zu Bootverzögerungen führt. Eventuell hilft dir die Info etwas weiter.

 

[jawr]

Hallo,

der Befehl wirft folgendes aus:

root@openvpn-gateway:~# systemd-analyze blame
           514ms ntopng.service
           465ms postfix@-.service
           138ms redis-server.service
           100ms ssh.service
            64ms openvpn@client.service
            60ms networking.service
            57ms netfilter-persistent.service
            55ms systemd-journald.service
            37ms ifupdown-pre.service
            34ms systemd-logind.service
            29ms systemd-user-sessions.service
            25ms rsyslog.service
            24ms systemd-modules-load.service
            24ms systemd-remount-fs.service
            21ms systemd-sysctl.service
            18ms sys-kernel-config.mount
            16ms systemd-journal-flush.service
            15ms systemd-tmpfiles-setup.service
            14ms systemd-tmpfiles-setup-dev.service
            14ms systemd-sysusers.service
            11ms dev-mqueue.mount
             9ms openvpn.service
             8ms systemd-update-utmp.service
             4ms systemd-update-utmp-runlevel.service
             1ms postfix.service
root@openvpn-gateway:~#

Sieht jetzt erstmal unverdächtig aus würde ich sagen. Was meinst du mit:

 falls nicht das stoppen bevor dem reboot das problem ist.

Danke und Gruß

 

[Chris]

Ich habe auch schon gelesen, dass oft IPv6 zu Bootverzögerungen führt. Eventuell hilft dir die Info etwas weiter.

Generell wahr, laut config aber nicht aktiviert.

 

[Chris]

Hallo,

der Befehl wirft folgendes aus:

root@openvpn-gateway:~# systemd-analyze blame
           514ms ntopng.service
           465ms postfix@-.service
           138ms redis-server.service
           100ms ssh.service
            64ms openvpn@client.service
            60ms networking.service
            57ms netfilter-persistent.service
            55ms systemd-journald.service
            37ms ifupdown-pre.service
            34ms systemd-logind.service
            29ms systemd-user-sessions.service
            25ms rsyslog.service
            24ms systemd-modules-load.service
            24ms systemd-remount-fs.service
            21ms systemd-sysctl.service
            18ms sys-kernel-config.mount
            16ms systemd-journal-flush.service
            15ms systemd-tmpfiles-setup.service
            14ms systemd-tmpfiles-setup-dev.service
            14ms systemd-sysusers.service
            11ms dev-mqueue.mount
             9ms openvpn.service
             8ms systemd-update-utmp.service
             4ms systemd-update-utmp-runlevel.service
             1ms postfix.service
root@openvpn-gateway:~#

Sieht jetzt erstmal unverdächtig aus würde ich sagen. Was meinst du mit:

 falls nicht das stoppen bevor dem reboot das problem ist.

Danke und Gruß

Soweit okay, also am besten doch mal im systemd journal nach ursachen suchen.

 

[jawr]

Ich habe auch schon gelesen, dass oft IPv6 zu Bootverzögerungen führt. Eventuell hilft dir die Info etwas weiter.

Ist für den Container eigentlich nicht konfiguriert:



Oder meinst du an anderer Stelle?

 

[jawr]

Soweit okay, also am besten doch mal im systemd journal nach ursachen suchen.

Ok werde ich mal machen, aber da muss ich mich erstmal einlesen, bin da nicht so fit drin

Danke und Gruß

 

[jawr]

Hi,
eventuell liefert das systemd journal im container aufschluss woran das liegt, journalctl -r. Ein systemd-analyze blame sollte helfen herauszufinden welche services beim boot lange brauchen, falls nicht das stoppen bevor dem reboot das problem ist.

journalctl -r liefert unter anderem folgendes:

Sep 05 10:48:36 openvpn-gateway mount[49]: mount: /sys/kernel/config: permission denied.
Sep 05 10:48:36 openvpn-gateway systemd-sysctl[51]: Couldn't write '1' to 'fs/protected_symlinks', ignoring: Permission denied
Sep 05 10:48:36 openvpn-gateway systemd-sysctl[51]: Couldn't write '1' to 'fs/protected_hardlinks', ignoring: Permission denied

Ist das ein "Problem"?

 

[jawr]

Ich habe jetzt mal ein journalctl -b -1 abgesetzt um zu sehen was beim letzten shutdown los war:

Sep 05 11:43:37 openvpn-gateway systemd[1]: openvpn@client.service: Consumed 38ms CPU time.
Sep 05 11:43:37 openvpn-gateway systemd[1]: Removed slice system-openvpn.slice.
Sep 05 11:43:37 openvpn-gateway systemd[1]: system-openvpn.slice: Consumed 38ms CPU time.
Sep 05 11:43:37 openvpn-gateway systemd[1]: Stopped target Network is Online.
Sep 05 11:45:06 openvpn-gateway systemd[1]: ntopng.service: State 'stop-sigterm' timed out. Killing.
Sep 05 11:45:06 openvpn-gateway systemd[1]: ntopng.service: Killing process 285 (ntopng) with signal SIGKILL.
Sep 05 11:45:06 openvpn-gateway systemd[1]: ntopng.service: Main process exited, code=killed, status=9/KILL
Sep 05 11:45:06 openvpn-gateway systemd[1]: ntopng.service: Failed with result 'timeout'.
Sep 05 11:45:06 openvpn-gateway systemd[1]: Stopped ntopng - High-Speed Web-based Traffic Analysis and Flow Collection Tool.

ntopng hat da Probleme gemacht. Hatte das noch installiert ohne das ich es wusste. Runtergeworfen und alles ist wieder gut. Danke für eure HIlfe.

Gruß