Hi Patrick,

I investigated a curious networking problem in Debian's autopkgtest
infrastructure along with Paul. We found that a recent (innocent) nftables
update caused needrestart to trigger a nftables.service restart which
flushed volatile firewall rules installed into the kernel by
lxc. Specifically by lxc-net.service see /usr/libexec/lxc/lxc-net.

I think we should add an exception for nftables to $nrconf{override_rc} to
avoid this problem since there doesn't seem to be any point in restarting
it for security purposes.

Thanks,
--Daniel

Hi Daniel,

I wonder why needrestart selects this service at all. Could you provide
the output of `needrestart -v` for this?

ACK, IMHO it should be completely ignored and one should consider the
same for iptables. But I still wonder why the service gets selected at all…


Cheers,
Thomas

(upstream)

Hi Daniel,

I wonder why needrestart selects this service at all. Could you provide
the output of `needrestart -v` for this?

ACK, IMHO it should be completely ignored and one should consider the
same for iptables. But I still wonder why the service gets selected at all…


Cheers,
Thomas

(upstream)

(IMO needrestart is not "unrelated" here.)

Isn't this really a bug in nftables and maybe lxc? If restarting a
service wipes its configuration, maybe it should be fixed there.

Chris

Am 02.05.2025 um 11:50 schrieb Chris Hofstaedtler:
I ACK here. Also for those kind of special configurations a user can add
an override for himself. I dont think this is a serious problem at all.
If Thomas wants to add this in the upstream ignore list I am ok with it,
but for this we should not do a stable update.

Hi Thomas, Hi Chris,

Unfortunately we already restarted all the affected nodes. Do you want me
to try and recreate the problem in debvm?
1.1.2-1 to testing on 04-26. We saw the nftables service was restarted on
affected nodes on 04-27 at about 6am i.e. almost certainly because of
unattended-upgrades.

Why do you think it should be ignored already?

I do think the severity is justified, nftables is the "unrelated" software
needrestart is breaking. See
https://release.debian.org/trixie/rc_policy.txt first section:

I did consider that. Unfortunately too much networking software is already
doing things this way to my knowledge and personal dismay. Think: docker,
libvirt etc.

I think nftables should support a .d directory to fix this "properly".

However since most upstream sofware treats the firwall as runtime state
there's going to be an impedance mismatch if we just stick this in
/etc/nftables.d.

So really we'd have to also support /run/nftables.d to allow representing
the intended semantics and I'm personally just not convinced that's the
right thing to do yet since I haven't thought of this runtime-state
consideration before.

For now adding an exception for nftables fixes the immediate issue and
doesn't have any downsides I can see and I'll carry the .d thing forward in
any case -- now with a good example issue for why it's needed :-)

Thanks,
--Daniel

Control: severity -1 normal

I recreated the situation in a trixie debvm I do indeed not see needrestart
trying to restart nftables.service but only lxc-net.service due to dnsmasq
being linked against libnftables1 which changed SONAME and consequently
moved.

So my assumption that nftables was being (directly) restarted by
needrestart is probably invalid. See below for -v output.

I reviewed lxc-net and it only flushes it's own table(s) not the whole
ruleset. It runs:

    flush table ip6 lxc
    flush table inet lxc

and doesn't otherwise seem to trigger a nftables.service restart
otherwise. Odd.

I'm downgrading the severity then and will try to find another explaination
for what happened here.

Hi,

On Fri, 2 May 2025 14:48:06 +0200 Daniel =?utf-8?Q?Gr=C3=B6ber?= <dxld@darkboxed.org> wrote:
But today I have two affected nodes again (they were off for a while,
now they are back on they show the same problem):

debian-ci@debci-22:~$ sudo nft list ruleset
table inet filter {
         chain input {
                 type filter hook input priority filter; policy accept;
         }

         chain forward {
                 type filter hook forward priority filter; policy accept;
         }

         chain output {
                 type filter hook output priority filter; policy accept;
         }
}


Interestingly, needrestart isn't installed:
debian-ci@debci-22:~$ sudo /usr/sbin/needrestart -v
sudo: /usr/sbin/needrestart: command not found

So I can hardly blame it (so this bug very probably needs reassignment,
but where?). Maybe it should be installed and it would have even
prevented the issue? As in, maybe something *should* have been
restarted, but wasn't?
On this node, the upgrade of nftables happened at 2025-05-21
07:12:51,318 (according to the unattended-upgrade.log). Several minutes
later, it was restarted.

debian-ci@debci-22:~$ sudo journalctl  -u nftables
Mar 13 15:25:58 debci-22 systemd[1]: Finished nftables.service - nftables.
May 21 07:18:42 debci-22 systemd[1]: Stopping nftables.service - nftables...
May 21 07:18:42 debci-22 systemd[1]: nftables.service: Deactivated
successfully.
May 21 07:18:42 debci-22 systemd[1]: Stopped nftables.service - nftables.
May 21 07:18:42 debci-22 systemd[1]: Starting nftables.service - nftables...
May 21 07:18:42 debci-22 systemd[1]: Finished nftables.service - nftables.

Paul