Latest/Network **fully** online SystemD Target (Fedora IoT)?

What is the latest systemd target? My rpi’s network seems to start up after multi-user.target, so I’m not sure where to start my podman containers that require the network. For now, I just have it on a one-minute delay with the OnBootSec= timer, but I’d like a slightly less hacky solution if possible.

1 Like

You need network-online.target. See this link for detailed explanation:

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

1 Like

Sorry. I made this post in a bit of a rush and should have made thing clearer. I have a few different service files, but I’ll just show the one for the Minecraft podman container since it is the simplest:

# container-mc.service
# autogenerated by Podman 3.1.2
# Wed May  5 10:02:13 EDT 2021

[Unit]
Description=Podman container-mc.service
Documentation=man:podman-generate-systemd(1)
Wants=network.target
After=network-online.target
RequiresMountsFor=/var/lib/containers/storage /run/containers/storage

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/bin/rm -f %t/container-mc.pid %t/container-mc.ctr-id
ExecStart=/usr/bin/podman run --conmon-pidfile %t/container-mc.pid --cidfile %t/container-mc.ctr-id --cgroups=no-conmon -d --replace --pull always -v /root/minecraft/data:/data:Z -e TYPE=CURSEFORGE -e CF_SERVER_MOD=AllofFabric3Server-2.7.2.zip -p 25565:25565 -e EULA=TRUE --name mc -e SERVER_NAME=aof3 -e DIFFICULTY=hard -e "MOTD=Andy's AOF3 Server!" -e PLAYER_IDLE_TIMEOUT=5 -e TZ=America/New_York -e USE_AIKAR_FLAGS=true -e MEMORY=6885M -e CF_BASE_DIR=/data -e OVERRIDE_SERVER_PROPERTIES=true -e VIEW_DISTANCE=6 docker.io/itzg/minecraft-server:multiarch
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/container-mc.ctr-id -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/container-mc.ctr-id
PIDFile=%t/container-mc.pid
Type=forking

[Install]
WantedBy=multi-user.target default.target

The thing is somehow network-online is not seeing my Ethernet. I usually don’t see the link-up message until after multi-user:

If Podman is executed before this is errors out or misconfigures the network.

1 Like

Do you have NetworkManager-wait-online.service enabled and running?

1 Like
[athurman@macaroni ~]$ sudo systemctl status NetworkManager-wait-online.service 
[sudo] password for athurman: 
○ NetworkManager-wait-online.service - Network Manager Wait Online
     Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait-online.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:nm-online(1)

This may be it…

1 Like

Yeah, I’m not really sure how to troubleshoot this…

1 Like

In my machine (regular Fedora, not IoT), its default timeout is 60 seconds. So it waits for network to be active but quit after 1 minute. I am not familiar with IoT but I think you should investigate why your network takes that much to get activated. systemctl cat NetworkManager-wait-online.service says:

# Set $NM_ONLINE_TIMEOUT variable for timeout in seconds.
# Edit with `systemctl edit NetworkManager-wait-online`.
#
# Note, this timeout should commonly not be reached. If your boot
# gets delayed too long, then the solution is usually not to decrease
# the timeout, but to fix your setup so that the connected state
# gets reached earlier.

This kind of brings us back to square one lol. The main problem is: I have no idea why it takes so long. Nothing here seems out of the ordinary:

[athurman@macaroni ~]$ journalctl -b -p4
-- Journal begins at Mon 2021-04-05 20:00:00 EDT, ends at Wed 2021-05-05 12:35:07 EDT. --
Apr 05 20:00:00 fedora kernel: sysfs: cannot create duplicate filename '/devices/platform/3e513000.framebuffer'
Apr 05 20:00:00 fedora kernel: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.17-300.fc34.aarch64 #1
Apr 05 20:00:00 fedora kernel: Hardware name:  /, BIOS 2021.04 04/28/2021
Apr 05 20:00:00 fedora kernel: Call trace:
Apr 05 20:00:00 fedora kernel:  dump_backtrace+0x0/0x1c0
Apr 05 20:00:00 fedora kernel:  show_stack+0x24/0x30
Apr 05 20:00:00 fedora kernel:  dump_stack+0xd0/0x128
Apr 05 20:00:00 fedora kernel:  sysfs_warn_dup+0x70/0x90
Apr 05 20:00:00 fedora kernel:  sysfs_create_dir_ns+0xc4/0xd4
Apr 05 20:00:00 fedora kernel:  create_dir+0x30/0x1f0
Apr 05 20:00:00 fedora kernel:  kobject_add_internal+0xd0/0x230
Apr 05 20:00:00 fedora kernel:  kobject_add+0x84/0xe0
Apr 05 20:00:00 fedora kernel:  device_add+0xf0/0x560
Apr 05 20:00:00 fedora kernel:  of_device_add+0x50/0x6c
Apr 05 20:00:00 fedora kernel:  of_platform_device_create_pdata+0xc8/0x11c
Apr 05 20:00:00 fedora kernel:  of_platform_device_create+0x24/0x30
Apr 05 20:00:00 fedora kernel:  simplefb_init+0x7c/0xa8
Apr 05 20:00:00 fedora kernel:  do_one_initcall+0x40/0x250
Apr 05 20:00:00 fedora kernel:  do_initcalls+0x104/0x144
Apr 05 20:00:00 fedora kernel:  kernel_init_freeable+0x1a4/0x1f0
Apr 05 20:00:00 fedora kernel:  kernel_init+0x20/0x134
Apr 05 20:00:00 fedora kernel:  ret_from_fork+0x10/0x18
Apr 05 20:00:00 fedora kernel: kobject_add_internal failed for 3e513000.framebuffer with -EEXIST, don't try to register things with the same name in the same directory.
Apr 05 20:00:00 fedora kernel: cacheinfo: Unable to detect cache hierarchy for CPU 0
Apr 05 20:00:02 fedora systemd-udevd[369]: /usr/lib/udev/rules.d/50-udev-default.rules:42 Unknown group 'sgx', ignoring
Apr 05 20:00:02 fedora systemd-udevd[369]: /usr/lib/udev/rules.d/50-udev-default.rules:42 Unknown group 'sgx', ignoring
Apr 05 20:00:03 fedora kernel: usb_phy_generic phy: supply vcc not found, using dummy regulator
Apr 05 20:00:03 fedora kernel: mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
Apr 05 20:00:03 fedora kernel: mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
Apr 05 20:00:03 fedora kernel: mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
Apr 05 20:00:03 fedora kernel: mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
Apr 05 20:00:03 fedora kernel: mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
Apr 05 20:00:04 fedora kernel: dwc2 fe980000.usb: supply vusb_d not found, using dummy regulator
Apr 05 20:00:04 fedora kernel: dwc2 fe980000.usb: supply vusb_a not found, using dummy regulator
Apr 05 20:00:06 fedora kernel: kauditd_printk_skb: 16 callbacks suppressed
Apr 05 20:00:15 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/dbus-parsec is not a valid unit name, ignoring.
Apr 05 20:00:15 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/greenboot-grub2-set-counter is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/greenboot-grub2-set-success is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/greenboot-healthcheck is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/greenboot-rpm-ostree-grub2-check-fallback is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/greenboot-status is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/greenboot-task-runner is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/parsec is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/redboot-auto-reboot is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni systemd[1]: multi-user.target: Wants dependency dropin /etc/systemd/system/multi-user.target.wants/redboot-task-runner is not a valid unit name, ignoring.
Apr 05 20:00:16 macaroni kernel: kauditd_printk_skb: 33 callbacks suppressed
Apr 05 20:00:19 macaroni systemd[1]: fstrim.timer: Not using persistent file timestamp Wed 2021-05-05 12:02:42 EDT as it is in the future.
Apr 05 20:00:27 macaroni NetworkManager[728]: <warn>  [1617667227.4998] sup-iface[c7857f66b4d67d77,0,wlan0]: call-p2p-cancel: failed with P2P cancel failed
Apr 05 20:00:36 macaroni chronyd[677]: System clock wrong by 2565099.135396 seconds
May 05 12:32:15 macaroni chronyd[677]: System clock was stepped by 2565099.135396 seconds
1 Like

Alright. I’ve done some more digging and testing, and it appears the network time keeps resting, cuasing the early boot internet issues:


I wonder if manually setting the time could help?

1 Like

Solved!

Steps:

  1. Enable chrony-wait.service

  2. I edited my SytemD Service:

# container-mc.service
# autogenerated by Podman 3.1.2
# Wed May  5 10:02:13 EDT 2021

[Unit]
Description=Podman container-mc.service
Documentation=man:podman-generate-systemd(1)
Wants=time-sync.target
After=time-sync.target
RequiresMountsFor=/var/lib/containers/storage /run/containers/storage

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStartPre=/bin/rm -f %t/container-mc.pid %t/container-mc.ctr-id
ExecStart=/usr/bin/podman run --conmon-pidfile %t/container-mc.pid --cidfile %t/container-mc.ctr-id --cgroups=no-conmon -d --replace --pull always -v /root/minecraft/data:/data:Z -e TYPE=CURSEFORGE -e CF_SERVER_MOD=AllofFabric3Server-2.7.2.zip -p 25565:25565 -e EULA=TRUE --name mc -e SERVER_NAME=aof3 -e DIFFICULTY=hard -e "MOTD=Andy's AOF3 Server!" -e PLAYER_IDLE_TIMEOUT=5 -e TZ=America/New_York -e USE_AIKAR_FLAGS=true -e MEMORY=6885M -e CF_BASE_DIR=/data -e OVERRIDE_SERVER_PROPERTIES=true -e VIEW_DISTANCE=6 docker.io/itzg/minecraft-server:multiarch
ExecStop=/usr/bin/podman stop --ignore --cidfile %t/container-mc.ctr-id -t 10
ExecStopPost=/usr/bin/podman rm --ignore -f --cidfile %t/container-mc.ctr-id
PIDFile=%t/container-mc.pid
Type=forking

[Install]
WantedBy=multi-user.target default.target

And now it seems to work flawlessly!

1 Like

I wonder if it would make sense to have chrony-wait.service enabled by default on IoT since many devices do not have a traditional “Hardware Clock”…

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.