My two cents on "the new Linux" -> RedHat EL7 / CentOS 7.

A 5 star hangout for overworked and underpaid system admins.
User avatar
TrevorH
Site Admin
Posts: 33202
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by TrevorH » 2014/07/23 18:06:56

Thread moved to CentOS Social forum since it has nothing at all to do with support.
The future appears to be RHEL or Debian. I think I'm going Debian.
Info for USB installs on http://wiki.centos.org/HowTos/InstallFromUSBkey
CentOS 5 and 6 are deadest, do not use them.
Use the FAQ Luke

_ck_
Posts: 89
Joined: 2012/08/10 23:00:35

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by _ck_ » 2014/07/23 19:07:49

People are comparing the wrong thing to systemd.

Systemd is exactly like the system services manager in WINDOWS, which is why it is the wrong direction, it even looks inspired by Windows.

Binary logs, programs that have to be run after changes, proprietary configuration files, even more services to do simple things like create directories with their OWN proprietary configuration. It is insanity. Or at least not linux-like.

Give me bash or bash-like scripts any day over that.

I don't get what the problem with init.d was, especially not with service and chkconfig making it easy. Service files were pretty straightforward.

Gee they shaved a few seconds off boot time, totally worth all that proprietary stuff.

jmrcpn
Posts: 5
Joined: 2014/07/18 19:06:00

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by jmrcpn » 2014/07/26 16:28:48

dwaltz wrote:
sblantipodi wrote: I absolutely prefer the initd style.
We all face the need to learn to sort out the dependencies of the modules to start up, but I don't think a procedural script is superior to declarative configuration.
jmrcpn wrote: Systemd is to initd , what Concorde is to B-747
I would say Systemd is to initd , what functional programming is to precedural, what sql is to manging your database by hand.
Sometimes we do have to worry about execution plans, but most of the time we don't know how a query works behinds the curtain: we just get the data by stating what we want not how we want it to come out of the datafiles.
Obviously, I was not good enough to carry my own meaning, the problem is not systemd adding a layer to init fonctionnalites. (as SQL Language adding consistency to data-base management).

"Systemd is to initd , what Concorde is to B-747" :
Concorde WAS a nice tech trip, challenge were fun to be resolved, but the real solution was B-747..., Concorde,
while a brand new concept and a giant leap forward, was not an effective solution. New is not always better!
The problem, systemd is trying to do far too many thing, it become a very critical path by itself.
As Dual-Hat, Developer and SysAdmin, systemd gave me very poor experience, changing my application daemon to be systemd compliant was not a very big deal, problem
came when I try to push systemd in real situation, I was "Nude and Alone in a winter storm", systemd was not providing enough data to
pin-point trouble. Exactly as described in the original post, "What the hell going on", now compound this with emergency situation and you are
in a very very deep trouble (sure you can do as in Windows, click again!... no?, reboot!... no?, then re-install. if you find this as acceptable, you can do it)
My Statement: Problems bring by systemd are not bugs, they are carried and embedded by systemd design.
My decision: No centos-7 in production within my servers pool. systemd is (and by far) too dangerous for production serveur. If future
is within slackware, netbsd or something else, future will say... (in 1991, I set up a Linux in production, Microsoft product were not satisfactory).

And now... to be a mean guy:
Someone say to me: "Have a look to systemd c code and search for comments and principle"
took systemctl.c, near 7000 lines of code, 2 comments line....
I used to say to my guys, "If you need to make modifications to one of your code written 6 months ago and find back your base in matter of minutes, then your code is not so bad".

dwaltz
Posts: 8
Joined: 2014/01/27 09:04:19

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by dwaltz » 2014/07/27 12:53:08

jmrcpn wrote: My decision: No centos-7 in production within my servers pool. systemd is (and by far) too dangerous for production serveur.
Our servers don't get random updates, we make baselines for the operative system as well, and we don't mess up by playing with it.
RHEL 7 is perfectly fine and production ready. So it is Centos 7.
If you need to change your servers boot sequence that often it is your policy of handling server that is broken.

jmrcpn
Posts: 5
Joined: 2014/07/18 19:06:00

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by jmrcpn » 2014/07/27 20:56:32

dwaltz wrote:
jmrcpn wrote: My decision: No centos-7 in production within my servers pool. systemd is (and by far) too dangerous for production serveur.
Our servers don't get random updates, we make baselines for the operative system as well, and we don't mess up by playing with it.
RHEL 7 is perfectly fine and production ready. So it is Centos 7.
If you need to change your servers boot sequence that often it is your policy of handling server that is broken.
Hmm... May I say you are overlooking something (how convenient), the systemd involvement origin in this thread....
seems to me you missed the point altogether.
The problem is NOT to change "servers boot sequence that often".

lets summarize/simplify it for you, from the original post....
"It took me a day to understand why postfix doesn't start with systemd while IPV6 networking is enabled"

So a "perfectly fine and production ready" (as you say) make you unable to start something as simple as postfix, not only
systemd causes trouble, but systemd report were so enlightening it took a very long time to address the problem.
What a perfect tool!.

My contribution in this thread, was to share that I had the very same kind of trouble as reported in the original post (unexpected behavior,
big trouble to diagnose) .
According to my own experience:
systemd can't address "limit situation" and that "by design" (which cause me great concern to have systemd on my server).

You know, I met peoples stating "With Cpanel, I am Sys-Admin", when they have a web site defaced, they call back
their last backup, easy enough....It may be good enough to them (not to me)

Agreed, systemd is a great tools for a "closed system". Cpanel is a closed system too and they are doing
a very good job allowing everybody managing a system (kind of).
I do not object to Cpanel, I am free not to use it.
I am objecting about systemd because it is a "trouble maker" embedded far too close from the kernel, removing flexibility from linux,
making Linux becoming another Windows. If Linux is now like Windows, why not use the original???
Long time ago, I refused the easy solution to use Microsoft product, I will adapt to another Linux distribution.

If you know something about software, the fact systemd perimeter was always increasing during development (and still
increasing?) should trigger an alarm to you.

sblantipodi
Posts: 252
Joined: 2009/07/10 09:43:13
Contact:

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by sblantipodi » 2014/07/28 19:40:06

jmrcpn wrote:
dwaltz wrote:
jmrcpn wrote: My decision: No centos-7 in production within my servers pool. systemd is (and by far) too dangerous for production serveur.
Our servers don't get random updates, we make baselines for the operative system as well, and we don't mess up by playing with it.
RHEL 7 is perfectly fine and production ready. So it is Centos 7.
If you need to change your servers boot sequence that often it is your policy of handling server that is broken.
Hmm... May I say you are overlooking something (how convenient), the systemd involvement origin in this thread....
seems to me you missed the point altogether.
The problem is NOT to change "servers boot sequence that often".

lets summarize/simplify it for you, from the original post....
"It took me a day to understand why postfix doesn't start with systemd while IPV6 networking is enabled"

So a "perfectly fine and production ready" (as you say) make you unable to start something as simple as postfix, not only
systemd causes trouble, but systemd report were so enlightening it took a very long time to address the problem.
What a perfect tool!.

My contribution in this thread, was to share that I had the very same kind of trouble as reported in the original post (unexpected behavior,
big trouble to diagnose) .
According to my own experience:
systemd can't address "limit situation" and that "by design" (which cause me great concern to have systemd on my server).

You know, I met peoples stating "With Cpanel, I am Sys-Admin", when they have a web site defaced, they call back
their last backup, easy enough....It may be good enough to them (not to me)

Agreed, systemd is a great tools for a "closed system". Cpanel is a closed system too and they are doing
a very good job allowing everybody managing a system (kind of).
I do not object to Cpanel, I am free not to use it.
I am objecting about systemd because it is a "trouble maker" embedded far too close from the kernel, removing flexibility from linux,
making Linux becoming another Windows. If Linux is now like Windows, why not use the original???
Long time ago, I refused the easy solution to use Microsoft product, I will adapt to another Linux distribution.

If you know something about software, the fact systemd perimeter was always increasing during development (and still
increasing?) should trigger an alarm to you.
I add that I noticed a random problem in starting fail2ban at boot.
You know, random problem are the worst problem you can challenge with, but knowing that systemd is broken, I solved it pretty quickly once discovered.
When fail2ban starts its jails it sends me an email, if postfix isn't started yet, fail2ban fails to start.
I had to correct the fail2ban.service to say systemd to start fail2ban after postfix.

PS: Never used cpanel on my systems, so I can't comment on it.

dwaltz
Posts: 8
Joined: 2014/01/27 09:04:19

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by dwaltz » 2014/07/28 20:43:22

jmrcpn wrote: I am objecting about systemd because it is a "trouble maker" embedded far too close from the kernel, removing flexibility from linux,
making Linux becoming another Windows. If Linux is now like Windows, why not use the original???
Let me quote from the Debian discussion on systemd adoption
Sysvinit is insufficient for desktops, mostly because of missing features such as the D-Bus interfaces. But the real problems arise on big server setups, where Debian is losing ground because of its antiquated init system. On these systems, you need fine service management, process monitoring, reliable dependencies, complex device setups and proper event handling.
Upstart was a huge improvement over sysvinit, and Debian should have switched to it years ago. Now that systemd is available and well-tested, however, it cannot sustain the comparison
... the choice for Debian’s init system should be made mostly on technical merit. It is clear to us that systemd is overwhelmingly better than any existing alternative anywhere the technical architecture is involved.
OpenSuse Fedora, Arch, Mageia, now RHEL/CentOS use it and SUSE Sles and Debian/ubuntu might adopt it soon.
All gone crazy?

jmrcpn
Posts: 5
Joined: 2014/07/18 19:06:00

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by jmrcpn » 2014/07/29 00:37:10

dwaltz wrote:
... the choice for Debian’s init system should be made mostly on technical merit. It is clear to us that systemd is overwhelmingly better than any existing alternative anywhere the technical architecture is involved.
OpenSuse Fedora, Arch, Mageia, now RHEL/CentOS use it and SUSE Sles and Debian/ubuntu might adopt it soon.
All gone crazy?
Fedora=RHEL=CENTOS (same decision maker), for the other I can't say...
All gone crazy. my guess, Yes.... Fashion Effect, Marketing push....
(when I compared B-747 and Concorde, it was done on purpose, may be you are too young to remember Marketing push about Concorde.....
Better, Faster, Smarter than B-747, the future! the 21 century!..., all was pure politics, technical merit were discarded, now count the number
of B-747 in the sky and compare it to Concorde number.).

Seems for what I have seen in comments, guys with server mileage are mostly reluctant/rejecting systemd, saying desktop "may be", server "no"....
my peers (via comment I can recognize with the same profile as mine) are saying "extreme caution" AND my personnal experience using systemd
concur with that.
I fully understand why Redhat is doing this, but decision was not on technical merit.
Time to fork a distribution server oriented? :-}}}

dwaltz
Posts: 8
Joined: 2014/01/27 09:04:19

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by dwaltz » 2014/07/29 13:40:40

jmrcpn wrote: I fully understand why Redhat is doing this, but decision was not on technical merit.
Time to fork a distribution server oriented? :-}}}
I think that managing a list of scripts where the the dependencies is hardcoded in the scripts themselves is no way easier, on the other side systemd has even debugging and introspection mode.
I agree that when something this big changes there can be problems, but in the long run this will be a winning feature of Linux. Don't give up.

jmrcpn
Posts: 5
Joined: 2014/07/18 19:06:00

Re: My two cents on "the new Linux" -> RedHat EL7 / CentOS 7

Post by jmrcpn » 2014/07/29 18:00:39

dwaltz wrote:
jmrcpn wrote: I fully understand why Redhat is doing this, but decision was not on technical merit.
Time to fork a distribution server oriented? :-}}}
I think that managing a list of scripts where the the dependencies is hardcoded in the scripts themselves is no way easier, on the other side systemd has even debugging and introspection mode.
I agree that when something this big changes there can be problems, but in the long run this will be a winning feature of Linux. Don't give up.
I am liking our exchanges, even we are not speaking on the same level.
You say: systemd, is just another way to do init, "just don't give up",
I say (and other say): systemd is not only another (bright) way to do init, host/kernel implications are major.

Just for Fun, here is an extract from another mailling just entered today (About LXC, (lxc=containers)), a mailling list I am following, didn't
participate for a very long time now.
;----
Initial Post:
HI all
When container with centos-7 x86_64 started, process systemd-journald
eat cpu in next loop:

Post Answer:
That's a journald problem that they (systemd) had claimed (in their
bugzilla report) was fixed. Had something to do with object id's and
ordinals getting out of order. I guess they lied. It's one of the
curses of using opaque binary file formats for storing data like this.
Somehow the object id's get out of sequence and journald looses its mind
and does a sit and spin on the cpu. It's been seen in non-LXC cases
(something to do with user journals) but seems to be worse under LXC. I
had been disabling journald in Fedora containers but had recently
reenabled them. That appears to have been a mistake.
;---

Once Again:
According my own experience with systemd (working mainly with container too, but on plain HOST to)...
There is no bug in Systemd, there is a 'by design' troubles.
Hope you are starting to see a little bit beyond the systemd shell language.

Post Reply