got stuck and only got it to work with the bottom two lines below in my /etc/sysctl.d/am-no-ipv6.conf:
root@reinder:~# cat /etc/sysctl.d/am-no-ipv6.conf net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.ens18.accept_ra=0
net.ipv6.conf.ens19.accept_ra=0
root@reinder:~#
This is, to me, unexpected, even unwanted behavior?
I would expect disabling default and all to work and prevent ipv6 routing
and perhaps need of firewalling?!
root@reinder:~# tail -7 /etc/dhcpcd.conf
## only ipv4
ipv4only
ipv6ra_noautoconf
nodhcp6
noipv6
noipv6rs
noipv4ll
root@reinder:~#
root@reinder:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug ens18
iface ens18 inet dhcp
iface ens18 inet6 static
autoconf 0
accept_ra 0
# The secondary network interface
allow-hotplug ens19
iface ens19 inet dhcp
iface ens19 inet6 static
autoconf 0
accept_ra 0
When trying to disable automatic binding of a (wrongly) advertised
ipv6 IP I got stuck and only got it to work with the bottom two lines
below in my /etc/sysctl.d/am-no-ipv6.conf:
root@reinder:~# cat /etc/sysctl.d/am-no-ipv6.conf net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.ens18.accept_ra=0
net.ipv6.conf.ens19.accept_ra=0
root@reinder:~#
This is, to me, unexpected, even unwanted behavior?
I would expect disabling default and all to work and prevent ipv6
routing and perhaps need of firewalling?!
What I also tried before and still have access but does not prevent
an ipv6 from binding:
root@reinder:~# tail -7 /etc/dhcpcd.conf
## only ipv4
ipv4only
ipv6ra_noautoconf
nodhcp6
noipv6
noipv6rs
noipv4ll
root@reinder:~#
Hello Debian Users!
Maybe I am doing something silly, but I am confused, so please educate
me if I am seeing/doing this wrong.
When trying to disable automatic binding of a (wrongly) advertised ipv6
IP I got stuck and only got it to work with the bottom two lines below
in my /etc/sysctl.d/am-no-ipv6.conf:
root@reinder:~# cat /etc/sysctl.d/am-no-ipv6.conf net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.ens18.accept_ra=0
net.ipv6.conf.ens19.accept_ra=0
root@reinder:~#
This is, to me, unexpected, even unwanted behavior?
I would expect disabling default and all to work and prevent ipv6
routing and perhaps need of firewalling?!
What I also tried before and still have access but does not prevent an
ipv6 from binding:
root@reinder:~# tail -7 /etc/dhcpcd.conf
## only ipv4
ipv4only
ipv6ra_noautoconf
nodhcp6
noipv6
noipv6rs
noipv4ll
root@reinder:~#
root@reinder:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug ens18
iface ens18 inet dhcp
iface ens18 inet6 static
autoconf 0
accept_ra 0
# The secondary network interface
allow-hotplug ens19
iface ens19 inet dhcp
iface ens19 inet6 static
autoconf 0
accept_ra 0
root@reinder:~#
On 10.01.2026 17:40 Uhr Reinder wrote:
When trying to disable automatic binding of a (wrongly) advertised
ipv6 IP I got stuck and only got it to work with the bottom two lines
below in my /etc/sysctl.d/am-no-ipv6.conf:
The right way is to fix that issue instead of changing every device.
root@reinder:~# cat /etc/sysctl.d/am-no-ipv6.conf
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.ens18.accept_ra=0
net.ipv6.conf.ens19.accept_ra=0
root@reinder:~#
This is, to me, unexpected, even unwanted behavior?
I would expect disabling default and all to work and prevent ipv6
routing and perhaps need of firewalling?!
The first question is the current state, so check if your values are
applied with sysctl -a.
Routing is handled different, the settings you mentioned disable the
SLAAC address generation and the insertion of the routes (default and
for each advertised prefix) from the RA. It doesn't disable IPv6
routing at all and it is entirely unrelated about firewalling.
You should definitely fix the real problems instead of tinkering around
here.
What I also tried before and still have access but does not prevent
an ipv6 from binding:
There are other ways of IPv6 addressing, like link-local.
root@reinder:~# tail -7 /etc/dhcpcd.conf
## only ipv4
ipv4only
ipv6ra_noautoconf
nodhcp6
noipv6
noipv6rs
noipv4ll
root@reinder:~#
Do you really use dhcpcd or do you use the NetworkManager?
root@reinder:~#
This is, to me, unexpected, even unwanted behavior?
I would expect disabling default and all to work and prevent ipv6
routing and perhaps need of firewalling?!
Is the package linux-sysctl-defaults installed? See <https://www.debian.org/releases/trixie/release-notes/issues.html#etc-sysctl-conf-is-no-longer-honored>.
Also, which version of Debian?
Jeff
Something must be ignoring the default/all setting or forcing it back
on.
root@reinder:~# sysctl -a |grep net.ipv6.conf.*accept_ra
[...]
net.ipv6.conf.ens18.accept_ra = 1
[...]
net.ipv6.conf.ens19.accept_ra = 1
On 11.01.2026 09:30 Uhr Reinder wrote:
Something must be ignoring the default/all setting or forcing it back
on.
Are the NetworkManager or systemd-networkd active?
root@reinder:~# sysctl -a |grep net.ipv6.conf.*accept_ra
[...]
net.ipv6.conf.ens18.accept_ra = 1
[...]
net.ipv6.conf.ens19.accept_ra = 1
And that means the RA will be accepted and the route installed.
Did you already check why the wrong RA exists?
If not, this is the first task.
At the moment I am thinking maybe ifup is still doing something? Though there is no inet6 configuration in /etc/network/interfaces:
It seems to be indeed an ifupdown issue, forcing a static ipv6 in /etc/network/interfaces works, see below.
At the moment I am thinking maybe ifup is still doing something?
Though there is no inet6 configuration in /etc/network/interfaces:
Problem is I did not want to do this. Will debug some more.
At the moment I am thinking maybe ifup is still doing something? Though there is no inet6 configuration in /etc/network/interfaces:
It seems to be indeed an ifupdown issue, forcing a static ipv6 in /etc/network/interfaces works, see below.
Problem is I did not want to do this. Will debug some more.
root@reinder:~# sysctl -a | grep accept_ra\
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.ens18.accept_ra = 0
net.ipv6.conf.ens19.accept_ra = 1
net.ipv6.conf.lo.accept_ra = 1
root@reinder:~# sed 's#[0-9]*:*:*:*:*:#xx:xx:xx:xx:xx:#' /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug ens18
iface ens18 inet dhcp
iface ens18 inet6 static
address xx:xx:xx:xx:xx:7b8:627:2::d59a:fd8c/64
autoconf 0
accept_ra 0
# The secondary network interface
allow-hotplug ens19
iface ens19 inet dhcp
root@reinder:~# ip a s dev ens18|grep kernel_ra|sed 's#[0-9]*:*:*:*:*:#xx:xx:xx:xx:xx:#'
root@reinder:~#
On Sun, Jan 11, 2026 at 4:58?AM Reinder <reinder@reinder.nl> wrote:
At the moment I am thinking maybe ifup is still doing something? Though there is no inet6 configuration in /etc/network/interfaces:
It seems to be indeed an ifupdown issue, forcing a static ipv6 in /etc/network/interfaces works, see below.
Problem is I did not want to do this. Will debug some more.
If I am not mistaken... If you are not using NetworkManager, and you
are not using Systemd, and you are not using Kea, then you are
probably using dhcpcd-base+ifupdown.
Maybe there's something in dhcpcd-base that will provide the next path
to go down.
On Mon, Jan 12, 2026 at 11:44:37 -0500, Jeffrey Walton wrote:
On Sun, Jan 11, 2026 at 4:58?AM Reinder <reinder@reinder.nl> wrote:
They might be using isc-dhcp-client instead. My trixie system is using
that, but it was installed on an older release and upgraded. I don't
know what a new trixie installation uses for its DHCP client.
They might be using isc-dhcp-client instead. My trixie system is using
that, but it was installed on an older release and upgraded. I don't
know what a new trixie installation uses for its DHCP client.
On 2026-01-12, Greg Wooledge wrote:
They might be using isc-dhcp-client instead. My trixie system is using that, but it was installed on an older release and upgraded. I don't
know what a new trixie installation uses for its DHCP client.
isc-dhcp-client is deprecated. trixie defaults to dhcpd
But I haven't checked the code. If you guys think it's worth the time
and is something that should be patched I can maybe find some time later
for this.
* Default to accept_ra=2 for inet6/auto (Closes: #739993, LP: #1260241)
This left me with the dhcpcd-base package installed, isc-dhcp-clientI remember it always was "normal" on Unices (I even remember poking
in the "rc" state, and a dhclient process still running(!). I didn't
even think that was possible on Linux -- for a process to continue
running after its program file on disk has been unlinked.
On Mon, Jan 12, 2026 at 08:03:39PM -0500, Greg Wooledge wrote:Yep - this has been part of my understanding of the key differences
[...]
This left me with the dhcpcd-base package installed,
isc-dhcp-client in the "rc" state, and a dhclient process still
running(!). I didn't even think that was possible on Linux -- for
a process to continue running after its program file on disk has
been unlinked.
I remember it always was "normal" on Unices (I even remember poking
fun at the poor Windows sods who couldn't pull off that trick). The background is that you just remove the directory entry (the file
still exists as long as it is referenced, i.e. at least while the
process runs; actually, on Linux, with its proc file system you even
might revive it by looking through /proc/<PID>, I think).
Now trying to *edit the executable file in place* might get you aI don't think I've actually seen a reference to this (signal?) code before.
-ETXTBSY (Text file busy). Another kettle of fish.
On 2026-01-13 at 02:57, tomas@tuxteam.de wrote:[...]
It is an errno. And it happens whenever the file is mmaped and servesNow trying to *edit the executable file in place* might get you a
-ETXTBSY (Text file busy). Another kettle of fish.
I don't think I've actually seen a reference to this (signal?) code before.
I didn't
even think that was possible on Linux -- for a process to continue
running after its program file on disk has been unlinked.
Now trying to *edit the executable file in place* might get you a
-ETXTBSY (Text file busy). Another kettle of fish.
I don't think I've actually seen a reference to this (signal?) code before.
On Mon, 2026-01-12 at 20:03 -0500, Greg Wooledge wrote:
I didn't
even think that was possible on Linux -- for a process to continue
running after its program file on disk has been unlinked.
That literally happens every time you upgrade a running program?
On Mon, 2026-01-12 at 20:03 -0500, Greg Wooledge wrote:Depends on what you mean by "upgrade a running program".
I didn't
even think that was possible on Linux -- for a process to continue
running after its program file on disk has been unlinked.
That literally happens every time you upgrade a running program?
On Tue, Jan 13, 2026 at 8:38?AM Jan Claeys <lists@janc.be> wrote:[...]
On Mon, 2026-01-12 at 20:03 -0500, Greg Wooledge wrote:
I didn't
even think that was possible on Linux -- for a process to continue running after its program file on disk has been unlinked.
That literally happens every time you upgrade a running program?
To add to Jan's reply, it can happen with shared objects and data files, too.
The takeaway is, the file is not actually deleted until the finalYou just remove the directory entry, which points to the file inode.
unlink and the inodes are freed.
That literally happens every time you upgrade a running program?
Depends on what you mean by "upgrade a running program".
On 2026-01-13, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:urs,
That literally happens every time you upgrade a running program?
Depends on what you mean by "upgrade a running program".
I always wondered about that. Say you're running chromium while the
package is upgraded. Of course, I long realized that nothing untoward occ
but kind of thought: my running instance will "perdure" until it's
closed, but then that would mean people who never reboot and leave
their browser eternally open would eventually have critical faults in
their navigation software, so that can't be right.
cp /proc/30319/exe ./foo1[...]
I once heard that story of someone rm -rf-ing /, then stopping in panic, but /bin/sh
was gone, then rescueing it this way. Or was it /lib/libc-whatever?
In case tmux was upgraded to a new major version you may get an error on attach: ?open terminal failed: not a terminal?. You can still access the
old session with:
/proc/$(pgrep "tmux: server")/exe attach
On 2026-01-13, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:You just have to reboot the browser. That's enough trauma.
That literally happens every time you upgrade a running program?
Depends on what you mean by "upgrade a running program".
I always wondered about that. Say you're running chromium while the
package is upgraded. Of course, I long realized that nothing untoward occurs, but kind of thought: my running instance will "perdure" until it's
closed, but then that would mean people who never reboot and leave
their browser eternally open would eventually have critical faults in
their navigation software, so that can't be right.
On 13/01/2026 8:31 pm, tomas@tuxteam.de wrote:I don't know what you mean by ".so plugins", but if it is good ol' shared
cp /proc/30319/exe ./foo1[...]
I once heard that story of someone rm -rf-ing /, then stopping in panic, but /bin/sh
was gone, then rescueing it this way. Or was it /lib/libc-whatever?
A similar workaround is recommended even in release notes:
<https://www.debian.org/releases/trixie/release-notes/upgrading.en.html>
4. Upgrades from Debian 12 (bookworm):
In case tmux was upgraded to a new major version you may get an error on attach: ?open terminal failed: not a terminal?. You can still access the old session with:
/proc/$(pgrep "tmux: server")/exe attach
As to ETXTBSY, I am less sure concerning .so plugins loaded using dlopen. At least I saw crashes when cp(1) was used instead of install(1) to replace old libraries during installing another version.
On Wed, Jan 14, 2026 at 09:29:47AM +0700, Max Nikulin wrote:
As to ETXTBSY, I am less sure concerning .so plugins loaded using dlopen. At >> least I saw crashes when cp(1) was used instead of install(1) to replace old >> libraries during installing another version.
I don't know what you mean by ".so plugins", but if it is good ol' shared libs, yes, they are mmapped:
On 14/01/2026 2:28 pm, tomas@tuxteam.de wrote:Ah, OK. I tend to agree with you in that.
On Wed, Jan 14, 2026 at 09:29:47AM +0700, Max Nikulin wrote:
As to ETXTBSY, I am less sure concerning .so plugins loaded using dlopen. At
least I saw crashes when cp(1) was used instead of install(1) to replace old
libraries during installing another version.
I don't know what you mean by ".so plugins", but if it is good ol' shared libs, yes, they are mmapped:
I mean explicit call of dlopen(3). Consider e.g. apache modules. I mentioned it for the case if there is some difference in loading of linked libraries and loading optional parts later. Certainly files are mmap'ed. I have no
idea if something has been changed in kernel or in libdl during last decade, but earlier cp was able to overwrite shared library in place causing crash
on next attempt to call some function from that library. I have not retested it now. I think, the key point is whether kernel considers specific file as being executed. Memory mapped files may be opened in read-write mode.
You just have to reboot the browser. That's enough trauma.
On 2026-01-14, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:;-)
You just have to reboot the browser. That's enough trauma.
A kernel upgrade requires a reboot of the system, then.
How traumatic!
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 19:03:38 |
| Calls: | 117 |
| Calls today: | 117 |
| Files: | 367 |
| D/L today: |
540 files (253M bytes) |
| Messages: | 70,845 |
| Posted today: | 26 |