Re: [systemd-devel] Ensuring that a unit starts before any networking
On Di, 30.06.20 11:45, Mark Rogers (m...@more-solutions.co.uk) wrote: > >From that, is it reasonable to conclude that this is just an omission that > has no potential negative effects from being fixed? I can't see any reason > why adding After=network-pre.target would have direct a negative impact > (it's plausible that on some systems it could subtly alter startup ordering > and expose a bug that was previously hidden by luck, but that's not a > reason to avoid doing it) and so there is no good reason not to do this, > but my knowledge of this isn't adequate to make an informed statement on > that matter. Before I make the argument for it being fixed I want to be > sure of my argument! well, one never knows what might triger bugs somewhere, but afaics this should be a relatively riskless fix. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
Am 30.06.20 um 14:55 schrieb Simon McVittie: > Adding After=network-pre.target to dhcpcd.service is probably also not > a bad idea. It isn't clear to me whether dhcpcd brings up interfaces of > its own accord just because you start it as a systemd unit it just fails when like in the example below the interface "br-guest" isn't already there, and hence it's not that simple to say when a dhcp service should be started i just made it all easier by throw away all the NetworkManager, systemd-networkd or whatever stuff and wrote a oneshot-unit with a ton of ExecStart configuring all my interfaces, bridges and hostapd-instances [root@srv-rhsoft:~]$ cat /etc/systemd/system/dhcpd-guest.service [Unit] Description=DHCPD Guest-WLAN After=network-up.service Requires=network-online.target network-up.service [Service] Type=notify ExecStart=/usr/sbin/dhcpd -4 -f -cf /etc/dhcp/dhcpd-guest.conf -lf /var/lib/dhcpd/dhcpd-guest.leases -user dhcpd -group dhcpd --no-pid br-guest Restart=always ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Tue, 30 Jun 2020 at 12:59:54 +0100, Mark Rogers wrote: > On Tue, 30 Jun 2020 at 12:13, Simon McVittie wrote: > > > > I would have expected this to be done in some "larger" network management > > component that is responsible for bringing up network interfaces according > > to your configuration, rather than necessarily dhcpcd.service itself. > > In which case one would expect dhcpcd to depend on that instead I meant the other way around, actually: a larger network management component like ifupdown (which has policy, not just mechanism) tells dhcpcd to start managing an interface, and that larger component conceptually depends on dhcpcd. (It might not be an explicit dependency because of automatic activation.) Adding After=network-pre.target to dhcpcd.service is probably also not a bad idea. It isn't clear to me whether dhcpcd brings up interfaces of its own accord just because you start it as a systemd unit, or whether it brings up interfaces only when specifically requested by something like ifupdown or NetworkManager, or some mixture. If it can be configured to bring up interfaces on its own, independent of things like ifupdown, then it is taking on at least part of the role of a network management component itself, in which case it does need After=network-pre.target. > > Typically server-class systems will use either ifupdown or > > systemd-networkd, which are ideal for relatively static network > > configurations that are set up by a sysadmin. > > It's definitely not systemd-networkd, to my untrained eye it looks > like ifupdown is there but how do I confirm? Your unit in https://lists.freedesktop.org/archives/systemd-devel/2020-June/044784.html (which I missed when replying earlier) refers to networking.service, which is part of ifupdown. Depending on precisely what configuration you're writing out from your database in your use-case-specific unit, you might be configuring ifupdown to do things (in which case ifupdown's After=network-pre.target should be enough), or you might be configuring dhcpcd to go behind ifupdown's back to do things (in which case your use-case-specific unit needs to happen before dhcpcd), or something else entirely. You'll need to look at and understand the overall system you have set up. You mentioned wanting to make your unit network-stack-agnostic, but adding an extra layer of abstraction cannot solve all problems, and in particular it cannot solve the problem "too many layers of abstraction". At some point someone or something has to make a decision and actually do something concrete :-) smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Tue, 30 Jun 2020 at 12:13, Simon McVittie wrote: > > I would have expected this to be done in some "larger" network management > component that is responsible for bringing up network interfaces according > to your configuration, rather than necessarily dhcpcd.service itself. In which case one would expect dhcpcd to depend on that instead; I can't see any obvious dependencies that would apply but I'm somewhat out of my depth here. > You mentioned Raspbian, which is a Debian derivative? Yes, Raspbian is Debian a derivative. > Typically server-class systems will use either ifupdown or > systemd-networkd, which are ideal for relatively static network > configurations that are set up by a sysadmin. It's definitely not systemd-networkd, to my untrained eye it looks like ifupdown is there but how do I confirm? dhcpcd seems to start very early in the boot and doesn't seem to be After anything on my Raspbian box. networking.service certainly includes After=network-pre.target and Before=network.target, but dhcpcd also includes Before=network.target - I can't see any combination of dependencies that would put dhcpcd.service later than networking.service. It's quite plausible that the "bug" here isn't necessarily the need for After=network-pre.target but as far as I can tell it is missing something. > If Raspbian does its own thing rather than recycling Debian components > for this, then it might need a separate bug report. I don't have a Debian box to check dhcpcd dependencies but I would assume that they're lifted from Debian, albeit that they may or may not be default Debian components. I have raised a Raspbian bug, which references this thread, so I'll see where that takes me. -- Mark Rogers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Tue, 30 Jun 2020 at 11:27:30 +0200, Lennart Poettering wrote: > On Sa, 27.06.20 15:54, Mark Rogers (m...@more-solutions.co.uk) wrote: > > Adding After=network-pre.target to dhcpcd.service seems to have > > resolved it, and taught me a lesson in the process. > > > > Is there an obvious reason I'm missing why these aren't distro > > defaults? (Is this a "bug" in the network management tools' unit > > files? Would "fixing" this at the distro level have any likely side > > effects?) > > Yes, this is a bug in the the distro packaging. Please file a bug > against your distro, so that they add After=network-pre.target. I would have expected this to be done in some "larger" network management component that is responsible for bringing up network interfaces according to your configuration, rather than necessarily dhcpcd.service itself. You mentioned Raspbian, which is a Debian derivative? On Debian systems, network device management is typically provided by either ifupdown (the traditional/historical network management component in Debian), systemd-networkd, NetworkManager or wicd. If those aren't After network-pre.target, then they should be. Typically server-class systems will use either ifupdown or systemd-networkd, which are ideal for relatively static network configurations that are set up by a sysadmin. Portable/roaming systems like laptops will typically use either NetworkManager or wicd, which are ideal for dynamic network configuration through a GUI (and in particular, some desktop environments like GNOME have built-in support for NetworkManager). Desktop and embedded systems could go either way. In ifupdown, the networking.service and ifup@.service units are ordered After=network-pre.target, which I think should be sufficient. NetworkManager.service and systemd-networkd.service also look correct. However, wicd does not currently appear to have implemented this (I've opened a Debian bug). If Raspbian does its own thing rather than recycling Debian components for this, then it might need a separate bug report. smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Tue, 30 Jun 2020 at 10:27, Lennart Poettering wrote: > Yes, this is a bug in the the distro packaging. Please file a bug > against your distro, so that they add After=network-pre.target. > Will do. > My educated guess is that, it's not trvial to get this right: we > document what network-pre.target is for in systemd.special(7) man > page, but I figure not everyone looks there. And i guess one most know > a certain level of systemd to understand what this actually means for > a specific implementation. > Fair enough. >From that, is it reasonable to conclude that this is just an omission that has no potential negative effects from being fixed? I can't see any reason why adding After=network-pre.target would have direct a negative impact (it's plausible that on some systems it could subtly alter startup ordering and expose a bug that was previously hidden by luck, but that's not a reason to avoid doing it) and so there is no good reason not to do this, but my knowledge of this isn't adequate to make an informed statement on that matter. Before I make the argument for it being fixed I want to be sure of my argument! -- Mark Rogers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sa, 27.06.20 15:54, Mark Rogers (m...@more-solutions.co.uk) wrote: > > It could very well be because of the dhcpcd.service you're using. > > > > I don't know what it's like on Raspbian, but on Debian this unit appears > > to have no ordering with respect to network.target or network-pre.target > > at all. > > Ah, therein lies my failing - I assumed OS supplied units wouldn't > need adapting... > > Adding After=network-pre.target to dhcpcd.service seems to have > resolved it, and taught me a lesson in the process. > > Is there an obvious reason I'm missing why these aren't distro > defaults? (Is this a "bug" in the network management tools' unit > files? Would "fixing" this at the distro level have any likely side > effects?) Yes, this is a bug in the the distro packaging. Please file a bug against your distro, so that they add After=network-pre.target. My educated guess is that, it's not trvial to get this right: we document what network-pre.target is for in systemd.special(7) man page, but I figure not everyone looks there. And i guess one most know a certain level of systemd to understand what this actually means for a specific implementation. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
Am 27.06.20 um 16:54 schrieb Mark Rogers: > Ah, therein lies my failing - I assumed OS supplied units wouldn't > need adapting... > > Adding After=network-pre.target to dhcpcd.service seems to have > resolved it, and taught me a lesson in the process. as often it depends - on machines with more than one network dhcpd is often bound to a specific interface which would fail when that is a bridge which don't exist before the network none of the 3 interfaces would exist here before my network-up.service dhcpd 1574 0.0 0.0 18820 10472 ?Ss Jun25 0:36 /usr/sbin/dhcpd -4 -f -cf /etc/dhcp/dhcpd-guest.conf -lf /var/lib/dhcpd/dhcpd-guest.leases -user dhcpd -group dhcpd --no-pid br-guest dhcpd 1575 0.0 0.0 19196 10764 ?Ss Jun25 0:37 /usr/sbin/dhcpd -4 -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid br-lan dhcpd 1589 0.0 0.0 19204 10848 ?Ss Jun25 0:31 /usr/sbin/dhcpd -4 -f -cf /etc/dhcp/dhcpd-vmware.conf -lf /var/lib/dhcpd/dhcpd-vmware.leases -user dhcpd -group dhcpd --no-pid vmnet8 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, 27 Jun 2020 at 13:04, Andrei Borzenkov wrote: > All other units that implement networking must have > After=network-pre.target for the above to do anything. Do they? .. and .. On Sat, 27 Jun 2020 at 13:08, Michael Chapman wrote: > It could very well be because of the dhcpcd.service you're using. > > I don't know what it's like on Raspbian, but on Debian this unit appears > to have no ordering with respect to network.target or network-pre.target > at all. Ah, therein lies my failing - I assumed OS supplied units wouldn't need adapting... Adding After=network-pre.target to dhcpcd.service seems to have resolved it, and taught me a lesson in the process. Is there an obvious reason I'm missing why these aren't distro defaults? (Is this a "bug" in the network management tools' unit files? Would "fixing" this at the distro level have any likely side effects?) -- Mark Rogers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, 27 Jun 2020, Mark Rogers wrote: > On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek > wrote: > > You should use Before=network-pre.target, Wants=network-pre.target. > > Thanks, tried that but still not working: It could very well be because of the dhcpcd.service you're using. I don't know what it's like on Raspbian, but on Debian this unit appears to have no ordering with respect to network.target or network-pre.target at all. On Fedora, this unit is Before=network.target, but it has no ordering with respect to network-pre.target. So even there this wouldn't help you. In my experience a lot of network management software's systemd units don't use these target units properly.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, Jun 27, 2020 at 11:42:00AM +0100, Mark Rogers wrote: > On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek > wrote: > > You should use Before=network-pre.target, Wants=network-pre.target. > > Thanks, tried that but still not working: > > $ journalctl -b | grep -Ei '(db2config|dhcpcd)' > Feb 14 10:12:03 localhost systemd[1]: Starting dhcpcd on all interfaces... > Feb 14 10:12:03 localhost dhcpcd[341]: read_config: fopen > `/etc/dhcpcd.conf': No such file or directory > [...] > Jun 27 10:19:39 localhost dhcpcd[341]: wlan0: /etc/wpa_supplicant.conf > does not exist > [...] > Jun 27 10:19:39 localhost dhcpcd[341]: read_config: fopen > `/etc/dhcpcd.conf': No such file or directory > [...] > Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting an IPv6 router > Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting a DHCP lease > Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config > Creating /tmp/sys//etc/dhcpcd.conf > Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config > Creating /tmp/sys//etc/wpa_supplicant/wpa_supplicant.conf > > (Comments about that extract: the jump from Feb to Jun I assume is the > clock getting updated from RTC, it's all from the same boot obviously; > also note my db2config script doesn't run until after hostname is set > which I would assume is set by the network startup?) > > Unit file is currently: > > [Unit] > Description=Config generation from DB > Before=network-pre.target > Wants=network-pre.target > > [Service] > Type=oneshot > ExecStart=/home/mark/bin/db2config.py > > [Install] > RequiredBy=network.target And how does the unit that is running dhcpcd look like? Zbyszek > After any changes I'm using > $ sudo systemctl daemon-reload > $ sudo systemctl reenable db2config.service > > ... although that's another area I'm not entirely clear about what > exactly is required after a unit file change. > > PS: Is list etiquette around here to CC on reply? Some love it, some > hate it, others don't care... reply-all is fine. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
27.06.2020 13:42, Mark Rogers пишет: > On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek > wrote: >> You should use Before=network-pre.target, Wants=network-pre.target. > > Thanks, tried that but still not working: > All other units that implement networking must have After=network-pre.target for the above to do anything. Do they? > $ journalctl -b | grep -Ei '(db2config|dhcpcd)' > Feb 14 10:12:03 localhost systemd[1]: Starting dhcpcd on all interfaces... > Feb 14 10:12:03 localhost dhcpcd[341]: read_config: fopen > `/etc/dhcpcd.conf': No such file or directory > [...] > Jun 27 10:19:39 localhost dhcpcd[341]: wlan0: /etc/wpa_supplicant.conf > does not exist > [...] > Jun 27 10:19:39 localhost dhcpcd[341]: read_config: fopen > `/etc/dhcpcd.conf': No such file or directory > [...] > Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting an IPv6 router > Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting a DHCP lease > Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config > Creating /tmp/sys//etc/dhcpcd.conf > Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config > Creating /tmp/sys//etc/wpa_supplicant/wpa_supplicant.conf > > (Comments about that extract: the jump from Feb to Jun I assume is the > clock getting updated from RTC, it's all from the same boot obviously; > also note my db2config script doesn't run until after hostname is set > which I would assume is set by the network startup?) > > Unit file is currently: > > [Unit] > Description=Config generation from DB > Before=network-pre.target > Wants=network-pre.target > > [Service] > Type=oneshot > ExecStart=/home/mark/bin/db2config.py > > [Install] > RequiredBy=network.target > > After any changes I'm using > $ sudo systemctl daemon-reload > $ sudo systemctl reenable db2config.service > > ... although that's another area I'm not entirely clear about what > exactly is required after a unit file change. > > PS: Is list etiquette around here to CC on reply? Some love it, some > hate it, others don't care... > > > -- > Mark Rogers > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
Just a wild guess, but I'd start with a combination of one of those: # - [Unit] Description=my service Before=network.target Before=systemd-networkd.service Before=network-online.target Before=systemd-networkd-wait-online.service ... [Install] WantedBy=Basic.target # - Probably someone will kill me for the basic target, which is fine, as long as the proper one is provided as well, and preferably with an explanation :) In fact, probably I'd create a new, dedicated target for that, like my.target. And if your script HAS to be finished, for networking to be run at all, you might want to add a drop in to systemd-networkd.service # - systemctl edit systemd-networkd.service [Unit] Requires=my.service After=my.service # - This is most likely not a final solution, but a way I would approach this matter and start to play. F.e., I am not sure, wether the drop in should really be for systemd-networkd.service or rather network.target. Play around. And I am assuming, you are using systemd-networkd, and not something else like networkmanager, in that case you have to adapt, of course. Until someone with proper knowledge replies, good luck and report back Am 27.06.20 um 10:34 schrieb Mark Rogers: This feels like something I should be easily able to answer from documentation/Google, and failing that from somewhere like StackOverflow, without troubling systemd-devel, but all my efforts have thus far failed [1] What is the correct way to ensure a script runs to completion before any networking units start? "The Internet" is abound with people asking the opposite question which hasn't helped my keyword-based searches. My use case (on a Raspberry Pi running Raspbian if it matters) is that I have network settings stored in a database from which I generate network configuration files (eg dhcpcd.conf) on boot, therefore they obviously need to be in place before dhcpcd starts. (Similarly wpa_supplicant.) Ideally I'd like to be agnostic about the actual network stack in my unit configuration (so not setting dependencies relating to dhcpcd, for example) but at this point I've tried pretty much everything without success so I'm obviously doing something stupid. I have tried multiple approaches so far but by current service file looks like this: [Unit] Description=Config generation from DB Before=networking.service [Service] Type=oneshot ExecStart=/home/mark/bin/db2config.py [Install] RequiredBy=network.target [1] https://stackoverflow.com/questions/62574482/ensuring-that-a-systemd-unit-starts-before-any-networking - no responses there to date, feel free to respond there for reputation or else I'll update it when I solve it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, 27 Jun 2020 at 11:51, Dave Howorth wrote: > A Pi doesn't normally have an RTC, so the mixup usually takes place > when the time is updated via NTP I believe. Do you have an RTC? Yes I do have an RTC. At that point in the logs dhcpcd hasn't started so it must be from the RTC (although nothing seems to appear in the logs from a quick glance). But I only mentioned it in passing because otherwise it looked like the logs were from different dates despite being from the same boot. > > also note my db2config script doesn't run until after hostname is set > > which I would assume is set by the network startup?) > > Well that depends how you've set the Pi up, so you tell us, don't > assume. If your script doesn't start until hostname is set and hostname > is set by dhcp then you have a fundamental problem. My script doesn't care about hostname. Hostname is set in /etc/hostname but I don't know when that is read (nor care unless it's a clue to why the script is running after networking starts despite my efforts! -- Mark Rogers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, 27 Jun 2020 11:42:00 +0100 Mark Rogers wrote: > On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek > wrote: > > You should use Before=network-pre.target, > > Wants=network-pre.target. > > Thanks, tried that but still not working: > > $ journalctl -b | grep -Ei '(db2config|dhcpcd)' > Feb 14 10:12:03 localhost systemd[1]: Starting dhcpcd on all > interfaces... Feb 14 10:12:03 localhost dhcpcd[341]: read_config: > fopen `/etc/dhcpcd.conf': No such file or directory > [...] > Jun 27 10:19:39 localhost dhcpcd[341]: wlan0: /etc/wpa_supplicant.conf > does not exist > [...] > Jun 27 10:19:39 localhost dhcpcd[341]: read_config: fopen > `/etc/dhcpcd.conf': No such file or directory > [...] > Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting an IPv6 router > Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting a DHCP lease > Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config > Creating /tmp/sys//etc/dhcpcd.conf > Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config > Creating /tmp/sys//etc/wpa_supplicant/wpa_supplicant.conf > > (Comments about that extract: the jump from Feb to Jun I assume is the > clock getting updated from RTC, it's all from the same boot obviously; A Pi doesn't normally have an RTC, so the mixup usually takes place when the time is updated via NTP I believe. Do you have an RTC? > also note my db2config script doesn't run until after hostname is set > which I would assume is set by the network startup?) Well that depends how you've set the Pi up, so you tell us, don't assume. If your script doesn't start until hostname is set and hostname is set by dhcp then you have a fundamental problem. > Unit file is currently: > > [Unit] > Description=Config generation from DB > Before=network-pre.target > Wants=network-pre.target > > [Service] > Type=oneshot > ExecStart=/home/mark/bin/db2config.py > > [Install] > RequiredBy=network.target > > After any changes I'm using > $ sudo systemctl daemon-reload > $ sudo systemctl reenable db2config.service > > ... although that's another area I'm not entirely clear about what > exactly is required after a unit file change. > > PS: Is list etiquette around here to CC on reply? Some love it, some > hate it, others don't care... > > > -- > Mark Rogers > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, 27 Jun 2020 at 11:06, Zbigniew Jędrzejewski-Szmek wrote: > You should use Before=network-pre.target, Wants=network-pre.target. Thanks, tried that but still not working: $ journalctl -b | grep -Ei '(db2config|dhcpcd)' Feb 14 10:12:03 localhost systemd[1]: Starting dhcpcd on all interfaces... Feb 14 10:12:03 localhost dhcpcd[341]: read_config: fopen `/etc/dhcpcd.conf': No such file or directory [...] Jun 27 10:19:39 localhost dhcpcd[341]: wlan0: /etc/wpa_supplicant.conf does not exist [...] Jun 27 10:19:39 localhost dhcpcd[341]: read_config: fopen `/etc/dhcpcd.conf': No such file or directory [...] Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting an IPv6 router Jun 27 10:19:40 localhost dhcpcd[341]: eth0: soliciting a DHCP lease Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config Creating /tmp/sys//etc/dhcpcd.conf Jun 27 10:19:41 mypi db2config.py[325]: 2020-06-27 10:19:41 db2config Creating /tmp/sys//etc/wpa_supplicant/wpa_supplicant.conf (Comments about that extract: the jump from Feb to Jun I assume is the clock getting updated from RTC, it's all from the same boot obviously; also note my db2config script doesn't run until after hostname is set which I would assume is set by the network startup?) Unit file is currently: [Unit] Description=Config generation from DB Before=network-pre.target Wants=network-pre.target [Service] Type=oneshot ExecStart=/home/mark/bin/db2config.py [Install] RequiredBy=network.target After any changes I'm using $ sudo systemctl daemon-reload $ sudo systemctl reenable db2config.service ... although that's another area I'm not entirely clear about what exactly is required after a unit file change. PS: Is list etiquette around here to CC on reply? Some love it, some hate it, others don't care... -- Mark Rogers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ensuring that a unit starts before any networking
On Sat, Jun 27, 2020 at 09:34:00AM +0100, Mark Rogers wrote: > I have tried multiple approaches so far but by current service file > looks like this: > > [Unit] > Description=Config generation from DB > Before=networking.service You should use Before=network-pre.target, Wants=network-pre.target. > [Service] > Type=oneshot > ExecStart=/home/mark/bin/db2config.py > > [Install] > RequiredBy=network.target > > [1] > https://stackoverflow.com/questions/62574482/ensuring-that-a-systemd-unit-starts-before-any-networking > - no responses there to date, feel free to respond there for > reputation or else I'll update it when I solve it. Yes, please update so. Also feel free to submit a PR for our man pages if you find the time. netowrk-pre.target is briefly explained in systemd.special(7), but maybe the network target deserve a separate section in bootup(7)? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Ensuring that a unit starts before any networking
This feels like something I should be easily able to answer from documentation/Google, and failing that from somewhere like StackOverflow, without troubling systemd-devel, but all my efforts have thus far failed [1] What is the correct way to ensure a script runs to completion before any networking units start? "The Internet" is abound with people asking the opposite question which hasn't helped my keyword-based searches. My use case (on a Raspberry Pi running Raspbian if it matters) is that I have network settings stored in a database from which I generate network configuration files (eg dhcpcd.conf) on boot, therefore they obviously need to be in place before dhcpcd starts. (Similarly wpa_supplicant.) Ideally I'd like to be agnostic about the actual network stack in my unit configuration (so not setting dependencies relating to dhcpcd, for example) but at this point I've tried pretty much everything without success so I'm obviously doing something stupid. I have tried multiple approaches so far but by current service file looks like this: [Unit] Description=Config generation from DB Before=networking.service [Service] Type=oneshot ExecStart=/home/mark/bin/db2config.py [Install] RequiredBy=network.target [1] https://stackoverflow.com/questions/62574482/ensuring-that-a-systemd-unit-starts-before-any-networking - no responses there to date, feel free to respond there for reputation or else I'll update it when I solve it. -- Mark Rogers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
