Re: Starting a service before any networking

[Jetchko Jekov <jetchko.jekov@xxxxxxxxx>]

Actually, I believe the dhcpcd service is the wrong one here:

Looking at the dhcpcd.service's Unit section (in F39 at least) I see:

[Unit]
Description=A minimalistic network configuration daemon with DHCPv4,
rdisc and DHCPv6 support
Wants=network.target
Before=network.target

So it orders itself *before* network.target but only this is not enough.
It must also order itself After=network-pre.target

>From the docs:
network-pre.target  This passive target unit may be pulled in by
services that want to run before any network is set up, for example
for the purpose of setting up a firewall. All network management
software orders itself after this target, but does not pull it in.

And dhcpcd is a network management software

On Thu, Sep 28, 2023 at 4:46 PM Mantas Mikulėnas <grawity@xxxxxxxxx> wrote:
>
> On Wed, Sep 27, 2023 at 12:31 PM Mark Rogers <mark@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> On Wed, 27 Sept 2023 at 10:18, Mantas Mikulėnas <grawity@xxxxxxxxx> wrote:
>>>
>>> So now I'm curious: if the first command you run is to bring the interface *down*, then what exactly brought it up?
>>
>>
>> Good question. The reason for down/up was that this was working as a way to reset the connection after boot, so I just transferred that to the ExecStartPre.
>>
>> Looking at the "journalctl -u dhcpcd" output, this is what I see from my last boot:
>> Feb 14 10:12:05 pi systemd[1]: Starting dhcpcd on all interfaces...
>> Feb 14 10:12:05 pi ip[372]: 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
>> Feb 14 10:12:05 pi ip[372]:     link/ether b8:27:eb:0d:ee:bb brd ff:ff:ff:ff:ff:ff
>> Feb 14 10:12:05 pi ip[383]: 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
>> Feb 14 10:12:05 pi ip[383]:     link/ether b8:27:eb:0d:ee:bb brd ff:ff:ff:ff:ff:ff
>> Feb 14 10:12:06 pi dhcpcd[385]: wlan0: starting wpa_supplicant
>> Feb 14 10:12:36 pi dhcpcd[385]: timed out
>> Feb 14 10:12:36 pi systemd[1]: Started dhcpcd on all interfaces.
>> Feb 14 10:12:37 pi systemd[1]: Stopping dhcpcd on all interfaces...
>> Feb 14 10:12:37 pi dhcpcd[519]: sending signal TERM to pid 466
>> Feb 14 10:12:37 pi dhcpcd[519]: waiting for pid 466 to exit
>> Feb 14 10:12:38 pi systemd[1]: dhcpcd.service: Succeeded.
>> Feb 14 10:12:38 pi systemd[1]: Stopped dhcpcd on all interfaces.
>> Feb 14 10:12:38 pi systemd[1]: Starting dhcpcd on all interfaces...
>> Feb 14 10:12:38 pi ip[524]: 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
>> Feb 14 10:12:38 pi ip[524]:     link/ether b8:27:eb:0d:ee:bb brd ff:ff:ff:ff:ff:ff
>> Feb 14 10:12:38 pi ip[529]: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
>> Feb 14 10:12:38 pi ip[529]:     link/ether b8:27:eb:0d:ee:bb brd ff:ff:ff:ff:ff:ff
>> Feb 14 10:12:38 pi dhcpcd[530]: wlan0: starting wpa_supplicant
>> Feb 14 10:12:49 pi dhcpcd[530]: Too few arguments.
>> Feb 14 10:12:49 pi dhcpcd[530]: Too few arguments.
>> Feb 14 10:12:49 pi systemd[1]: Started dhcpcd on all interfaces.
>>
>>  (I deleted the "ip addr" output from the interfaces other than eth0 for brevity.)
>>
>> The interesting thing is surely that dhcpcd is being started twice. Assuming that was always happening then that suggests dhcpcd was bringing the network up early (and failing but leaving it in a "stuck" state) and then again later (where it was unable to recover from the first failure, but now can)?
>
>
> That's possible... but again, I don't see how it would get into this "stuck" state in any other way but driver and/or hardware issues, as the kernel driver is where the power-up sequence is done... dhcpcd (like 'ip link set eth0 up') pretty much just tells the OS to power the NIC on, then waits.
>
> (My previous laptop had a Realtek Ethernet NIC that often wouldn't recognize Ethernet link after suspend/resume until I removed it from the PCI bus... took several kernel releases until they fixed that.)
>
> --
> Mantas Mikulėnas