`lxc-stop -n <container>` takes too long

Stopping an LXC from the CLI takes long (a minute or so), while stopping it from LuCI is quick (almost instantly).

In the end the container stops without any persisting issues. It feels to me that when performing an lxc-stop -n <containername> waits on a timeout orso, while stopping it from LuCI does not. But this is gutt feeling / assumption at this moment.

Could anyone shine some light on this and/or tell me what logs to check to see what actually happens that takes so long?


PS: I would have responded in this topic that seems to resemble my problem if it wasn’t closed already (without a resolution, I do not know why it was closed).

Problem I mentioned in the other post was not solved and still exists. I guess it was closed because there was no activity for x days

Hello,
I’ll need to find how LuCI handles it, but lxc-stop might take up to 60 seconds.
More details can be find here.

Yes, older topics, where there no was activity for 90 days was closed.
Usually someone replied to thread and post his issue, which was completely different to that thread.

Could well be that LuCI uses low timeout values and/or even the kill switch.

Would be nice to know what exactly is kicked off by LuCI.

No rush / high priority or anything, as there is probably no real problem here, but it would be nice to know/understand in order to explain the difference!

@Pepe You officially part of the Turris Team nowadays? I did not realize, congrats! :slight_smile:

I just found a PR for lxc that says to fix a problem with debian lxc containers with systemd.



The current lxc on the TO sends:

Jan 29 23:21:06 LXC_NAME systemd[1]: Received SIGPWR.
Jan 29 23:21:06 LXC_NAME systemd[1]: Starting Power Failure.
Jan 29 23:21:06 LXC_NAME systemd[1]: Reached target Power Failure.
1 Like

I just looked into this again and the TO still waits 60 seconds to forcefully kill the container when using lxc-stop. No services are shut down properly in the container (debian 9)

Also I noticed, which may be related, that the containers do not regain network connection after restarting the TO network service (eg. by changing dns server in foris). Manually restarting the container solves this, but if you have your vpn or other critical service in the container you can loose remote access to the network :frowning:

dmesg output from restart of TO network services:

[435345.111033] br-lan: port 6(vethNYXVM4) entered disabled state
[435345.111124] br-lan: port 5(vethEWFUJG) entered disabled state
[435345.111182] br-lan: port 4(wlan0) entered disabled state
[435345.111225] br-lan: port 3(wlan1) entered disabled state
[435345.111287] br-lan: port 2(eth2) entered disabled state
[435345.111341] br-lan: port 1(eth0) entered disabled state
[435345.120250] device eth0 left promiscuous mode
[435345.120358] br-lan: port 1(eth0) entered disabled state
[435345.130074] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[435345.131921] device eth2 left promiscuous mode
[435345.132015] br-lan: port 2(eth2) entered disabled state
[435345.141702] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[435345.143298] device wlan0 left promiscuous mode
[435345.143388] br-lan: port 4(wlan0) entered disabled state
[435345.143659] device wlan1 left promiscuous mode
[435345.143716] br-lan: port 3(wlan1) entered disabled state
[435345.143939] device vethNYXVM4 left promiscuous mode
[435345.143994] br-lan: port 6(vethNYXVM4) entered disabled state
[435345.144203] device vethEWFUJG left promiscuous mode
[435345.144254] br-lan: port 5(vethEWFUJG) entered disabled state
[435347.051386] device eth0 entered promiscuous mode
[435347.052595] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[435347.067778] device eth2 entered promiscuous mode
[435347.158393] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[435347.536714] ath: EEPROM regdomain: 0x80cb
[435347.536723] ath: EEPROM indicates we should expect a country code
[435347.536727] ath: doing EEPROM country->regdmn map search
[435347.536730] ath: country maps to regdmn code: 0x36
[435347.536733] ath: Country alpha2 being used: CZ
[435347.536735] ath: Regpair used: 0x36
[435347.536739] ath: regdomain 0x80cb dynamically updated by user
[435347.539720] ath: EEPROM regdomain: 0x80cb
[435347.539729] ath: EEPROM indicates we should expect a country code
[435347.539737] ath: doing EEPROM country->regdmn map search
[435347.539739] ath: country maps to regdmn code: 0x36
[435347.539742] ath: Country alpha2 being used: CZ
[435347.539744] ath: Regpair used: 0x36
[435347.539748] ath: regdomain 0x80cb dynamically updated by user
[435348.908999] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[435348.917924] device wlan0 entered promiscuous mode
[435348.922187] ath: EEPROM regdomain: 0x8114
[435348.922194] ath: EEPROM indicates we should expect a country code
[435348.922197] ath: doing EEPROM country->regdmn map search
[435348.922200] ath: country maps to regdmn code: 0x37
[435348.922203] ath: Country alpha2 being used: DE
[435348.922206] ath: Regpair used: 0x37
[435348.922209] ath: regdomain 0x8114 dynamically updated by user
[435348.922261] ath: EEPROM regdomain: 0x8114
[435348.922264] ath: EEPROM indicates we should expect a country code
[435348.922267] ath: doing EEPROM country->regdmn map search
[435348.922269] ath: country maps to regdmn code: 0x37
[435348.922272] ath: Country alpha2 being used: DE
[435348.922274] ath: Regpair used: 0x37
[435348.922277] ath: regdomain 0x8114 dynamically updated by user
[435349.002511] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[435349.004169] device wlan1 entered promiscuous mode
[435349.004232] br-lan: port 4(wlan1) entered forwarding state
[435349.004271] br-lan: port 4(wlan1) entered forwarding state
[435349.004364] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[435349.004684] ath: EEPROM regdomain: 0x80cb
[435349.004689] ath: EEPROM indicates we should expect a country code
[435349.004693] ath: doing EEPROM country->regdmn map search
[435349.004695] ath: country maps to regdmn code: 0x36
[435349.004698] ath: Country alpha2 being used: CZ
[435349.004701] ath: Regpair used: 0x36
[435349.004705] ath: regdomain 0x80cb dynamically updated by user
[435349.004749] ath: EEPROM regdomain: 0x80cb
[435349.004753] ath: EEPROM indicates we should expect a country code
[435349.004755] ath: doing EEPROM country->regdmn map search
[435349.004758] ath: country maps to regdmn code: 0x36
[435349.004761] ath: Country alpha2 being used: CZ
[435349.004763] ath: Regpair used: 0x36
[435349.004766] ath: regdomain 0x80cb dynamically updated by user
[435349.036931] mvneta f1030000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[435349.037019] br-lan: port 1(eth0) entered forwarding state
[435349.037066] br-lan: port 1(eth0) entered forwarding state
[435349.072613] mvneta f1070000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[435349.072636] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[435349.072828] br-lan: port 2(eth2) entered forwarding state
[435349.072868] br-lan: port 2(eth2) entered forwarding state
[435349.297139] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[435349.297238] br-lan: port 3(wlan0) entered forwarding state
[435349.297290] br-lan: port 3(wlan0) entered forwarding state
[435350.996746] br-lan: port 4(wlan1) entered forwarding state
[435351.036882] br-lan: port 1(eth0) entered forwarding state
[435351.066746] br-lan: port 2(eth2) entered forwarding state
[435351.157319] mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[435351.157346] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[435351.296735] br-lan: port 3(wlan0) entered forwarding state

Manually restarting the containers result in dmesg output of:

[434615.294369] device vethNFLRH9 entered promiscuous mode
[434615.294535] IPv6: ADDRCONF(NETDEV_UP): vethNFLRH9: link is not ready
[434615.294544] br-lan: port 5(vethNFLRH9) entered forwarding state
[434615.294566] br-lan: port 5(vethNFLRH9) entered forwarding state
[434615.363623] eth0: renamed from vethXBUX9R
[434615.402087] IPv6: ADDRCONF(NETDEV_CHANGE): vethNFLRH9: link becomes ready
[434616.143349] device vethOBMEVV entered promiscuous mode
[434616.143731] IPv6: ADDRCONF(NETDEV_UP): vethOBMEVV: link is not ready
[434616.243814] eth0: renamed from vethQ5SB3Q
[434616.272127] IPv6: ADDRCONF(NETDEV_CHANGE): vethOBMEVV: link becomes ready
[434616.272208] br-lan: port 6(vethOBMEVV) entered forwarding state
[434616.272273] br-lan: port 6(vethOBMEVV) entered forwarding state
[434617.290623] br-lan: port 5(vethNFLRH9) entered forwarding state
[434618.270581] br-lan: port 6(vethOBMEVV) entered forwarding state

Notice how the TO network service restart disables the veth ports but never reenables them