Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #255176 > unrolled thread
| Started by | Geert Stappers <stappers@stappers.nl> |
|---|---|
| First post | 2023-02-19 17:30 +0100 |
| Last post | 2023-02-20 16:20 +0100 |
| Articles | 20 on this page of 55 — 13 participants |
Back to article view | Back to linux.debian.user
Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-19 17:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-19 17:40 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Stefan Monnier <monnier@iro.umontreal.ca> - 2023-02-19 18:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-19 20:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-19 20:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-20 05:40 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-20 04:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-20 05:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-20 15:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-21 17:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-21 18:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-21 19:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-21 19:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-21 19:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' <tomas@tuxteam.de> - 2023-02-21 20:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-22 19:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-22 20:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Greg Wooledge <greg@wooledge.org> - 2023-02-22 20:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Darac Marjal <mailinglist@darac.org.uk> - 2023-02-22 21:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-22 16:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-22 17:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-22 19:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-24 16:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-24 19:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-24 20:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-24 22:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-25 03:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-26 12:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Reco <recoverym4n@enotuniq.net> - 2023-02-26 14:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-26 15:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Reco <recoverym4n@enotuniq.net> - 2023-02-26 15:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Geert Stappers <stappers@stappers.nl> - 2023-02-27 23:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Reco <recoverym4n@enotuniq.net> - 2023-02-28 07:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Max Nikulin <manikulin@gmail.com> - 2023-02-26 16:20 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-26 18:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' David Wright <deblis@lionunicorn.co.uk> - 2023-02-25 04:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-25 04:40 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-25 13:50 +0100
unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Max Nikulin <manikulin@gmail.com> - 2023-02-26 16:40 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-26 17:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-26 19:10 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') David Wright <deblis@lionunicorn.co.uk> - 2023-02-26 20:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-02-28 11:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Max Nikulin <manikulin@gmail.com> - 2023-03-02 15:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-03-02 16:30 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Max Nikulin <manikulin@gmail.com> - 2023-03-03 16:20 +0100
Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') Christoph Brinkhaus <c.brinkhaus@t-online.de> - 2023-03-03 16:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Reco <recoverym4n@enotuniq.net> - 2023-02-21 19:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-20 07:00 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' <tomas@tuxteam.de> - 2023-02-20 08:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-20 08:50 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' tomas@tuxteam.de - 2023-02-20 10:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' rhkramer@gmail.com - 2023-02-20 15:30 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' Jeffrey Walton <noloader@gmail.com> - 2023-02-20 16:10 +0100
Re: Remove route '169.254.0.0/16 dev ovs-system' The Wanderer <wanderer@fastmail.fm> - 2023-02-20 16:20 +0100
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-22 17:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G20tz-7Jto-3@gated-at.bofh.it> |
| In reply to | #255282 |
Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin: > On 22/02/2023 01:26, Christoph Brinkhaus wrote: > > > > I have no idea if it is possible to estimate a DHCP response > > > > time. > > Since static IP address is assigned, it does not matter. I expected DHCP > configuration and that delay may be noticed in `journalctl -b 0` logs. > > > [Unit] > > Description=A remote mail retrieval and forwarding utility > > After=network-online.target opensmtpd.service unbound.service > > Requires=opensmtpd.service unbound.service > > > > But fetchmail starts before the dependencies have been finished. > > I can not say that I fully understand interaction of After and > Requires/Wants options. I would try additional Wants=network-online.target As far as I remeber correctly I have tried the Wants option without success. In case of my fetchmail setup the culprit is unbound. At the startup of unbound it takes some time to exchange keys and so on. During that period names cannot be resolved. Now I call fetchmail after the mailserver name can be resolved to an IP. This is done in a tiny wrapper script. It keeps the log files clean. That workaround is fine for me. > > [Match] > > Name=w* > > > > [Network] > > DHCP=no > > Address=192.168.0.62/24 > > Gateway=192.168.0.32 > > DNS=127.0.0.1 > > There are options like RequiredForOnline, see systemd.network(5), but likely > default value is yes. However avahi-autoipd should be started concurrently > with network configuration to assign link-local address in the case of > failure. In a different thread - it was about IPv6 which has mutated slightly - several users claimed that the avahi-autoip is useful for their business. I am only a hobbyist, I trust the guys who do IT in their regular job. May be it is ok as it is implemented in Debian. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-22 19:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G22lH-7KDI-1@gated-at.bofh.it> |
| In reply to | #255287 |
On Wed 22 Feb 2023 at 17:45:40 (+0100), Christoph Brinkhaus wrote: > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin: > > On 22/02/2023 01:26, Christoph Brinkhaus wrote: > > > > > I have no idea if it is possible to estimate a DHCP response > > > > > time. > > > > Since static IP address is assigned, it does not matter. I expected DHCP > > configuration and that delay may be noticed in `journalctl -b 0` logs. > > > > > [Unit] > > > Description=A remote mail retrieval and forwarding utility > > > After=network-online.target opensmtpd.service unbound.service > > > Requires=opensmtpd.service unbound.service > > > > > > But fetchmail starts before the dependencies have been finished. > > > > I can not say that I fully understand interaction of After and > > Requires/Wants options. I would try additional Wants=network-online.target > > As far as I remeber correctly I have tried the Wants option without > success. > > In case of my fetchmail setup the culprit is unbound. At the startup > of unbound it takes some time to exchange keys and so on. During that > period names cannot be resolved. Now I call fetchmail after the > mailserver name can be resolved to an IP. This is done in a tiny > wrapper script. It keeps the log files clean. That workaround is fine > for me. > > > > [Match] > > > Name=w* > > > > > > [Network] > > > DHCP=no > > > Address=192.168.0.62/24 > > > Gateway=192.168.0.32 > > > DNS=127.0.0.1 > > > > There are options like RequiredForOnline, see systemd.network(5), but likely > > default value is yes. Might you try systemd-networkd-wait-online.service, whose name implies that it waits for up to two minutes (configurable default). > > However avahi-autoipd should be started concurrently > > with network configuration to assign link-local address in the case of > > failure. > In a different thread - it was about IPv6 which has mutated > slightly - several users claimed that the avahi-autoip is useful for > their business. I am only a hobbyist, I trust the guys who do IT in > their regular job. May be it is ok as it is implemented in Debian. I agree with that. I think the people that report problems on the list are, with possible exceptions, trying to get their networks into better shape. Perhaps one problem is that getting a 169.254.x.y address might be useful if you're expecting to join an ad hoc network, but if you're not (like, I suspect, many of us here), it only complicates matters. For the latter, better surely to get no address, notice the fact, and fix the networking, rather than to have to do all that /and/ get rid of the 169.254.x.y address. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-02-24 16:20 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G2I1z-8bOW-1@gated-at.bofh.it> |
| In reply to | #255287 |
On 22/02/2023 23:45, Christoph Brinkhaus wrote: > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin: >> On 22/02/2023 01:26, Christoph Brinkhaus wrote: >>> [Unit] >>> Description=A remote mail retrieval and forwarding utility >>> After=network-online.target opensmtpd.service unbound.service >>> Requires=opensmtpd.service unbound.service ... > In case of my fetchmail setup the culprit is unbound. At the startup > of unbound it takes some time to exchange keys and so on. I have no experience with unbound and I am not sure at which moment it notifies systemd that the service is ready. However I have found a recent bug https://github.com/NLnetLabs/unbound/issues/773 "When used with systemd-networkd, unbound does not start until systemd-networkd-wait-online.service times out" Perhaps the package in Debian has an older version of the unbound.service file and so is not affected. ... >> However avahi-autoipd should be started concurrently >> with network configuration to assign link-local address in the case of >> failure. > > In a different thread - it was about IPv6 which has mutated > slightly - several users claimed that the avahi-autoip is useful for > their business. I mean IPv4 link local addresses 169.254.x.y. My impression is that avahi-autoipd was created for the cases when there is no point to setup centralized DHCP server. On the other hand I agree that a router (and so DHCP out of the box) is more wide spread configuration than connecting a couple of devices directly or through a switch.
[toc] | [prev] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-24 19:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G2LiN-8dKn-3@gated-at.bofh.it> |
| In reply to | #255346 |
Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin: > On 22/02/2023 23:45, Christoph Brinkhaus wrote: > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin: > > > On 22/02/2023 01:26, Christoph Brinkhaus wrote: > > > > [Unit] > > > > Description=A remote mail retrieval and forwarding utility > > > > After=network-online.target opensmtpd.service unbound.service > > > > Requires=opensmtpd.service unbound.service > ... > > In case of my fetchmail setup the culprit is unbound. At the startup > > of unbound it takes some time to exchange keys and so on. > > I have no experience with unbound and I am not sure at which moment it > notifies systemd that the service is ready. However I have found a recent > bug > https://github.com/NLnetLabs/unbound/issues/773 > "When used with systemd-networkd, unbound does not start until > systemd-networkd-wait-online.service times out" > > Perhaps the package in Debian has an older version of the unbound.service > file and so is not affected. > Hi Max, I have observed lines below in journald: Feb 22 15:41:44 lenovo systemd[1]: Reached target Network is Online. Feb 22 15:41:44 lenovo systemd[1]: Failed to start Wait for Network to be Configured. Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE Feb 22 15:41:44 lenovo systemd-networkd-wait-online[362]: Event loop failed: Connection timed out Feb 22 15:41:25 lenovo systemd[1]: anacron.service: Succeeded. Feb 22 15:41:25 lenovo anacron[3261]: Normal exit (0 jobs run) Feb 22 15:41:25 lenovo anacron[3261]: Anacron 2.3 started on 2023-02-22 Feb 22 15:41:25 lenovo systemd[1]: Started Run anacron jobs. This looks related, thank you very much! I will have a look at the link. > ... > > > However avahi-autoipd should be started concurrently > > > with network configuration to assign link-local address in the case of > > > failure. > > > > In a different thread - it was about IPv6 which has mutated > > slightly - several users claimed that the avahi-autoip is useful for > > their business. > > I mean IPv4 link local addresses 169.254.x.y. My impression is that > avahi-autoipd was created for the cases when there is no point to setup > centralized DHCP server. On the other hand I agree that a router (and so > DHCP out of the box) is more wide spread configuration than connecting a > couple of devices directly or through a switch. I think so, too. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-24 20:30 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G2LVv-8edT-3@gated-at.bofh.it> |
| In reply to | #255354 |
On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote: > Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin: > > On 22/02/2023 23:45, Christoph Brinkhaus wrote: > > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin: > > > > On 22/02/2023 01:26, Christoph Brinkhaus wrote: > > > > > [Unit] > > > > > Description=A remote mail retrieval and forwarding utility > > > > > After=network-online.target opensmtpd.service unbound.service > > > > > Requires=opensmtpd.service unbound.service > > ... > > > In case of my fetchmail setup the culprit is unbound. At the startup > > > of unbound it takes some time to exchange keys and so on. > > > > I have no experience with unbound and I am not sure at which moment it > > notifies systemd that the service is ready. However I have found a recent > > bug > > https://github.com/NLnetLabs/unbound/issues/773 > > "When used with systemd-networkd, unbound does not start until > > systemd-networkd-wait-online.service times out" > > > > Perhaps the package in Debian has an older version of the unbound.service > > file and so is not affected. > > > Hi Max, > > I have observed lines below in journald: > > Feb 22 15:41:44 lenovo systemd[1]: Reached target Network is Online. > Feb 22 15:41:44 lenovo systemd[1]: Failed to start Wait for Network to be Configured. > Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. > Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE > Feb 22 15:41:44 lenovo systemd-networkd-wait-online[362]: Event loop failed: Connection timed out > Feb 22 15:41:25 lenovo systemd[1]: anacron.service: Succeeded. > Feb 22 15:41:25 lenovo anacron[3261]: Normal exit (0 jobs run) > Feb 22 15:41:25 lenovo anacron[3261]: Anacron 2.3 started on 2023-02-22 > Feb 22 15:41:25 lenovo systemd[1]: Started Run anacron jobs. > > This looks related, thank you very much! And does anything start up after wait-online expires? (I've never used it.) > I will have a look at the link. > > ... > > > > However avahi-autoipd should be started concurrently > > > > with network configuration to assign link-local address in the case of > > > > failure. > > > > > > In a different thread - it was about IPv6 which has mutated > > > slightly - several users claimed that the avahi-autoip is useful for > > > their business. > > > > I mean IPv4 link local addresses 169.254.x.y. My impression is that > > avahi-autoipd was created for the cases when there is no point to setup > > centralized DHCP server. On the other hand I agree that a router (and so > > DHCP out of the box) is more wide spread configuration than connecting a > > couple of devices directly or through a switch. > > I think so, too. Well, you typically only get a level of Recommended for avahi-autoipd when you install on a laptop, which is a reasonable choice for the debian-installer to make. Otherwise it's either a Suggests, or the sysadmin has to choose it off their own bat. But I guess their are a lot of laptops, now they are affordable, that aren't really used in the way they were intended, but just as more flexible desktops. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Geert Stappers <stappers@stappers.nl> |
|---|---|
| Date | 2023-02-24 22:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G2O6Z-8fuC-3@gated-at.bofh.it> |
| In reply to | #255355 |
On Fri, Feb 24, 2023 at 01:25:55PM -0600, David Wright wrote: > On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote: > > Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin: .... > > > > > > I mean IPv4 link local addresses 169.254.x.y. My impression is that > > > avahi-autoipd was created for the cases when there is no point to setup > > > centralized DHCP server. On the other hand I agree that a router (and so > > > DHCP out of the box) is more wide spread configuration than connecting a > > > couple of devices directly or through a switch. > > > > I think so, too. > > Well, you typically only get a level of Recommended for avahi-autoipd > when you install on a laptop, which is a reasonable choice for the > debian-installer to make. Otherwise it's either a Suggests, or the > sysadmin has to choose it off their own bat. But I guess their are > a lot of laptops, now they are affordable, that aren't really used > in the way they were intended, but just as more flexible desktops. Having `apt purge avahi-autoipd` still gets me "auto IPv4 address" Ideas how to avoid it are welcome. <screenshot> $ dpkg -l '*avahi*ip*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================= un avahi-autoipd <none> <none> (no description available) $ uptime 22:45:25 up 1 min, 1 user, load average: 0.02, 0.04, 0.05 $ ip route | grep system 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004 $ </screenshot> Groeten Geert Stappers -- Silence is hard to parse
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-02-25 03:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G2SNj-8iip-1@gated-at.bofh.it> |
| In reply to | #255358 |
On 25/02/2023 04:43, Geert Stappers wrote: > Having `apt purge avahi-autoipd` still gets me "auto IPv4 address" > > Ideas how to avoid it are welcome. Have you checked "journalctl --boot" for logs which component assigns 169.254.x.y address and for various errors related to network? I am not familiar with openvswitch (or another package that really created ovs-system and ovsbr0), so I have no idea how they may be configured (systemd-networkd, NetworkManager, netplan, ifupdown) in your case and how to configure them properly. Perhaps it better to ask their community how to avoid failure of systemd-networkd-wait-online and assigning of IPv4LL address. I have realized that your problem may be more general than just ovs-system, I do not like the following log line and which file is not found is not clear for me: > feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: wlan0: Failed to update link state, ignoring: No such file or directory
[toc] | [prev] | [next] | [standalone]
| From | Geert Stappers <stappers@stappers.nl> |
|---|---|
| Date | 2023-02-26 12:20 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G3neq-8BOF-7@gated-at.bofh.it> |
| In reply to | #255360 |
On Sat, Feb 25, 2023 at 09:42:49AM +0700, Max Nikulin wrote:
> On 25/02/2023 04:43, Geert Stappers wrote:
> > Having `apt purge avahi-autoipd` still gets me "auto IPv4 address"
> >
> > Ideas how to avoid it are welcome.
>
> Have you checked "journalctl --boot" for logs which component assigns
> 169.254.x.y address and for various errors related to network?
Just did (checking `journalctl --boot`) and found lines like
Feb 24 22:24:13 trancilo systemd-networkd[455]: ovs-system: Unmanaging interface.
Feb 24 22:24:13 trancilo systemd-networkd[455]: ovs-system: State changed: initialized -> unmanaged
Feb 24 22:24:14 trancilo dhcpcd[1175]: ovs-system: waiting for carrier
Feb 24 22:24:14 trancilo systemd-networkd[455]: ovs-system: IPv6 link-local address generation mode is changed: eui64 -> none
Feb 24 22:24:14 trancilo systemd-networkd[455]: ovs-system: Flags change: +UP +LOWER_UP +RUNNING
Feb 24 22:24:14 trancilo systemd-networkd[455]: ovs-system: Link UP
Feb 24 22:24:14 trancilo systemd-networkd[455]: ovs-system: Gained carrier
...
Feb 24 22:24:14 trancilo NetworkManager[1188]: <info> [1677273854.7167] manager: (ovs-system): new Generic device (/org/freedesktop/NetworkManager/Devices/3)
Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired
Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25
Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address fe80::56b2:83e1:5ceb:9d50
...
Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease
...
Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address
Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7
Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16
Feb 24 22:24:26 trancilo systemd-networkd[455]: ovs-system: Received new foreign address (configured): 169.254.201.7/16 (valid forever, preferred forever), flags: permanent,no-prefixroute, scope: global
Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding default route
Feb 24 22:24:26 trancilo systemd-networkd[455]: ovs-system: link_check_ready(): link is in unmanaged state.
Feb 24 22:24:26 trancilo systemd-networkd[455]: ovs-system: Received new foreign route (configured): dst: 169.254.201.7/32, src: n/a, gw: n/a, prefsrc: 169.254.201.7, scope: host, table: local(255), proto: kernel, type: local, nexthop: 0, priority: 0, flags: n/a
Feb 24 22:24:26 trancilo systemd-networkd[455]: ovs-system: Received new foreign route (configured): dst: 169.254.255.255/32, src: n/a, gw: n/a, prefsrc: 169.254.201.7, scope: link, table: local(255), proto: kernel, type: broadcast, nexthop: 0, priority: 0, flags: n/a
> I am not familiar with openvswitch (or another package that really created
> ovs-system and ovsbr0), so I have no idea how they may be configured
> (systemd-networkd, NetworkManager, netplan, ifupdown) in your case and how
> to configure them properly. Perhaps it better to ask their community how to
> avoid failure of systemd-networkd-wait-online and assigning of IPv4LL
> address.
AIUI is systemd-networkd the main player, dhcpcd some helper
and NetworkManager for contact with user.
> I have realized that your problem may be more general than just ovs-system,
> I do not like the following log line and which file is not found is not
> clear for me:
> > feb 19 18:46:18 trancilo systemd-networkd-wait-online[601]: wlan0: Failed to update link state, ignoring: No such file or directory
>
Acknowledge on the "be aware of a problem with wlan0"
Groeten
Geert Stappers
--
Silence is hard to parse
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2023-02-26 14:20 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G3p6x-8D1c-3@gated-at.bofh.it> |
| In reply to | #255381 |
Hi. On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote: > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25 > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address fe80::56b2:83e1:5ceb:9d50 > ... > Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease > ... > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7 > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16 Let's try a straightforward approach for starters: echo denyinterfaces ovs-system >> /etc/dhcpcd.conf Reco
[toc] | [prev] | [next] | [standalone]
| From | Geert Stappers <stappers@stappers.nl> |
|---|---|
| Date | 2023-02-26 15:20 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G3q2B-8DCi-7@gated-at.bofh.it> |
| In reply to | #255382 |
Hi. On Sun, Feb 26, 2023 at 04:01:06PM +0300, Reco wrote: > On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote: > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25 > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address fe80::56b2:83e1:5ceb:9d50 > > ... > > Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease > > ... > > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7 > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16 > > Let's try a straightforward approach for starters: > > echo denyinterfaces ovs-system >> /etc/dhcpcd.conf Yes, now no more route 169.254.0.0/16 for device ovs-system. And for the record: * Package avahi-autoipd left removed * Service avahi-daemon left disabled * Socket avahi-daemon left disabled > Reco Thanks Groeten Geert Stappers -- Silence is hard to parse
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2023-02-26 15:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G3qvD-8DML-1@gated-at.bofh.it> |
| In reply to | #255383 |
Hi. On Sun, Feb 26, 2023 at 03:14:22PM +0100, Geert Stappers wrote: > Hi. > > On Sun, Feb 26, 2023 at 04:01:06PM +0300, Reco wrote: > > On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote: > > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired > > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25 > > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address fe80::56b2:83e1:5ceb:9d50 > > > ... > > > Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease > > > ... > > > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7 > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16 > > > > Let's try a straightforward approach for starters: > > > > echo denyinterfaces ovs-system >> /etc/dhcpcd.conf > > > Yes, now no more route 169.254.0.0/16 for device ovs-system. > > And for the record: > * Package avahi-autoipd left removed > * Service avahi-daemon left disabled > * Socket avahi-daemon left disabled These have nothing to do with your problem. dhcpcd is the source of your problem, in a way. dhcpcd can run as a systemwide daemon, which tries to obtain DHCP lease on any network interface barring "lo". In stock configuration, dhcpcd will add IPv4LL (169.254/16) IP on a interface if it fails to obtain a lease after 60 second timeout (IIRC). And obviously you have no DHCP server on "ovs-system" :) Debian's packaging of dhcpcd should prevent the daemon to obtain DHCP lease on any interface that's listed in /etc/network/interfaces, but: 1) OVS bridge should not be listed there, it's dynamic by nature. 2) You're using Network Manager, so it's totally possible that you have an empty /etc/network/interfaces, or no such file at all. Long story short, consider running "systemctl mask dhcpcd" unless you need dhcpcd to work in a way described above. Another possible workaround is to add "noipv4ll" to dhcpcd.conf, but this could break something else in your setup. Reco
[toc] | [prev] | [next] | [standalone]
| From | Geert Stappers <stappers@stappers.nl> |
|---|---|
| Date | 2023-02-27 23:00 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G3THj-8Wxx-1@gated-at.bofh.it> |
| In reply to | #255385 |
Hi.
On Sun, Feb 26, 2023 at 05:25:09PM +0300, Reco wrote:
> On Sun, Feb 26, 2023 at 03:14:22PM +0100, Geert Stappers wrote:
> > On Sun, Feb 26, 2023 at 04:01:06PM +0300, Reco wrote:
> > > On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote:
} } } } } Have you tried `journalctl --boot`?
> > > > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL address
> > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address 169.254.201.7
> > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to 169.254.0.0/16
> > >
> > > Let's try a straightforward approach for starters:
> > >
> > > echo denyinterfaces ovs-system >> /etc/dhcpcd.conf
> >
> >
> > Yes, now no more route 169.254.0.0/16 for device ovs-system.
> >
> > And for the record:
> > * Package avahi-autoipd left removed
> > * Service avahi-daemon left disabled
> > * Socket avahi-daemon left disabled
As done / adviced earlier in this thread.
> These have nothing to do with your problem.
> dhcpcd is the source of your problem, in a way.
OK, so I checked. And yes, it is true that adding
'denyinterfaces ovs-system ovsbr0' to /etc/dhcpcd.conf
does prevent "route 169.254.0.0/16 dev ovs-system"
and "route 169.254.0.0/16 dev ovsbr0"
> dhcpcd can run as a systemwide daemon, which tries to obtain DHCP lease
> on any network interface barring "lo".
> In stock configuration, dhcpcd will add IPv4LL (169.254/16) IP on a
> interface if it fails to obtain a lease after 60 second timeout (IIRC).
> And obviously you have no DHCP server on "ovs-system" :)
> Debian's packaging of dhcpcd should prevent the daemon to obtain DHCP
> lease on any interface that's listed in /etc/network/interfaces, but:
>
> 1) OVS bridge should not be listed there, it's dynamic by nature.
> 2) You're using Network Manager, so it's totally possible that you have
> an empty /etc/network/interfaces, or no such file at all.
>
I have no /etc/network/interfaces.d/ovs-system,
my /etc/network/interfaces.d/ovsbr0 has
auto ovsbr0
iface ovsbr0 inet static
address 172.24.6.2/24
And there was "route 169.254.0.0/16 dev ovsbr0".
I only reported, until now, only about dev ovs-system.
Thing I trying to say:
Having device in /etc/network/interfaces did
not prevent the unwanted route.
(Meanwhile solved with denyinterface in /etc/dhcpcd.conf)
> Long story short, consider running "systemctl mask dhcpcd" unless you
> need dhcpcd to work in a way described above.
The laptop does need to have DHCP client.
> Another possible workaround is to add "noipv4ll" to dhcpcd.conf,
Not tried.
> but this could break something else in your setup.
Yes "could break", but I don't know what ...
(I'm mostly on computer networks that do have
DHCP and DNServers (I can't tell first hand
the benefits of IPv4LL addresses))
> Reco
Groeten
Geert Stappers
--
Silence is hard to parse
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Date | 2023-02-28 07:10 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G41lv-91Ll-9@gated-at.bofh.it> |
| In reply to | #255418 |
Hi. On Mon, Feb 27, 2023 at 10:53:24PM +0100, Geert Stappers wrote: > (Meanwhile solved with denyinterface in /etc/dhcpcd.conf) > > > > Long story short, consider running "systemctl mask dhcpcd" unless you > > need dhcpcd to work in a way described above. > > The laptop does need to have DHCP client. I see. Adding appropriate amount of "allowinterfaces" and "denyinterfaces" stanzas into dhcpcd.conf should solve it for you. > > Another possible workaround is to add "noipv4ll" to dhcpcd.conf, > > Not tried. It disallows dhcpcd to add IPv4LL address on any network interface. Reco
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-02-26 16:20 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G3qYF-8Edd-9@gated-at.bofh.it> |
| In reply to | #255381 |
On 26/02/2023 18:18, Geert Stappers wrote:
> AIUI is systemd-networkd the main player, dhcpcd some helper
> and NetworkManager for contact with user.
First of all, I would not touch dhcpcd.conf for a while.
Is it assumed that ovs-system should get its IP address from DHCP?
If I understand it correctly, systemd-networkd may send DHCP request
itself, it does not need dhcpcd helper. NetworkManager is not only UI,
it may manage interfaces. I would not be surprised if more than one tool
tries to manage ovs-system.
Perhaps some of the following command may shed some light on what really
happens:
systemctl --failed
networkctl list
networkctl status ovs-system
Last command should show Network File name if the interface is really
managed by systemd-networkd. Please, post its content
nmcli general status
nmcli device
nmcli -f CONNECTIONS device show ovs-system
ifquery --list
and check if /etc/network/interfaces and /etc/network/interfaces.d for
ovs-system entries
See also
https://wiki.debian.org/NetworkConfiguration
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-26 18:10 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G3sH7-8FkL-17@gated-at.bofh.it> |
| In reply to | #255386 |
On Sun 26 Feb 2023 at 22:11:30 (+0700), Max Nikulin wrote: > On 26/02/2023 18:18, Geert Stappers wrote: > > AIUI is systemd-networkd the main player, dhcpcd some helper > > and NetworkManager for contact with user. > > First of all, I would not touch dhcpcd.conf for a while. > > Is it assumed that ovs-system should get its IP address from DHCP? > > If I understand it correctly, systemd-networkd may send DHCP request > itself, it does not need dhcpcd helper. Yes, if you configure it to, eg: # /etc/systemd/network/80-wifi.network for systemd-networkd last edited 2022-09-30 [Match] Name=wl* [Network] DHCP=ipv4 IgnoreCarrierLoss=true [DHCPv4] RouteMetric=20 # which gave this morning (daemon.log): avahi-daemon[359]: Joining mDNS multicast group on interface wlp2s4.IPv4 with address 192.168.1.10. systemd-networkd[216]: wlp2s4: Gained carrier avahi-daemon[359]: New relevant interface wlp2s4.IPv4 for mDNS. avahi-daemon[359]: Registering new address record for 192.168.1.10 on wlp2s4.IPv4. systemd-networkd[216]: wlp2s4: DHCPv4 address 192.168.1.10/24 via 192.168.1.1 systemd[1]: Started Getty on tty1. systemd[1]: Reached target Login Prompts. (man 5 systemd.network) and: $ ip r default via 192.168.1.1 dev wlp2s4 proto dhcp src 192.168.1.10 metric 20 192.168.1.0/24 dev wlp2s4 proto kernel scope link src 192.168.1.10 192.168.1.1 dev wlp2s4 proto dhcp scope link src 192.168.1.10 metric 20 $ > NetworkManager is not only UI, > it may manage interfaces. I would not be surprised if more than one > tool tries to manage ovs-system. > > Perhaps some of the following command may shed some light on what > really happens: > > systemctl --failed > networkctl list > networkctl status ovs-system This long thread seems to be turning into a game of 20 Questions. It would be nice to see some of the OP's configuration, rather than just a few log extracts and a "How do I get rid of …". As it is, the OP has said "no more route 169.254.0.0/16 for device ovs-system", so perhaps all that's left is to leave that as solved, and tiptoe over to the alternate OP (CB) and see if they decide to restore the removed and disabled packages (XFCE and avahi-daemon) to check whether their 169.254.… addresses return. > Last command should show Network File name if the interface is really > managed by systemd-networkd. Please, post its content > > nmcli general status > nmcli device > nmcli -f CONNECTIONS device show ovs-system > > ifquery --list > > and check if /etc/network/interfaces and /etc/network/interfaces.d for > ovs-system entries > > See also > https://wiki.debian.org/NetworkConfiguration > Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-02-25 04:00 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G2SWZ-8ilL-1@gated-at.bofh.it> |
| In reply to | #255358 |
On Fri 24 Feb 2023 at 22:43:49 (+0100), Geert Stappers wrote: > On Fri, Feb 24, 2023 at 01:25:55PM -0600, David Wright wrote: > > On Fri 24 Feb 2023 at 19:41:26 (+0100), Christoph Brinkhaus wrote: > > > Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin: > > .... > > > > > > > > > I mean IPv4 link local addresses 169.254.x.y. My impression is that > > > > avahi-autoipd was created for the cases when there is no point to setup > > > > centralized DHCP server. On the other hand I agree that a router (and so > > > > DHCP out of the box) is more wide spread configuration than connecting a > > > > couple of devices directly or through a switch. > > > > > > I think so, too. > > > > Well, you typically only get a level of Recommended for avahi-autoipd > > when you install on a laptop, which is a reasonable choice for the > > debian-installer to make. Otherwise it's either a Suggests, or the > > sysadmin has to choose it off their own bat. But I guess their are > > a lot of laptops, now they are affordable, that aren't really used > > in the way they were intended, but just as more flexible desktops. > > Having `apt purge avahi-autoipd` still gets me "auto IPv4 address" > > Ideas how to avoid it are welcome. > > > <screenshot> > $ dpkg -l '*avahi*ip*' > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==============-============-============-================================= > un avahi-autoipd <none> <none> (no description available) > $ uptime > 22:45:25 up 1 min, 1 user, load average: 0.02, 0.04, 0.05 > $ ip route | grep system > 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004 > $ > </screenshot> I see you rebooted, and you get the same address. It's ambiguous as to why: it could have been stored, which makes things more efficient when a number of machines start up and don't have to renegotiate; or it could have been recomputed anew by a pseudorandom process on a host-dependent seed, which would generate the same sequence of tries each time you boot. A couple of odd points: . I notice that certain files in the openvswitch packages seem to generate 169.254.… addresses, . There's a long discussion about getting the network to come up in the right order, which seems to suggest that there's a fair chance of getting it wrong. > Silence is hard to parse It's ironic that this is your signature. AFAICT we've been told a total of: . you installed package openvswitch-switch, . 169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004 is in the routing table in the company of ?, . configured with network-manager? and systemd-networkd? (not sure how they interact), . systemd-networkd-wait-online waits for any? interface to be up, but the tests are flawed, and the order seems to be of no concern notwithstanding the long discussion mentioned. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2023-02-25 04:40 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G2TzH-8iUC-1@gated-at.bofh.it> |
| In reply to | #255361 |
On Fri, Feb 24, 2023 at 9:51 PM David Wright <deblis@lionunicorn.co.uk> wrote: > > On Fri 24 Feb 2023 at 22:43:49 (+0100), Geert Stappers wrote: > > [...] > I see you rebooted, and you get the same address. It's ambiguous as > to why: it could have been stored, which makes things more efficient > when a number of machines start up and don't have to renegotiate; > or it could have been recomputed anew by a pseudorandom process on a > host-dependent seed, which would generate the same sequence of tries > each time you boot. APIPA's use a deterministic process to generate the random host portion of the address. They will generate the same host portion of the address across reboots and restarts without the need to save state. Jeff
[toc] | [prev] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-25 13:50 +0100 |
| Subject | Re: Remove route '169.254.0.0/16 dev ovs-system' |
| Message-ID | <G329X-8ogY-3@gated-at.bofh.it> |
| In reply to | #255354 |
Am Fri, Feb 24, 2023 at 07:41:26PM +0100 schrieb Christoph Brinkhaus: I reply to myself thanking Max. > Am Fri, Feb 24, 2023 at 10:09:34PM +0700 schrieb Max Nikulin: > > On 22/02/2023 23:45, Christoph Brinkhaus wrote: > > > Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin: > > > > On 22/02/2023 01:26, Christoph Brinkhaus wrote: [snip] > > I have no experience with unbound and I am not sure at which moment it > > notifies systemd that the service is ready. However I have found a recent > > bug > > https://github.com/NLnetLabs/unbound/issues/773 > > "When used with systemd-networkd, unbound does not start until > > systemd-networkd-wait-online.service times out" > > > > Perhaps the package in Debian has an older version of the unbound.service > > file and so is not affected. > > > Hi Max, > > I have observed lines below in journald: > > Feb 22 15:41:44 lenovo systemd[1]: Reached target Network is Online. > Feb 22 15:41:44 lenovo systemd[1]: Failed to start Wait for Network to be Configured. > Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'. > Feb 22 15:41:44 lenovo systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE > Feb 22 15:41:44 lenovo systemd-networkd-wait-online[362]: Event loop failed: Connection timed out > Feb 22 15:41:25 lenovo systemd[1]: anacron.service: Succeeded. > Feb 22 15:41:25 lenovo anacron[3261]: Normal exit (0 jobs run) > Feb 22 15:41:25 lenovo anacron[3261]: Anacron 2.3 started on 2023-02-22 > Feb 22 15:41:25 lenovo systemd[1]: Started Run anacron jobs. > > This looks related, thank you very much! > I will have a look at the link. Dear Max, the method descriped in the link above helped to fix the issue. Now there are no messages reported by journald as above. Thank you very much for the kind help! [snip] Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-02-26 16:40 +0100 |
| Subject | unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') |
| Message-ID | <G3ri1-8Ek5-3@gated-at.bofh.it> |
| In reply to | #255369 |
On 25/02/2023 19:49, Christoph Brinkhaus wrote: > Now there are no messages reported by journald as above. I am curious if fixing unbound and so network-online.target helped to avoid 169.254.x.y address in your case. Can fetchmail work without a kludge you added to achieve some delay? My expectation is that unbound.service may be dropped from Requires= and After= in fetchmail.service, but both fields should have network-online.target. I forgot that debugging of such issues should be started with "systemctl --failed".
[toc] | [prev] | [next] | [standalone]
| From | Christoph Brinkhaus <c.brinkhaus@t-online.de> |
|---|---|
| Date | 2023-02-26 17:30 +0100 |
| Subject | Re: unbound and fetchmail (was: Re: Remove route '169.254.0.0/16 dev ovs-system') |
| Message-ID | <G3s4p-8ER5-1@gated-at.bofh.it> |
| In reply to | #255387 |
Am Sun, Feb 26, 2023 at 10:33:19PM +0700 schrieb Max Nikulin: > On 25/02/2023 19:49, Christoph Brinkhaus wrote: > > Now there are no messages reported by journald as above. > > I am curious if fixing unbound and so network-online.target helped to avoid > 169.254.x.y address in your case. I am not sure because I have disabled/deinstalled stuff which triggered the assignment of the 149.254.x.y address. > Can fetchmail work without a kludge you > added to achieve some delay? My expectation is that unbound.service may be > dropped from Requires= and After= in fetchmail.service, but both fields > should have network-online.target. You are right, there is no need anymore to check if the mail server can be resolved before starting fetchmail. Nevertheless I still have the unbound.service and the opensmtpd.service in the Requires= and After= sections. The reason is that incoming mails are routed via opensmtpd because fetchmail runs as an unprivileged user. Additionally the setup is indemendent of the mail server. Then the mails are sorted by maildrop. As far as I remember forwarding the mails from an unprivileged fetchmail to maildrop running as my user did not work. Now incoming mails appear in /var/log/mail.log, too which is also nice. > I forgot that debugging of such issues should be started with "systemctl > --failed". I have still a lot to learn. Kind regards, Christoph -- Ist die Katze gesund schmeckt sie dem Hund.
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.debian.user
csiph-web