Matthew Miller wrote:

On Wed, Jun 07, 2017 at 10:10:14AM -0400, m.roth@5-cent.us wrote:

...

I just updated a system - as in minutes ago, and log back in after it reboots, and this is in dmesg: [ 88.202272] systemd-readahead[484]: open(/var/tmp/dracut.fP4yj1/initramfs/usr/bin/loginctl) failed: Too many levels of symbolic links [ 88.202515] systemd-readahead[484]: open(/var/tmp/dracut.fP4yj1/initramfs/usr/lib/systemd/system/dracut-emergency.service) failed: Too many levels of symbolic links Anyone know what this is - some weird bug, a garbage message?

systemd-readahead is just trying to pre-cache stuff into memory so boot time is faster. I'm not sure eaxctly what's going on here but that message is typical of having a loop in your symbolic links (which can easily happen with relative links).

I'm not quite sure what *exactly* is going on, but it looks like maybe dracut temp files didn't get cleaned up properly and that they contain such a loop. I bet you can just rm -rf /var/tmp/dracut.fP4yj1.

Thanks for the info. Now, why it shouldn't have cleaned itself up when I gave it the reboot command... I see too many (that's defined as more than zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for things to finish - sush as not getting the hostname from dhcp, and so having to hardcode the name instead.

Systemd, as I've said before, seems to be targeted towards laptops. Not servers. Not workstations. *bleah*

mark

On 06/07/2017 11:24 AM, James Hogarth wrote:

Mark stop with the flame baiting please.

This is nothing systemd specific - and keep in mind /var/tmp is a persistent temp area unlike /tmp which as it's tmpfs by default is of course emptie don boot.

I would wholeheartedly disagree. This IS something systemd specific. I have never seen init.d blow itself up over bloody symlinks. The readahead, while /possibly/ nice isn't at all necessary on modern hardware. I want my hardware to boot consistently, not bomb like an Adam Sandler movie because of /symlinks/.

But hey, call it flamebait if you want. I'd be willing to bet a year's salary most admins hate systemd with a passion.

On Wed, Jun 07, 2017 at 11:31:06AM -0400, Mark Haney wrote:

I would wholeheartedly disagree. This IS something systemd specific. I have never seen init.d blow itself up over bloody symlinks. The readahead, while /possibly/ nice isn't at all necessary on modern hardware. I want my hardware to boot consistently, not bomb like an Adam Sandler movie because of /symlinks/.

Now this is just silly. It didn't "blow itself up". Nothing blew up at all. There are just messages logged. There is no actual problem.

On Wed, June 7, 2017 10:43 am, Warren Young wrote:

On Jun 7, 2017, at 9:31 AM, Mark Haney mark.haney@neonova.net wrote:

...

On 06/07/2017 11:24 AM, James Hogarth wrote:

...

Mark stop with the flame baiting please.

This is nothing systemd specific - and keep in mind /var/tmp is a persistent temp area unlike /tmp which as it's tmpfs by default is of course emptie don boot.

I would wholeheartedly disagree. This IS something systemd specific.

I’m sure James Hogarth meant that circular symlink chains are a problem for any program, not just for systemd.

Now if you can show that systemd *generated* this chain, you might have a point.

Since we have only one report of this, it seems unlikely that systemd is doing this. Surely we’d have thousands of reports of this is something systemd always did.

...

I have never seen init.d blow itself up over bloody symlinks.

Only the systemd-readahead process failed. It’s an optional component. systemd is clearly not “blown up” on Mark’s system, else he couldn’t have gotten to a login prompt.

This optional component diagnosed an actual problem, that’s all.

...

The readahead, while /possibly/ nice isn't at all necessary on modern hardware.

Explain then why a VM containing a given OS generally boots faster the second time on a given host than rebooting the same OS on the bare hardware running that VM host.

RAM caches matter more today than they ever did, due to the vast disparity between storage access speeds in a modern system. Precharging the caches is still a good idea in 2017.

...

I want my hardware to boot consistently, not bomb like an Adam Sandler movie because of /symlinks/.

Hyperbolic much?

...

I'd be willing to bet a year's salary most admins hate systemd with a passion.

I think you’re basing that bet on data generated by an angry noisy minority.

With all my respect to Warren, I still decided to mention: noisy minority are the only ones everyone hears. There is big bunch of people who stopped saying anything as when one does, he gets in the middle of heated argument, gets shushed upon... And both sides of argument do realize that arguing will not change anything. Especially NOT on CentOS list. I am just mentioning that obviously visible minority has a bunch of invisible folks agreeing with them who decided to stop commenting on this, and some who fled elsewhere (and definitely didn't change their minds). Sigh.

Let's close this theme, and go back to administering systems we love (whichever OS that would mean for you).

Valeri

++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

Mark Haney wrote:

...

Thanks for the info. Now, why it shouldn't have cleaned itself up when I gave it the reboot command... I see too many (that's defined as more than zero) cases where systemd WANTS TO BOOT FAST, and doesn't wait for things to finish - sush as not getting the hostname from dhcp, and so

having to

...

hardcode the name instead.

Systemd, as I've said before, seems to be targeted towards laptops. Not servers. Not workstations. *bleah*

I'm still thinking it's a jacked up filesystem. I'm not sure what fs you're using, though the default is xfs, but I'd look at dmesg and boot.log to see if the kernel is finding issues with the drives or just the fs. It's also possible that server had been up a long time and RAM was funky. I've seen both of these happen before.

Not sure what you mean when you say "jacked up filesystem". Here's fstab:

UUID=b32212c1-bb97-4a99-8200-aa8152da528d / xfs defaults 0 0 UUID=d6648305-f049-4d7d-9999-670979da3cbe /boot xfs defaults 0 0 UUID=1bc3baaf-4b52-4309-9564-f80f2c098643 swap swap defaults 0 0 LABEL=export1 /export/1 ext4 defaults 0 0

mark

Kenneth Porter wrote:

On 6/7/2017 8:31 AM, m.roth@5-cent.us wrote:

...

Not sure what you mean when you say "jacked up filesystem". Here's fstab:

In systemd fstab takes care of only rudimentary mounting. Most mounting is done through *.mount unit files. Type "mount" and you'll see a bunch of other mounts that were implemented that way. Add your custom mounts by creating suitable files in /etc/systemd/system/*mount. (There's also *.automount for creating demand-based mounts.)

You. Have. To. Be. Joking. WHY? Why doesn't systemd *look* at fstab and create what it needs on the fly? Why does it only "rudimentary mount"? What purpose does that serve? What goal is it trying to achieve by this?

mark

On Wed, 2017-06-07 at 12:47 -0400, m.roth@5-cent.us wrote:

Kenneth Porter wrote:

...

On 6/7/2017 8:31 AM, m.roth@5-cent.us wrote:

...

Not sure what you mean when you say "jacked up filesystem". Here's fstab:

In systemd fstab takes care of only rudimentary mounting. Most mounting is done through *.mount unit files. Type "mount" and you'll see a bunch of other mounts that were implemented that way. Add your custom mounts by creating suitable files in /etc/systemd/system/*mount. (There's also *.automount for creating demand-based mounts.)

You. Have. To. Be. Joking. WHY? Why doesn't systemd *look* at fstab and create what it needs on the fly? Why does it only "rudimentary mount"?

Calm down Mark. You are overreacting. Systemd does generate mount units in the fly. Check the documentation: man systemd.mount tells you more. I would not call fstab rudimentary. /Louis

Kenneth Porter wrote:

On 6/7/2017 10:09 AM, Louis Lagendijk wrote:

...

I would not call fstab rudimentary.

Perhaps I phrased that poorly. The idea is that fstab provides a minimal set of mounts to get off the ground. (My understanding, not saying that's how it's designed or intended.)

This follows the packaging pattern that every unique setting goes in its own file. You don't disturb or risk breaking other settings when you add a new setting, and you can separately package these settings without meddling with central files.

Ok, sorta. Thanks for expanding, all.

mark "none o' youse guys had to spend something like six hours Monday and Tuesday swapping 42 drives in a RAID from 2TB to 4TB, 6 unscrews, 4 screws....zzzzzzzz"

On Wed, 2017-06-07 at 11:23 -0500, Johnny Hughes wrote:

If you want to create a CentOS-7 variant that does not use systemd, then start a Special Interest Group and create modified packages to use something else instead ......., much like the this group did with Debian:

https://devuan.org/

In the case of CentOS-7 .. you don't need to create a whole new distro, you can just petition the CentOS Project Board to create a Special Interest Group to get access to CentOS Project controlled resources to build packages (and get them rolled into our mirrors, etc.) to use something other than systemd.

Excellent idea. I'll gladly sign any such petition :-)

On 06/07/2017 02:02 PM, John R Pierce wrote:

On 6/7/2017 11:28 AM, Always Learning wrote:

...

...

In the case of CentOS-7 .. you don't need to create a whole new distro, you can just petition the CentOS Project Board to create a Special Interest Group to get access to CentOS Project controlled resources to build packages (and get them rolled into our mirrors, etc.) to use something other than systemd.

Excellent idea. I'll gladly sign any such petition:-)

but will you contribute to building the non-systemd packages, and working out how to retrofit old sysV init back into everything via patches, etc ? every RPM that interacts with systemd will need to be 'fixed' to do it the old way, with init.d scripts. repositories like postgres, EPEL, etc won't work, either, as their C7 packaged daemons are all configured to use systemd.

Exactly what John said.

What I meant by petitioning the board is for a group of people who are willing to actually contribute the time/effort required to make/modify software that would use something other than systemd.

If such a group exists, and if that group wanted a way to get such software into CentOS, they could petition (ask) for the starting of a SIG.

If there are not people willing to invest that effort, then we get what we get from the released source code.

We don't need people to tell us they don't like it .. just like we don't need people to tell us the want they want the upgrade tool to work. We need people who will actually DO SOMETHING to volunteer to do said something in order for these (or any other things) to actually happen.

On 6/7/2017 12:53 PM, Bruce Ferrell wrote:

On 6/7/17 12:42 PM, Johnny Hughes wrote:

...

On 06/07/2017 02:02 PM, John R Pierce wrote:

...

On 6/7/2017 11:28 AM, Always Learning wrote:

...

...

In the case of CentOS-7 .. you don't need to create a whole new distro, you can just petition the CentOS Project Board to create a Special Interest Group to get access to CentOS Project controlled resources to build packages (and get them rolled into our mirrors, etc.) to use something other than systemd.

Excellent idea. I'll gladly sign any such petition:-)

but will you contribute to building the non-systemd packages, and working out how to retrofit old sysV init back into everything via patches, etc ? every RPM that interacts with systemd will need to be 'fixed' to do it the old way, with init.d scripts. repositories like postgres, EPEL, etc won't work, either, as their C7 packaged daemons are all configured to use systemd.

Exactly what John said.

What I meant by petitioning the board is for a group of people who are willing to actually contribute the time/effort required to make/modify software that would use something other than systemd.

If such a group exists, and if that group wanted a way to get such software into CentOS, they could petition (ask) for the starting of a SIG.

If there are not people willing to invest that effort, then we get what we get from the released source code.

We don't need people to tell us they don't like it .. just like we don't need people to tell us the want they want the upgrade tool to work. We need people who will actually DO SOMETHING to volunteer to do said something in order for these (or any other things) to actually happen.

Actually, a LOT of that work exists in Scientific Linux. The power of OSS is that odds are our problems aren't new and have already been solved by someone and we share those solutions.

Previous to systemd, the packages didn't have systemd integrated, so should be good models.

I, for one, volunteer.

Honestly, systemd-as-a-service-launcher isn't the core issue many have, it's systemd-as-init-subsystem. systemd could remain in a fashion similar to xinetd, or a daemontools RPM I've been using for the past 10 years or so: launched via script in standard, deterministic SysV style, and starting up child processes as configured (but NOT being responsible for things already taken care of, like autofs mounting, etc). In this case, many of those RPMs could hopefully work fine right out of the box.

Rather than a call to "replace systemd", it might better to look at it as taking CentOS 7 and putting the bulk of EL6's initscripts RPM and startup package back into it, and adjusting as needed forward. Doing things like replacing previously-existing SysV Init scripts in packages can be helpful down the line, but that could plausibly be considered a "reach goal"... (No idea how easily desktop integration would be separatable -- getting hooks into every aspect of GNOME/login was certain one way the creators tried to make it a fait accompli.)

I, for one, would volunteer for this project as well.

A benefit of being downstream from a stable distribution is that once it's up and working, the mechanics of *keeping* it up and working with package updates are easier. Minority or not, there's a vocal group of EL users that are looking for a RedHat-ecosystem server distro that's not running systemd-as-init. CentOS 7 can be used as a core and leverage the parallel work that Scientific Linux has done with ease.

The drawback of being a stable distro (let alone downstream of one) is that unlike on the other side where Debian begets the rapidly-advancing Ubuntu, here *Fedora* is at the top. The C in CentOS means "community supported", not "Community Designed Enterprise OS", and as interesting as it would be to try to invert the ecosystem, that's not the goal. There's a need for CentOS as-is. (Arguably any lessons learned from creating a systemd-less CentOS-7 (even if usership is low), could end up having the most utility in easing the creation of a fork of Fedora down the road. Now *that* would be interesting.)

To enact *real* change, Enterprise Linux users of all stripes need to make their voices heard in Fedora-land, not just trust that the fedora-devel list will eventually DTRT ... While at the same time, paying RHEL customers need to talk to their reps.

An alternative CentOS-SIG focused on the initsystem would be the place to discuss these matters further -- venting on the CentOS list itself isn't helpful.

Just some thoughts.

-jc

On Wed, June 7, 2017 2:02 pm, John R Pierce wrote:

On 6/7/2017 11:28 AM, Always Learning wrote:

...

...

In the case of CentOS-7 .. you don't need to create a whole new distro, you can just petition the CentOS Project Board to create a Special Interest Group to get access to CentOS Project controlled resources to build packages (and get them rolled into our mirrors, etc.) to use something other than systemd.

Excellent idea. I'll gladly sign any such petition:-)

but will you contribute to building the non-systemd packages, and working out how to retrofit old sysV init back into everything via patches, etc ? every RPM that interacts with systemd will need to be 'fixed' to do it the old way, with init.d scripts. repositories like postgres, EPEL, etc won't work, either, as their C7 packaged daemons are all configured to use systemd.

I agree, John.

We respect CentOS for what it is (blatantly said, being RHEL binary replica, I know it is more...). Debian/devuan is a core system developers team split. You want similar core system developers split here - the place is RedHat, not CentOS and this definitely will not happen (note the difference between debian.org and redhat.com).

So, the only productive thing about systemd on CentOS list will be to drop all battles, accept systemd as our reality, and keep all posts restricted to pure technical questions/answers.

Just my $0.02

Valeri

++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++

On Jun 7, 2017, at 2:24 PM, Always Learning centos@u68.u22.net wrote:

What is the advantage of patches over a virgin version that can be subsequently patched ?

Doing the change as a patch to the upstream RPM means that, most of the time, you can just apply your patch again whenever the upstream RPM changes. If the patch applies cleanly, chances are that your port update is done, right there.

If you fork the package base entirely, you have to backport each change from upstream yourself, which is a much bigger burden. Chances are good that you’ll end up forking the whole OS that way, rather than creating a variant spin of it.

The fork-the-whole-thing model would make sense if you’re starting from C6, since it’s on the downhill side of the patch rate curve now, so that there will be little backporting necessary. And soon, a maintainer of a C6 fork would be on his own anyway, when the upstream patches dry up.

Whereas if you start with C7, you’d like to have the benefit of the upstream changes while you do the smallest amount of work you can while achieving your end of ridding C7 of systemd. The project is likely to take years to complete — after all, it took many years for systemd to get to where it is now — so there’s a good chance you could complete the project before you’re left with an EOL’d C7 base package set.

If you look inside many RPMs, they are composed of the untouched upstream source tarball plus a series of patches. One RPM I looked into recently had something like 30 separate patches applied to it, some from Fedora, some from Red Hat, Inc, and potentially (though not in this specific case) some from the CentOS project. This is the normal way of doing these things.

On 06/07/2017 01:27 PM, Warren Young wrote:

On Jun 7, 2017, at 1:02 PM, John R Pierce pierce@hogranch.com wrote:

...

every RPM that interacts with systemd will need to be 'fixed' to do it the old way, with init.d scripts. repositories like postgres, EPEL, etc won't work, either, as their C7 packaged daemons are all configured to use systemd.

That’s just skimming the surface.

The real hard bits come from the way systemd hooks into the whole FreeDesktop infrastructure and vice versa. (e.g. dbus is now inextricably part of systemd, and many FreeDesktop interactions happen via dbus.) This is why the BSDs are either dropping GNOME and KDE (e.g. Lumina in TrueOS) or have badly lagging ports compared to the upstream version.

I suspect it’s probably easier to start with C6, then backport as much as is possible without dragging in any systemd stuff, the same way the BSDs are doing.

Good luck to y’all. Sincerely. I plan to keep on using C7, warts and all. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

As I mentioned previously. Scientific Linux (another RHEL clone) HAS solved those issues. Centos isn't running the latest KDE/Plasma5 junk.

On 6/8/17 1:15 AM, Veli-Pekka Kestilä wrote:

On 7.6.2017 23:40, Bruce Ferrell wrote:

...

On 06/07/2017 01:27 PM, Warren Young wrote:

...

On Jun 7, 2017, at 1:02 PM, John R Pierce pierce@hogranch.com wrote:

...

every RPM that interacts with systemd will need to be 'fixed' to do it the old way, with init.d scripts. repositories like postgres, EPEL, etc won't work, either, as their C7 packaged daemons are all configured to use systemd.

That’s just skimming the surface.

The real hard bits come from the way systemd hooks into the whole FreeDesktop infrastructure and vice versa. (e.g. dbus is now inextricably part of systemd, and many FreeDesktop interactions happen via dbus.) This is why the BSDs are either dropping GNOME and KDE (e.g. Lumina in TrueOS) or have badly lagging ports compared to the upstream version.

I suspect it’s probably easier to start with C6, then backport as much as is possible without dragging in any systemd stuff, the same way the BSDs are doing.

Good luck to y’all. Sincerely. I plan to keep on using C7, warts and all.

As I mentioned previously. Scientific Linux (another RHEL clone) HAS solved those issues. Centos isn't running the latest KDE/Plasma5 junk.

How they have solved it? According SL7 release notes in: http://ftp.scientificlinux.org/linux/scientific/7.0/x86_64/release-notes/

They say following: "Following upstream SL7 uses systemd as its init system. The System’s Administrators Guide published by upstream provides a helpful introduction to systemd commands."

-vpk

Yes, 7 does track upstream. upstream 6 uses systemd also and Scientific Linux 6 does not. I would say that indicates a solution.

On 06/08/2017 04:59 AM, John Hodrien wrote:

On Thu, 8 Jun 2017, Bruce Ferrell wrote:

...

Yes, 7 does track upstream. upstream 6 uses systemd also and Scientific Linux 6 does not. I would say that indicates a solution.

Upstream 6 uses systemd?

jh _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

yes, 6.6 and above

On Thu, Jun 08, 2017 at 05:02:38AM -0700, Bruce Ferrell wrote:

...

On Thu, 8 Jun 2017, Bruce Ferrell wrote:

...

Yes, 7 does track upstream. upstream 6 uses systemd also and Scientific Linux 6 does not. I would say that indicates a solution.

Upstream 6 uses systemd?

jh

yes, 6.6 and above

RHEL6 has used Upstart since RHEL 6.0, and continues to use it in RHEL 6.9. I have no idea where you'd get this kind of information.

I think we had enough of Systemd flaming last month. Please stop polluting my inbox and find an operating system compatible with your worldview. It is really tiresome to keep on hearing about it.

On 8 June 2017 at 14:51, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:

On Thu, 8 Jun 2017, Jonathan Billings wrote:

Upstream 6 uses systemd?

...

...

...

jh

yes, 6.6 and above

RHEL6 has used Upstart since RHEL 6.0, and continues to use it in RHEL 6.9. I have no idea where you'd get this kind of information.

If you really thought Redhat would switch from upstart of systemd, within a major release, I have no idea why you'd want to use anything based on Redhat.

jh

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On Thu, Jun 08, 2017 at 09:15:23AM -0400, Mark Haney wrote:

Huh. Okay, though I'm not sure when you became arbiter of this list. If you don't like 'our worldview' discussions, maybe you need to find a different OS that suits your childish attitude. Like Windows 95.

Mailing lists now are so full of children it's hard to even use them. Maybe you should leave IT if heated discussions make you uncomfortable.

I certainly would not suggest anyone leave this list or stop using CentOS.

While I don't think we need to be yelling at each other, I do sympathize with anyone frustrated by the continued ignorance of some of the more vocal proponents of the systemd-haters crowd. The CentOS list continues to be a good resource, even if it's learning about systemd. Sometimes the complaints about systemd can be turned into a learning experience (such as how fstab works). I think that if we can attempt to frame questions about systemd in a more positive way, everyone would get more out of it.

I was sorely tempted to post saying I would initiate an empty email to the list in a week with subject systemd and see what the response would be - I'll refrain...

----- Original Message ----- From: "m roth" m.roth@5-cent.us To: "centos" centos@centos.org Sent: Thursday, June 8, 2017 9:32:57 AM Subject: Re: [CentOS] C7, systemd, say what?!

Mark Haney wrote:

On 06/08/2017 09:12 AM, Andrew Holway wrote:

...

I think we had enough of Systemd flaming last month. Please stop polluting my inbox and find an operating system compatible with your worldview. It is really tiresome to keep on hearing about it.

Huh. Okay, though I'm not sure when you became arbiter of this list. If you don't like 'our worldview' discussions, maybe you need to find a different OS that suits your childish attitude. Like Windows 95.

Mailing lists now are so full of children it's hard to even use them. Maybe you should leave IT if heated discussions make you uncomfortable.

Folks, I'm the one who made the original annoyed throwaway remark. I've even asked that we end the incipient flamewar. Look, as much as I dislike systemd, going on and on and on just ain't of interest. Hell, I'll probably skim and delete, or just delete.

Now, the information that someone posted about what might be happening to cause my original question was helpful, and in *that* context, in the same email, cmts about systemd, sure. But I dunno 'bout most of you, but a flamewar that runs for *weeks*, as we've seen here, is of no interest.

Maybe we need another mailing list, like alt.religion.editors*, we could have alt.religion.systemd.... <g>

mark

* vi, not emacs! Nyahhhh....

_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

On Jun 9, 2017, at 10:08 AM, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:

On Thu, 8 Jun 2017, m.roth@5-cent.us wrote:

...

Maybe we need another mailing list, like alt.religion.editors*, we could have alt.religion.systemd.... <g>

mark

• vi, not emacs! Nyahhhh....

You mean 6, right?

The developer of Sublime Text is hard at work on his third attempt at a Vi emulating plugin, apparently having run into walls with the prior two attempts. He is calling his latest attempt…Six. :)

http://www.sublimesix.com/