> > 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@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > >
_______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
