Re: [systemd-devel] Starting a service before any networking

[Demi Marie Obenour]

On Tue, Sep 26, 2023 at 11:50:55AM +0100, Mark Rogers wrote:
> I'm sure this is trivial but I've gone round in circles without success.
> 
> I have a script which reads from an SQLite database and generates various
> system configuration files - at the moment these are dhcpcd.conf and
> wpa_supplicant.conf but this might grow in future.
> 
> As such the only dependency the script has is that the filesystem is up and
> running. But the script must complete before anything that the script
> manages the configuration file for.
> 
> My current unit looks like this:
> [Unit]
> Before=networking.service
> After=local-fs.target
> 
> [Service]
> Type=oneshot
> ExectStart=/path/to/script
> 
> [Install]
> RequiredBy=network.target
> 
> Where am I going wrong and what is the right way to do this?
> 
> I've also tried Before=network-pre.target and Wants=network-pre.target
> without success - it was that not working that set me off trying to fix it.

RequiredBy=network-pre.target should be sufficient, but unfortunately
lots of stuff (like systemd-networkd) that should have
Requires=network-pre.target doesn't.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab


signature.asc
Description: PGP signature

Re: [systemd-devel] Starting a service before any networking

[Mark Rogers]

On Tue, 26 Sept 2023 at 19:38, Mantas Mikulėnas  wrote:

> That's not a race condition; it's a fault in the network interface
> itself. "NO-CARRIER" means it's physically unable to establish the
> Ethernet link – an external condition that the service ordering has no
> effect on.
>

That's interesting.

In that case, how is it that
ip link set eth0 down
ip link set eth0 up
.. consistently brings the network up? (I have tested that sequence dozens
of times.) What is that doing that isn't happening during a normal boot?

This being a Raspberry Pi I believe that the Ethernet port hangs of the USB
bus internally in case that's relevant.

(I should be able to find another Pi to test for any physical hardware
issues, I'll try that tomorrow.)
-- 
Mark Rogers

Re: [systemd-devel] Starting a service before any networking

[Mantas Mikulėnas]

On 2023-09-26 21:31, Mark Rogers wrote:
On Tue, 26 Sept 2023 at 13:44, Mantas Mikulėnas > wrote:



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
"" within the interface flags?


eth0:  mtu 1500 qdisc pfifo_fast 
state DOWN group default qlen 1000


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.


That's not a race condition; it's a fault in the network interface 
itself. "NO-CARRIER" means it's physically unable to establish the 
Ethernet link – an external condition that the service ordering has no 
effect on.


(The interface *is* already brought "up" – in the `ip link set` sense – 
because it shows the  flag, which was probably done by dhcpcd when 
it started up; now the DHCP client is sitting there waiting for carrier 
before it can do anything else.)


At this stage ordering is not a problem because dhcpcd, like any 
self-respecting DHCP client, is able to monitor carrier status; it 
doesn't just immediately give up.

Re: [systemd-devel] Starting a service before any networking

[Mark Rogers]

On Tue, 26 Sept 2023 at 13:44, Mantas Mikulėnas  wrote:

> I think you're confusing two different states, which have similar
> indications – "administrative" up/down that you control (the "" flag,
> with nothing shown when down) and "operational" up/down that represents the
> actual interface status (the "" vs "" flags and/or the
> "state XXX" field).
>

Yes I am, thanks for clarifying.


> "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  (i.e. turned on).
>
> 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
> "" within the interface flags?
>

eth0:  mtu 1500 qdisc pfifo_fast state
DOWN group default qlen 1000

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.


> `systemctl cat` for direct configuration and `systemctl list-dependencies
> --after` (if I remember it right) should be a good start.
>

So here is what I now have. My unit is now this:
[Unit]
Before=network-pre.target dhcpcd.service
Wants=network-pre.target
[Service]
Type=oneshot
ExecStart=/path/to/script
[Install]
RequiredBy=network.target

Note I added dhcpcd.service to Before as it consistently starts too early
otherwise.

The dhcpcd unit config is (I haven't changed anything here):
[Unit]
Wants=network.target
Before=network.target
[Service]
Type=forking
PIDFile=/run/dhcpcd.pid
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -b
ExecStop=/sbin/dhcpcd -x
[Install]
WantedBy=multi-user.target
Alias=dhcpcd5.service

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.

--
Mark Rogers

[systemd-devel] udev database cross-version compatibility

[Valentin David]

Hello,

Back in 2014 and again in 2020, there were discussions on the mailing-list 
related to udev database version safety. This was important to know if libudev 
from a container could access to /run/udev/data files safely. Given then 
libudev and systemd-udevd would be potentially different version.

The conclusion was that there was no guarantee. And based on that flatpak has 
not provided /run/udev/data to applications.

Later, the format changed in #16853 (udev: make uevents "sticky"). But this 
caused issue #17605 (Units with BindsTo= are being killed on upgrade 
from v246 to v247).

This was fixed by #17622 (sd-device: make sd_device_has_current_tag() 
compatible with udev database generated by older udevd).

It seems to me, because udev needs to handle upgrade and downgrade, that it 
will continue to handle some compatibility across versions.

Is it safe now for flatpak to provide /run/udev/data to containers?

(Also, snapd does it, oops)

--
Valentin David
m...@valentindavid.com

Re: [systemd-devel] Starting a service before any networking

[Mantas Mikulėnas]

On Tue, Sep 26, 2023, 15:32 Mark Rogers  wrote:

> On Tue, 26 Sept 2023 at 13:08, Mantas Mikulėnas  wrote:
>
>> Depends on what exactly runs dhcpcd and wpa_supplicant. Is that done by
>> networking.service (ifupdown)? NetworkManager? Are they standalone services?
>>
>
> How do I tell?
>

Run `systemctl status ` or browse `systemd-cgls` to map a process to
its .service unit.


> (System is a Pi running an elderly Raspbian. The issue I am having is that
> the device is not getting an IP address - if i wait until booted I have to
> issue "ip link set eth0 down" and "ip link set eth0 up" to get it to retry
> the DHCP request
>


("up" alone isn't sufficient, despite "ip addr" showing the interface as
> DOWN.
>

I think you're confusing two different states, which have similar
indications – "administrative" up/down that you control (the "" flag,
with nothing shown when down) and "operational" up/down that represents the
actual interface status (the "" vs "" flags and/or the
"state XXX" field).

"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  (i.e. turned on).

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
"" within the interface flags?

I am assuming that this is because the config file isn't in place when
> dhcpcd starts but I may be mistaken.)
>
>
>> I would generally expect Before/Wants=network-pre.target to work, but
>> that relies on your network services themselves being set up correctly –
>> they too need to order themselves After that target.
>>
>
> In that case I should probably return to Before/Wants=network-pre.target
> and work out what is breaking it, but same question as above: how do I
> figure that out?
>

`systemctl cat` for direct configuration and `systemctl list-dependencies
--after` (if I remember it right) should be a good start.



> --
> Mark Rogers
>
>

Re: [systemd-devel] Starting a service before any networking

[Mark Rogers]

On Tue, 26 Sept 2023 at 13:08, Mantas Mikulėnas  wrote:

> Depends on what exactly runs dhcpcd and wpa_supplicant. Is that done by
> networking.service (ifupdown)? NetworkManager? Are they standalone services?
>

How do I tell?

(System is a Pi running an elderly Raspbian. The issue I am having is that
the device is not getting an IP address - if i wait until booted I have to
issue "ip link set eth0 down" and "ip link set eth0 up" to get it to retry
the DHCP request ("up" alone isn't sufficient, despite "ip addr" showing
the interface as DOWN. I am assuming that this is because the config file
isn't in place when dhcpcd starts but I may be mistaken.)


> I would generally expect Before/Wants=network-pre.target to work, but that
> relies on your network services themselves being set up correctly – they
> too need to order themselves After that target.
>

In that case I should probably return to Before/Wants=network-pre.target
and work out what is breaking it, but same question as above: how do I
figure that out?

-- 
Mark Rogers

Re: [systemd-devel] Starting a service before any networking

[Mantas Mikulėnas]

Depends on what exactly runs dhcpcd and wpa_supplicant. Is that done by
networking.service (ifupdown)? NetworkManager? Are they standalone services?

I would generally expect Before/Wants=network-pre.target to work, but that
relies on your network services themselves being set up correctly – they
too need to order themselves After that target.

On Tue, Sep 26, 2023, 13:51 Mark Rogers  wrote:

> I'm sure this is trivial but I've gone round in circles without success.
>
> I have a script which reads from an SQLite database and generates various
> system configuration files - at the moment these are dhcpcd.conf and
> wpa_supplicant.conf but this might grow in future.
>
> As such the only dependency the script has is that the filesystem is up
> and running. But the script must complete before anything that the script
> manages the configuration file for.
>
> My current unit looks like this:
> [Unit]
> Before=networking.service
> After=local-fs.target
>
> [Service]
> Type=oneshot
> ExectStart=/path/to/script
>
> [Install]
> RequiredBy=network.target
>
> Where am I going wrong and what is the right way to do this?
>
> I've also tried Before=network-pre.target and Wants=network-pre.target
> without success - it was that not working that set me off trying to fix it.
> --
> Mark Rogers
>
>

[systemd-devel] How to get Credential into Environment variable?

[chandler]

Hi all,

    I'm not quite grasping something here... I've just learned about
`systemd-creds` and now trying to utilize it with a service which
depends on a secret stored in an environment variable (or passed as a
CLI option).

Normally I could use a line like:

`Environment=SEC=1234`

Now I've:

1) Given "1234" to `systemd-ask-password -n | systemd-creds encrypt
--name=secret --pretty - -`
2) Put the resulting `SetCredentialEncrypted=secret: ...` under the
[Service] section
3) Failing with `Environment=SEC=%d/secret`

Now `SEC=/run/credentials/myService.service/secret` but I need the value
from the file, which I verified with a simple `ExecStart=checkEnv.sh`
which runs `cat ${SEC}` which prints `1234`.

Also tried putting the secret, e.g. "1234", into a temp file `/tmp/sec`
and ran:

`systemd-creds encrypt --name=secret --pretty /tmp/sec -`

but the results are the same.

How to get `SEC=1234` basically?  I have to use `ExecStartPre=` and run
a pre-script that defines `SEC` with shell code?  Something like
`SEC=$(cat %d/secret)` is all that's needed right?  Or it needs to be
exported too at this point?  Doesn't that defeat the purpose of
`systemd-creds` now?  Maybe I can just put that in the `ExecStart=` line
instead... will keep trying in the mean time

Thanks

[systemd-devel] Starting a service before any networking

[Mark Rogers]

I'm sure this is trivial but I've gone round in circles without success.

I have a script which reads from an SQLite database and generates various
system configuration files - at the moment these are dhcpcd.conf and
wpa_supplicant.conf but this might grow in future.

As such the only dependency the script has is that the filesystem is up and
running. But the script must complete before anything that the script
manages the configuration file for.

My current unit looks like this:
[Unit]
Before=networking.service
After=local-fs.target

[Service]
Type=oneshot
ExectStart=/path/to/script

[Install]
RequiredBy=network.target

Where am I going wrong and what is the right way to do this?

I've also tried Before=network-pre.target and Wants=network-pre.target
without success - it was that not working that set me off trying to fix it.
-- 
Mark Rogers