Re: Starting a service before any networking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 27, 2023 at 11:23 AM Mark Rogers <mark@xxxxxxxxxxxxxxxxxxxx> wrote:
On Tue, 26 Sept 2023 at 20:41, Mark Rogers <mark@xxxxxxxxxxxxxxxxxxxx> wrote:
(I should be able to find another Pi to test for any physical hardware issues, I'll try that tomorrow.)

I have today tested on a different Pi, different PSU, different cable, all with exactly the same results. There is definitely something about the early boot stages which is different from later on that means bringing the network up early (as happens now) will usually fail.

(Some more background: This is a heavily modified install for a specific application so it's almost certainly something I have broken somewhere. However it has worked for years, I'm trying to resolve an issue on a unit that was returned because of physical damage to the SD card, so I've rebuilt it from an old image and now have this problem. I just need to break down the boot sequence to find out which step is causing the interface to get into a state where it fails like this. Systemd version is 241.)

It might be an issue with the kernel driver for your Ethernet interface, then (as setting the interface 'up/down' usually reinitializes the controller) – or possibly a physical issue with your cable or your switch, but it doesn't seem like the kind of issue that userspace configuration should be *able* to lead to in the first place. (...except maybe for EEE "power saving" stuff that might tip over a really marginal link.)

(It's sort of like blaming a segfault crash on the user: if a program crashes, that's inherently a bug regardless of configuration. Here it's similar: if the Ethernet cable is really connected but the driver still reports "no carrier", that's either an interface issue or – if you see the same on multiple Pi's – perhaps a NIC driver issue, but it's not something that configuration ought to be *able* to do.)
 

Alternatively I guess there's the workaround option: detect the condition at a later stage of the boot and run the down/up sequence to fix it. If I try that, where is likely the best place in the sequence to put it? If I wanted to make it, in effect, part of the dhcpcd unit (in that when dhcpcd starts it first runs a down/up script), how should I do that without modifying system dhcpcd unit files?

Use the "drop-in" system (dhcpcd.service.d/*.conf), e.g. via `systemctl edit dhcpcd5`. Add a few ExecStartPre= commands in [Service] to have it "manually" bring the interface up, then down (possibly with a 'sleep .5' after each), and hopefully when dhcpcd brings it up the /second/ time it will work.

--
Mantas Mikulėnas

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux