Tom Horsley writes:
On Fri, 30 Sep 2016 10:29:51 -0400
Saint Michael wrote:
> In short, the most recent update to Centos7, makes Mariadb unable to start
> in both versions that use systemd.
> This affects millions of users. I had to replace my container for a Fedora
> 22 one, and lower ,my version of Mariadb.
> Does anybody of any work around?
I have vast numbers of things in my rc.local file to delay a
bit then restart services that never start correctly (mainly
because systemd has no idea when the network is in fact "up").
I find that the following wait-for-network.service is fairly bulletproof:
[Unit]
Description=Wait for network ports to be initialized
Before=network.target network-online.target
After=network.service
Wants=network.target
[Service]
Type=oneshot
ExecStart=/usr/bin/true
[Install]
WantedBy=multi-user.target
Then, enable this, and network-online.target.
I have this configured on my F23 machine running MythTV. This doesn't work since I have a Ceton InfiniTV cable capture card. The card's driver presents itself as a virtual network interface, and once that comes up, systemd is like, "whelp, I'm done here!" and proceeds to start everything else which requires a network connection. This means that anything which does a "bind to all network interfaces" between the time that the virtual network interface comes up (uSecs) and the DHCP response comes back with the actual external network interface address (mSecs) *doesn't actually bind to an external network interface*.
Several people have raised this on the MythTV lists and provided feedback to the systemd developers. Last I heard their response was "this isn't broken because we don't know that it's a virtual network interface and we can't wait for ALL the network interfaces to come up because .... reasons. Closed: Working As Intended."
The work-around was to buy a UPS for that machine because the #1 cause of reboots was flaky power in our neighborhood. No reboots ~> fewer chances for systemd to do the wrong thing.
Sadly I think the power company will fix the distribution infrastructure in our neighborhood before systemd gets this working correctly.
-jdm
Whatever the hell that is.
NetworkManager-wait-online.service is not enough. Whatever the hell that is, too.
Speaking of that:
# time systemctl status NetworkManager-wait-online.service
● NetworkManager-wait-online.service - Network Manager Wait Online
Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait-online.service; d
Active: active (exited) since Sat 2016-09-24 09:51:13 EDT; 6 days ago
Docs: man:nm-online(1)
Process: 1072 ExecStart=/usr/bin/nm-online -s -q --timeout=30 (code=exited, st
Main PID: 1072 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 512)
CGroup: /system.slice/NetworkManager-wait-online.service
Sep 24 09:51:04 octopus.email-scan.com systemd[1]: Starting Network Manager Wait
Sep 24 09:51:13 octopus.email-scan.com systemd[1]: Started Network Manager Wait
real 0m12.133s
user 0m0.016s
sys 0m0.063s
I'll give two seconds of credit for me hitting Enter (because, for some reason, systemctl apparently pipes its output to "less").
But the end result that it takes ten seconds for systemd to tell me the status of a single service.
That's state-of-the-art system management, for you.
For all the bombast about systemd being the future of system management, it is utter. complete. total. unquestionable. crap.
I have no axe to grind. I am not involved with either systemd, or any competing project, if there is one. I have no personal grudges with anyone involved with systemd. Aside from Poettering, I can't even give you even one other name who's involved with it.
I just call them as I see them.
And as much as it pains me to say this: $dayjob$ just rolled out Linux as a supported platform for employees' laptops, to complement Windows 7 and Macs. Their distribution image is the systemd-free Ubuntu 14, despite us being a CentOS shop. The reason is very simple: after I type in the password to unlocks the LUKS-encrypted partition, it takes about three seconds to get to the KDM prompt. After logging in, the KDE Plasma workbench is ready for user action in about three more seconds. I'm depressed.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@lists.fedoraproject.org
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
