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.
You need network-online.target
. See this link for detailed explanation:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
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.
Do you have NetworkManager-wait-online.service
enabled and running?
[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…
Yeah, I’m not really sure how to troubleshoot this…
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
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?
Solved!
Steps:
-
Enable
chrony-wait.service
-
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!
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.