Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#61452 - [lxc] lxc-net.service has a race with iptables.service
Attached to Project:
Community Packages
Opened by Ondřej Svoboda (lenoch) - Friday, 18 January 2019, 09:14 GMT
Last edited by Morten Linderud (Foxboron) - Thursday, 11 May 2023, 21:04 GMT
Opened by Ondřej Svoboda (lenoch) - Friday, 18 January 2019, 09:14 GMT
Last edited by Morten Linderud (Foxboron) - Thursday, 11 May 2023, 21:04 GMT
|
DetailsDescription:
When both lxc-net.service and iptables.service are enabled, the latter (iptables-restore) sometimes fails to start, with this message: "Another app is currently holding the xtables lock. Perhaps you want to use the -w option?", because iptables.service does not expect any other party messing with firewall rules at startup. This results in a dangerous state with a pretty useless firewall, e.g. the INPUT chain has the default ACCEPT policy... @spupykin: Creating the following service override for lxc-net.service fixes the race for me: [Unit] After=iptables.service Since the service is included in the package, it is a downstream bug to me, firstly. Additional info: lxc 1:3.1.0-1, iptables 1:1.8.2-1 |
This task depends upon
Closed by Morten Linderud (Foxboron)
Thursday, 11 May 2023, 21:04 GMT
Reason for closing: No response
Thursday, 11 May 2023, 21:04 GMT
Reason for closing: No response
PS: the lxc-net.service file comes from upstream.