Re: [PATCH] Re-add use of locking with iptables/ip6tables/ebtables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/11/2014 05:42 AM, Daniel P. Berrange wrote:
> A previous commit introduced use of locking with invocation
> of iptables in the viriptables.c module
> 
>   commit ba95426d6f39aec1da6e069dd7222f7a8c6a5862
>   Author: Serge Hallyn <serge.hallyn@xxxxxxxxxx>
>   Date:   Fri Nov 1 12:36:59 2013 -0500
> 
>     util: use -w flag when calling iptables
> 
> This only ever had effect with the virtual network driver,
> as it was not wired up into the nwfilter driver. Unfortunately
> in the firewall refactoring the use of the -w flag was
> accidentally lost.
> 
> This patch introduces it to the virfirewall.c module so that
> both the virtual network and nwfilter drivers will be using
> it. It also ensures that the equivalent --concurrent flag
> to ebtables is used.
> ---
>  src/util/virfirewall.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++---
>  src/util/viriptables.c |  2 --
>  2 files changed, 63 insertions(+), 6 deletions(-)

With this patch applied, and testing on Fedora 20, I see the following
messages at startup of libvirtd:

2014-11-18 13:22:49.979+0000: 31329: info : libvirt version: 1.2.11
2014-11-18 13:22:49.979+0000: 31329: error : virCommandWait:2532 :
internal error: Child process (/usr/sbin/iptables -w -L -n) unexpected
exit status 2: iptables v1.4.19.1: unknown option "-w"
Try `iptables -h' or 'iptables --help' for more information.

2014-11-18 13:22:49.982+0000: 31329: error : virCommandWait:2532 :
internal error: Child process (/usr/sbin/ip6tables -w -L -n) unexpected
exit status 2: ip6tables v1.4.19.1: unknown option "-w"
Try `ip6tables -h' or 'ip6tables --help' for more information.

Do we need a followup patch to avoid logging failures when probing for
whether -w works?


> +
> +static void
> +virFirewallCheckUpdateLock(bool *lockflag,
> +                           const char *const*args)
> +{
> +    virCommandPtr cmd = virCommandNewArgs(args);
> +    if (virCommandRun(cmd, NULL) < 0) {
> +        VIR_INFO("locking not supported by %s", args[0]);

Generally, it would be done by passing a non-NULL parameter to
virCommandRun and checking the status ourselves (since virCommandRun
with a NULL argument logs all non-zero exit).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]