Settings in /etc/sysctl.conf being overwritten

[pklaus]

Hi everyone!

When I was changing the configuration of my GoFlex Home I was realizing that ArchLinuxARM somehow disregards settings that I changed in /etc/sysctl.conf. In my particular setup I wanted my box to ignore IPv6 autoconfiguration and router advertisements. So I added the following to /etc/sysctl.conf:

Code: Select all

# don’t accept IPv6 router advertisements anymore. We will need to configure our default routers, too.
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.eth0.accept_ra = 0

However after a reboot, when I connected to the machine via SSH, the command

Code: Select all

cat /proc/sys/net/ipv6/conf/default/accept_ra

still revealed a 1 and the box continued to receive autoconfigured IPv6 addresses.

I was checking, where the /etc/sysctl.conf was being loaded and this happens in the /usr/lib/initscripts/arch-sysctl which in turn is being called in /etc/rc.multi. Directly afterwards, the daemons are being launched.

The daemons in my /etc/rc.conf are:

Code: Select all

DAEMONS=(hwclock syslog-ng network netfs crond sshd plugui lighttpd)

A fix that works for me is to apply the sysctl configuration again and restart the network in my /etc/rc.local:

Code: Select all

# sysctl.conf seems to be ignored so we apply that stuff again (it is first called from /etc/rc.multi) :
/usr/lib/initscripts/arch-sysctl
rc.d restart network

Somehow I think that the starting of the daemon 'network' in the first place makes it forget the sysctl settings but I don't really know how to investigate the problem further.

Do you have an idea? Thanks!

Philipp

[pklaus]

Somehow I found a hint:

When I added the debug line

Code: Select all

cat /proc/sys/net/ipv6/conf/default/accept_ra > /debug.txt

in my /etc/rc.multi so that is was looking like this:

Code: Select all

[...]
# Load sysctl config files
[[ -x /usr/lib/initscripts/arch-sysctl ]] && /usr/lib/initscripts/arch-sysctl
cat /proc/sys/net/ipv6/conf/default/accept_ra > /debug.txt
[...]

I found the following line in my /var/log/boot:

Code: Select all

Thu Mar  1 10:58:12 2012: cat: /proc/sys/net/ipv6/conf/default/accept_ra: No such file or directory

So it seems like the /proc/sys/net tree is not (fully) populated at the time the sysctl.conf is being applied. This seems unfortunate to me. I'm not sure what has to be done to populate it at that moment in system boot. Probably loading an IPv6 kernel module?

[pepedog]

How about
echo 0 > /proc/sys/net/ipv6/conf/default/accept_ra
in /etc/rc.local

[pklaus]

Hi pepedog,

thanks for your contribution to the topic. Unfortunately I would still have to restart the network as the interfaces will get their router advertisements and autoconfigured IPv6 addresses already at that point and setting /proc/sys/net/ipv6/conf/default/accept_ra to 0 afterwards does not undo that (at least the addresses will remain).

[pepedog]

Why don't you customise the rc.d network file

[pklaus]

The reason why I don't change the rc.d file is that I think this problem is a more fundamental one. I just wanted to report my finding that /etc/sysctl.conf is not that useful in the current way the system works. I have no idea how Arch Linux (non ARM) handles this. Probably the network interfaces are being brought up before the /etc/sysctl.conf is being evaluated? No idea. But I'm sure there is an issue with the current way it works in Arch Linux ARM.
Also I would get a conflict when someone changes the /etc/rc.d/network upstream.

If I was to customize my /etc/rc.d/network file, I would also have to know what exactly is causing the issue. It might be the ifconfig $ifname up?

[Emerson1000]

Hello anybody.

Sort of desperation urged me to revive this thread - couldn't find anywhere else a discussion about the issue 'sysctl.conf being overwritten'.

Don't know whether the issue was solved for Arch. Anyway, using LMDE, I do confirm that it still exists for this bread of Debian Testing. Astonishing: the behaviour may vary in detail of certain parameters by flow of updates and although across different installations independently from hardware base. Supposing: this could be a problem of still more distributions.

As pklaus wrote, the question of cause remains unsolved. As long as this persists, I can't call my Windows using friend a lier who insists saying that Linux code is as often garbage as it is Windows code. Where is often praised precision of Linux?

Also tried different workaraounds (i.e. using: echo xxx > variable) in rc.local - without result. Only way working reliably: writing the command directly to console.

Don't know if Arch and Debian use exactly the same init and init script procedure, but I'm really doubting about that. So it is to be supposed that this is an issue of Linux init procedure in general (anbody out there invited to verify the statment with other distributions).

As sysctl (8) doesn't use sysctl(2) syscall, but reads and writes directly in the procfs subtree, unfortuntly, there is currently no program that wraps this syscall (remember that sysctl(8) doesn't use it).
See: http://tldp.org/HOWTO/TCP-Keepalive-HOW ... alive.html
So, how could it be possible to verify the behaviour of the init process reliably in another way?

Another very critical statement on the sysctl() function causes grieve:
http://lwn.net/Articles/247243/
Behind that, there might exist a very serious code problem even in kernel.