[systemd-devel] dev-mmcblk0p2.device delay
Hello, I noticed that mounting partition takes more time on yocto thud regarding rocko. I checked the dev-mmcblk0p2.device in my case using systemd-bootchart. Is there any reason why this mouting delay was increased? Where the dev-mmcblk0p2.device comes from? I am not able to locate it in /lib/systemd/system, any help on this please? Best regards, Mohamed Ali ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-vconsole-setup.service: cannot open file de-latin1-nodeadkeys
is this a dracut or systemd bug in Fedora 32? the other failing services at bottom are a direct reuslt of this while everything seems to work fine, but i can't stand "failed" stuff when consider a dist-upgrade -- [root@rawhide ~]# systemctl status systemd-vconsole-setup.service ● systemd-vconsole-setup.service - Setup Virtual Console Loaded: loaded (/usr/lib/systemd/system/systemd-vconsole-setup.service; static; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2020-06-27 20:45:53 CEST; 51s ago Docs: man:systemd-vconsole-setup.service(8) man:vconsole.conf(5) Main PID: 209 (code=exited, status=1/FAILURE) CPU: 28ms Jun 27 20:45:54 rawhide.vmware.local systemd-vconsole-setup[214]: cannot open file de-latin1-nodeadkeys -- the file is obviously there and in fact is *used* for the VT because i have the correct keyboard layout and german umlauts and when i remove "KEYMAP=de-latin1-nodeadkeys" from "/etc/vconsole.conf" and run "dracut -f" i end with a english keyboard and enter my password is virtually impossible [root@rawhide ~]# lsinitrd | grep de-latin1-nodeadkey -rw-r--r-- 1 root root 493 Feb 10 11:26 usr/lib/kbd/keymaps/legacy/i386/qwertz/de-latin1-nodeadkeys.map -- [root@rawhide ~]# cat /etc/vconsole.conf FONT=latarcyrheb-sun16 KEYMAP=de-latin1-nodeadkeys -- -rw-r--r-- 1 root root 493 Feb 10 11:26 usr/lib/kbd/keymaps/legacy/i386/qwertz/de-latin1-nodeadkeys.map [root@rawhide ~]# cat /etc/vconsole.conf FONT=latarcyrheb-sun16 KEYMAP=de-latin1-nodeadkeys [root@rawhide ~]# cat /etc/default/grub GRUB_TIMEOUT=1 GRUB_DISTRIBUTOR="Fedora" GRUB_SAVEDEFAULT=false GRUB_TERMINAL_OUTPUT="console" GRUB_GFXPAYLOAD_LINUX="text" GRUB_CMDLINE_LINUX="nosmp edd=off audit=0 rd.plymouth=0 plymouth.enable=0 zswap.enabled=0 net.ifnames=0 biosdevname=0 nodmraid raid=noautodetect nomodeset selinux=0 noswapaccount nousb usbcore.nousb noisapnp noresume hibernate=no kaslr thermal.off=1 nmi_watchdog=0 pcie_aspm=off consoleblank=0 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 vconsole.font=latarcyrheb-sun16 vconsole.keymap=de-latin1-nodeadkeys locale.LANG=C.UTF-8" GRUB_DISABLE_RECOVERY=true GRUB_DISABLE_SUBMENU=true GRUB_DISABLE_OS_PROBER=true GRUB_ENABLE_BLSCFG=true -- [root@rawhide ~]# system-errors.sh [Sat Jun 27 20:45:52 2020] systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE [Sat Jun 27 20:45:52 2020] systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'. [Sat Jun 27 20:45:52 2020] systemd[1]: Failed to start Setup Virtual Console. [Sat Jun 27 20:45:52 2020] systemd[1]: Dependency failed for dracut ask for additional cmdline parameters. [Sat Jun 27 20:45:52 2020] systemd[1]: dracut-cmdline-ask.service: Job dracut-cmdline-ask.service/start failed with result 'dependency'. Jun 27 20:45:54 rawhide systemd[1]: systemd-vconsole-setup.service: Main process exited, code=exited, status=1/FAILURE Jun 27 20:45:54 rawhide systemd[1]: systemd-vconsole-setup.service: Failed with result 'exit-code'. Jun 27 20:45:54 rawhide systemd[1]: Failed to start Setup Virtual Console. Jun 27 20:45:54 rawhide systemd[1]: Dependency failed for dracut ask for additional cmdline parameters. Jun 27 20:45:54 rawhide systemd[1]: dracut-cmdline-ask.service: Job dracut-cmdline-ask.service/start failed with result 'dependency'. Jun 27 20:45:54 rawhide systemd-vconsole-setup[209]: /usr/bin/loadkeys failed with exit status 1. Jun 27 20:45:54 rawhide systemd-vconsole-setup[269]: /usr/bin/loadkeys failed with exit status 1. Jun 27 20:45:54 rawhide systemd-udevd[261]: vtcon0: Process '/usr/lib/systemd/systemd-vconsole-setup' failed with exit code 1. -- ___ 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] Accpetance of Environment Variables in Attributes
Thanks again for your in depth reply. > it's a very different kind of language, as these specifiers are > defined by systemd itself Maybe someday someone will find a safe way to inject addtionally, arbitrary values into systemd. There are still some free letters left that can be prefixed with a % :) Until then I'll stick with dedicated unit files. Ede Am 26.06.20 um 15:27 schrieb Lennart Poettering: On Do, 25.06.20 20:25, Ede Wolf (lis...@nebelschwaden.de) wrote: Does work, so %i works, $SOMETHING not. Different naming, different way of invocation, I am aware of that, but in general it still the usage of variables. And the likes of %H, %m or %v are some form of environment, aren't they? Sure, you could claim this was a very specific form of templating. But it's a very different kind of language, as these specifiers are defined by systemd itself and are not affected by the contents of the unit file itself. I.e. you cannot go and say within a unit file that %m shall now resolve to "foo", and that %v shall now be "xyz". Instead, these expansions are defined by the unit file language itself, not by the unit file stanzas you place them in. That difference is quite major: the value of each specifier expansion is already well-defined and fixed at the moment we begin parsing the unit file (and its drop-ins) and their meaning does not change based on anything you could put in the file. Scripting languages that know env vars or generic templating languages are quite different there: you come up with variables, you assign them at the top and then you can resolve them further down. This implies a top-down, iterative order of execution. And we don't want that. Use m4 for that or shell. It's what they do, what they are good in. It's the distinction between declarative languages and iterative languages. We provide shortcuts to some concepts, but that's really it, otherwise we are declarative and never iterative. If you want a shell, use a shell. Given the dominance of systemd, this is only in parts realistic. This is not meant to critisize systemd itself, just this rather bold statement. As shown above, variables (specifiers, whatever you call them) are not shell specific. They are not shell specific. You could also use m4 if you want a templating language, there's no shame in that. But systemd is certainly not in the business of inventing yet another shell or generic templating language. 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
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
