Sam Varshavchik writes:
a well-defined point when the system boots, then, I guess we can reach the conclusion that NetworkManager is totally incapable of accomplishing basic networking administration tasks, and move on to consider ugly hacks like https://github.com/svarshavchik/unfrak-systemd-network to be the only way to
And to close the loop on this dumpster fire, the evidence is in: NetworkManager-wait-online does not really wait until anything is online. Got solid proof, right here. I just installed and tested the unfrak-systemd- network script on that server of mine where things often don't get started properly. This script quickly tries to bind to the server's known IP addresses, logs the results, and tries every second until it succeeds, then E-mails me the report.
Well, on this particular boot, which succeeded, NetworkManagerWaitOnline.service alleged "Started" on 08:35:33:
Dec 18 08:35:27 shorty.email-scan.com systemd[1]: Starting Network Manager Wait
Dec 18 08:35:33 shorty.email-scan.com systemd[1]: Started Network Manager Wait O
unfrak-systemd-network ran a second later:
Dec 18 08:35:33 shorty.email-scan.com systemd[1]: Starting Unfrak systemd networ
Dec 18 08:35:35 shorty.email-scan.com systemd[1]: Started Unfrak systemd network
And the emailed report from the script landed in my mailbox:
Subject: systemd network initialization unfrak report
Message-ID: <courier.000000005a37c427.00000...@www.courier-mta.com>
Date: Mon, 18 Dec 2017 08:35:35 -0500
--------------------------------------------------------------------------------
Time IP addresses
======== ==================
08:35:34
08:35:35 192.168.0.1
At 08:35:34 the server had no IP addresses, a full second until
NetworkManager assured the rest of the system that it's "online". Finally,
192.168.0.1 came up a second later.
This service is keyed to run after NetworkManager-wait-line: [Unit] Description=Unfrak systemd network startup After=NetworkManager-wait-online.service systemd-networkd-wait-online.service Before=network-online.targetNow that unfrak-systemd-network injects itself into the dependency chain, and delays it, looks like all the problematic services get delayed until the IP addresses are really there:
Dec 18 08:35:35 shorty.email-scan.com systemd[1]: Starting Privoxy Web Proxy Wit Dec 18 08:35:36 shorty.email-scan.com systemd[1]: Started Privoxy Web Proxy With Dec 18 08:35:35 shorty.email-scan.com systemd[1]: Starting Courier SOCKS 5 proxy Dec 18 08:35:35 shorty.email-scan.com systemd[1]: Started Courier SOCKS 5 proxy.It's a sad, sad state of affairs when one needs to resort to these kinds of hacks just to get a server booted correctly.
pgpi4ZKt9X8QJ.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
