I've solved this by statically entering the first IPv6 address in my
netplan config. Previously it came up via DHCPv6, whereas the second
IPv6 address was static.
I don't know why the above script didn't achieve the required delay,
given that it explicitly waits for the IPv6 address which nginx fa
I've added my script back in to the wait-online override, which looks
like this. After a few reboots, nginx once again failed to bind to this
address.
My hacky solution is to add a 5 second sleep to the end of this script.
#!/bin/bash
ip=$(ip -6 address)
until [[ $ip == *"2603:af50:1630:aec9:f19
Another thing I tried was an additional script to loop "ip address" and
look for the IPv6 address I need before wait-online finishes, and even
that failed to sufficiently delay the boot process enough to allow nginx
to bind to the address.
--
You received this bug notification because you are a m
** Attachment added: "networkd.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2081645/+attachment/5826893/+files/networkd.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2081645
Tit
** Attachment added: "wait-online.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2081645/+attachment/5826892/+files/wait-online.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/208164
> it does not override the existing one (maybe you already know that)
Yep, I did know that. My drop-in creates a second wait-online
invocation, but since they are both waiting I saw no need to remove the
initial invocation.
> I am wondering if networkd is reporting the link as configured after
*o
Sorry for the delay. It does not look like you enabled the debug.conf
override, which I need to see more detail about what wait-online is
doing. However, testing a similar setup locally, it seems that the
override is doing what you want it to do (i.e. add additional wait for
ipv6). Note, for the re
Can you gather debug logs for networkd itself, too?
$ mkdir -p /etc/systemd/system/systemd-networkd.d/
$ cat > /etc/systemd/system/systemd-networkd.d/debug.conf << EOF
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
EOF
# reboot
$ journalctl -u systemd-networkd -b > networkd.txt
--
You received
Any update? I'm still seeing failures to bind to an IPv6 address that
systemd-networkd has previously reported as being up. I can insert an
arbitrary 5 second pause as a workaround, but this should not be
necessary.
ubuntu@hawk:~$ journalctl -g 2603:af50:1630:aec9:f19a:227e:2f54:5c73 -b
Oct 10 13:
** Attachment added: "cat-sd-wait-online.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2081645/+attachment/5821600/+files/cat-sd-wait-online.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
** Attachment added: "wait-online.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2081645/+attachment/5821599/+files/wait-online.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/208164
Logs attached.
I created the file:
/etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf
in order to delay boot until IPv6 is available.
** Attachment added: "networkctl.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2081645/+attachment/5821598/+files/networkc
Ah sorry, I missed that. Can you please do the following then:
1. Enable debug logs on systemd-networkd-wait-online.service:
$ mkdir -p /etc/systemd/system/systemd-networkd-wait-online.d/
$ cat > /etc/systemd/system/systemd-networkd-wait-online.d/debug.conf << EOF
[Service]
Environment=SYSTEMD_LO
Also, there is no problem launching services manually after boot, and
the issue doesn't happen on every boot, so whatever is happening is very
time-dependant.
I can manually add a few seconds of delay to the boot process, but that
feels hacky.
--
You received this bug notification because you ar
I'm using two IPv6 addresses, bind9 is binding to one, which as you say
is fine.
But when nginx and dovecot try to bind to the other IPv6 address during
boot, they (sometimes) fail.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
It looks like bind9 (named.service) is able to bind to the address just
fine after systemd-networkd reports the address is configured. Is named
maybe not setting SO_REUSEADDR/SO_REUSEPORT or something? Or (as an
experiment) does disabling named.service allow the others to start?
** Changed in: sys
This sounds very similar: https://github.com/systemd/systemd/issues/650
Nevertheless that bug was resolved, so it may be a regression or
something else entirely.
** Bug watch added: github.com/systemd/systemd/issues #650
https://github.com/systemd/systemd/issues/650
--
You received this bug
I can launch the services manually after boot, so the IP addresses are
fine. It's a question of why during boot systemd-networkd is reporting
the IPv6 addresses as available before they actually are.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
This error means the system can't bind to the requested IP address.
Check your network configuration, ensure the IP is valid, and look for
conflicts. Restarting the network service or device might resolve the
issue. For troubleshooting, you might also explore how to https://graphicsinn1.com/corel-
19 matches
Mail list logo
