Systemd made me stop using Centos 7. https://jira.mariadb.org/browse/MDEV-10925?page=com.atlassian.jira.plugin... 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? On Fri, Sep 30, 2016 at 9:05 AM, Glenn Holmer <cenbe(a)kolabnow.com&gt; wrote:

The issue is systemd+mariadb. Anything higher than Fedora 22 may have the same issue. On Fri, Sep 30, 2016 at 10:42 AM, Chris Murphy <lists(a)colorremedies.com&gt; wrote:

Tom Horsley writes: 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. 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.

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

On 09/30/2016 11:37 AM, Tom Horsley wrote: The time to start worrying is when you learn that your text editors are dependent on systemd.

Justin Moore writes: I have no doubt that there are people who find systemd useful for one reason or another, and they are so thrilled with joy is that they will choose to willingly defend its merits in public. But I can't name one off the top of my head. The systemd advocates that I've read – in my experience they were either directly, or closely, involved with the project. The converse is true, for the other side. Of all the spilled ink that I read, I can't give one name of anyone who's involved, in any way, with anything that might be considered as competing with systemd's mind share, in any way, shape, or matter. I see people from all walks of life, find something or other that's fundamentally wrong with it. Either its fundamental technical flaws, or the fact that it takes ten bleeping seconds to figure out if one service is running, or not. The only thing they ever have in common is that if they raise it through the official channels, the response they usually get is not exactly professional. For example, let's take your specific case here. I note that the follow-up response to the article I cited made some kind of tenuous comparison with the Linux kernel, in some form or fashion, that I found quite hard to follow. I can't help but recall that the Linux kernel maintains blacklists of devices, by their USB or ATAPI id, of some sort, when those specific devices fail to implement some key aspect of the relevant hardware protocol. The blacklisted devices are fully supported, except for some obscure featureset for which there's a fallback alternate implementation, which is used. I even recall one newsworthy incident several years ago. Chipmaker FTDI makes USB bridge chips, and a Windows driver for them. Naturally, a bunch of cheap knockoffs of the hardware flooded the market. Since Windows already had a driver in the base OS, it was plug and play with the clones. Then, FTDI released a driver update that bricked the cheap clones, by intentionally wiping the bridge chips' NVRAM, and setting their USB manufacturer id to 0000. Anyway, some time later the Linux kernel was patched to recognize the phony manufacturer id, and fully support it. The incident you described reminded me of that episode, for some reason. Anyway, back to your situation: the responsible, and user friendly, thing to do here would also be to maintain a known blacklist of virtual network interfaces that are not true network interfaces, and ignore them. Just like the Linux kernel would do in a comparable situation. I'm sure that this is eminently possible. That's what I would do. Then, the main functionality of systemd will work as intended. This is the proper way to go, instead of the stock "too bad, so sad, your system is going to be bleeked up because we are smarter, and we know better" response. I have complete faith that this is going to correct itself, over time. It won't happen soon, but these things typically work themselves out in long term. Currently, systemd has mindshare in most Linux distros. But that can always change, and I think it will. And then, systemd will eventually join XFree86 on the ash heap of history; and it will be interesting to see if systemd will take Red Hat down with it. Red Hat has bet its farm on systemd; and it remains to be seen how far they will ride the bomb (Google it).

Glenn Holmer writes: That response appears to be written by a systemd developer, so it's not exactly surprising. And the writer immediately goes into a contradiction: # Things that interact regularly with PID 1 over a bus or socket but are # isolated by process and privileges. This includes a handful things, like # logind and the journal. Which he had to begrudgingly admits later, is not exactly true: # This is a reasonable request, and I’ve been pushing for more modularity # around parsing for a while. Except that he fails again. This is not about parsing. He then goes and builds a big house of cards, focusing on parsing, etc… The problem with a simple command crashing PID 1 is that it's just a parsing problem. Year, right. This type of an intentional blind spot is quite typical, inside the systemd reality distortion field. Besides, throwing a well-deserved temper tantrum is not such a bad thing.

On 09/30/2016 01:47 PM, Rex Dieter wrote: Rex, the last time everybody agreed on things was in the late 1930's in Germany, and that really didn't turn out all that well now, did it? We need some place to vent our frustrations since no one seems to listen to those of us who actually USE the system and try to get some real work done rather than treating it as an experiment. After all, eventually Fedora becomes RHEL (and CentOS), so this isn't trivial stuff! It affects what will we will be using for years. In my opinion and speaking as a system administrator and programmer with over 45 years of experience (as well as having served on four highly contentious ANSI committees), systemd is overly complicated, burdensome and just plain broken in many areas. It never should have been adopted in its current state. It isn't "baked" enough. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - A day for firm decisions!!! Well, then again, maybe not! - ----------------------------------------------------------------------

Allegedly, on or about 01 October 2016, Ed Greshko sent: Dunno. The willful blindness to its problems, and lack of concern about it's shortcomings, and blaming everyone else but themselves, seemed direct and to the point, not some ill thought out insult. Seriously, when your software is the root cause of all manner of problems, *IT* is the problem. -- [tim@localhost ~]$ uname -rsvp Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 Boilerplate: All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I only get to see the messages posted to the mailing list. Damn, I didn't mean to press *that* button!