<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 26 Sept 2023 at 13:44, Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I think you're confusing two different states, which have similar indications – "administrative" up/down that you control (the "<UP>" flag, with nothing shown when down) and "operational" up/down that represents the actual interface status (the "<RUNNING>" vs "<NO_CARRIER>" flags and/or the "state XXX" field).</div></blockquote><div><br></div><div>Yes I am, thanks for clarifying.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">"state DOWN" is *not* directly controlled by `ip link set up` – it's the result of the interface being operative for any other reason even though it is administratively <UP> (i.e. turned on).</div><div dir="auto"><br></div><div dir="auto">I'm still not entirely sure of the situation but right now it sounds like the configuration is okay but the Ethernet interface is failing to establish a physical link on the first try. Does it also show "<UP,NO_CARRIER>" within the interface flags?</div></div></blockquote><div><br></div><div>eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000</div><div><br></div><div>I've done a lot more testing now and there's a race condition somewhere as it does sometimes (rarely) boot OK and get an IP address with no config changes.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">`systemctl cat` for direct configuration and `systemctl list-dependencies --after` (if I remember it right) should be a good start.</div></blockquote><div><br></div><div>So here is what I now have. My unit is now this:<br></div><div style="margin-left:40px"><span style="font-family:monospace">[Unit]<br>Before=network-pre.target dhcpcd.service<br>Wants=network-pre.target<br>[Service]<br>Type=oneshot<br>ExecStart=/path/to/script<br>[Install]<br>RequiredBy=network.target</span></div><div><br></div><div>Note I added dhcpcd.service to Before as it consistently starts too early otherwise.</div><div><br></div><div>The dhcpcd unit config is (I haven't changed anything here):<br></div><div style="margin-left:40px"><span style="font-family:monospace">[Unit]<br>Wants=network.target<br>Before=network.target<br>[Service]<br>Type=forking<br>PIDFile=/run/dhcpcd.pid<br>ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -b<br>ExecStop=/sbin/dhcpcd -x<br>[Install]<br>WantedBy=multi-user.target<br>Alias=dhcpcd5.service </span><br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">In this state dhcpcd consistently starts after my script but the DHCP issue I'm trying to fix continues, so the race may not related to dhcpcd after all.</div><div class="gmail_quote"><br></div><div class="gmail_quote">--<br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><div style="font-size:12.8px"><span style="font-size:12.8px">Mark Rogers</span></div></div></div></div></div></div></div></div>