Hi everyone
on a brand-new Rocky Linux 9 AWS EC2 instance (official image Rocky-9-EC2-Base-9.5-20241118.0.aarch64-0d51926d-1cd1-4223-bda9-346993accc16 AMI ami-0793f1de745d09710) I keep getting the logs flooded by NetworkManager with lines like the below
dhcp6 (eth0): state changed new lease, address=xyz
It would suggest dhcp6 is attempting to get an address and not getting one or getting a different one regularly for some reason. If you are not using dhcp6, perhaps edit the network connection to disable IPv6 by setting it to manual?
Or perhaps ask AWS what is going on with dhcp6 at their end, as it could well be a problem with their environment.
You can check the lease expire date for the DHCP6 leases you get. May be they are really short (instead of the common default of 24h).
You can try this ( replace DHCP4 with DHCP6 and “enp1s0” with “eth0”):
[root@localhost ~]# nmcli -f DHCP4 dev show enp1s0 |grep -i exp
DHCP4.OPTION[6]: expiry = 1738258354
[root@localhost ~]# date -d "@1738258354"
Thu Jan 30 06:32:34 PM CET 2025
[root@localhost ~]#
If you cannot find the reason for those messages but want to suppress them, you can reconfigure rsyslogd via configuration file /etc/rsyslog.conf to not log the “info” level of facility “daemon” to /var/log/messages anymore.
Rocky 9 has this line: *.info;mail.none;authpriv.none;cron.none /var/log/messages
To ignore info level for all daemon processes ( including NetworkManager)
and start logging with next higher level “notice” this might work: *.info;mail.none;authpriv.none;cron.none;daemon.notice /var/log/messages
( appending “daemon.notice” should overwrite “*.info” from the first entry. There might be better ways to do this with advanced rsyslog filtering, e.g. by only ignoring messages with text “changed new lease”)
In my daily work we see many different reasons why processes are spamming our log files and often we cannot change that behaviour. So a common thing we do is to enable “logrotate” to run every day. This way our logs are rotated and compressed.
Is this supposed to be?? The IPv4 is 17 lines long indeed and having the expiry field
expiry = 1738263024
BTW just replicated this with a brand new EC2 instance just to try out: issue happens immediately at first boot, without any docker or anything else installed. Therefore I assume it’s something embedded in the official Rocky image when IPv6 is used.
If the lease is short, then the lease is configured on the DHCP server - which is obviously what AWS manages. Your Rocky image is just a DHCP client that obtains an address from that server. This is why I believe the Rocky image isn’t the problem here, but the DHCP server providing the address. You really need to be talking to AWS about this.
It would help seeing the data/time from your logs as well to see how often the messages are appearing in the log. Your screenshot above doesn’t include that.
Yes true, it would require AWS to check it. I’m curious, if you can test another image other than Rocky, say CentOS or Alma if they have it and see if they also have the same problem with Network Manager and IPv6? If they do it would suggest it’s not specific to Rocky as such if other images suffer the same problem. If they don’t suffer the same problem, then it would suggest a problem with the Rocky one.
I think you’re right (I even remember I stumbled upon that page but discarded on the spot given the Nitro reference). The relevant part is
By default, the IPv6 preferred lease time is 140 seconds and DHCP lease renewals for IPv6 address assignments occur at the halfway mark of 70 seconds
therefore it makes sense seeing logs around every minute or so (precisely, every 70 seconds).
This is for sure something not clear from AWS console VPC -> DHCP option sets where no such default 140s default lease time is reported and cannot be changed at all in the existing DHCP config set (no edit button at all):