LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Closed Thread
 
Search this Thread
Old 06-18-2013, 05:22 PM   #496
elvis4526
Member
 
Registered: Aug 2011
Posts: 114

Rep: Reputation: Disabled

Quote:
Originally Posted by ReaperX7 View Post
This is why I fail to understand why there is such a uninformed rush, like ArchLinux did, to implement systemd without it being matured well enough to be reliable in the long run.

The Parallel service starting system works on paper, but even Gentoo and OpenRC have said that starting services in Parallel is experimental in nature because if a dependency service is started after it is required the service that depends on it can not function, and why Linear mode is recommended.

This is why I said numerous times, yet it fell on deaf ears, that systemd is Alpha class software, nowhere near ready even by Red Hat's estimates, to be mass deployed or even used as a core system daemon.

Five years from now, it might be ready, it might be matured enough, it might even be stable enough, and work properly to be a full successor to SysVInit, but it's not there yet, and 5 years time might still be a rough estimate. It might not ever be ready.
1) ArchLinux doesn't intent do be a reliable or stable distribution. It intend to be a bleeding-edge distribution with latest upstream softwares and technologies.

2) You are the one having deaf ears, stop commenting on what you don't even understand. Systemd use socket activation to parallelize the boot process. As far as I know, OpenRC doesn't use this, so even if they try to accomplish the same thing, it's not the same thing at all. Therefore, you can't say systemd parallelization capabilities are buggy because OpenRC ones are.

3) How can you estimate how much time it will take for a software to "mature" if you don't even have a single idea about what programming is ?
 
1 members found this post helpful.
Old 06-18-2013, 05:29 PM   #497
elvis4526
Member
 
Registered: Aug 2011
Posts: 114

Rep: Reputation: Disabled
Quote:
Originally Posted by TobiSGD View Post
This must be the reason why RHEL 7, scheduled for the second half of 2013, will come with systemd as init system. Where did you get the information that Red Hat thinks systemd is not production ready?
I think he's a troll, I shouldn't answer him anymore.
 
Old 06-18-2013, 05:42 PM   #498
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,999

Rep: Reputation: Disabled
Quote:
Originally Posted by elvis4526 View Post
2) You are the one having deaf ears, stop commenting on what you don't even understand. Systemd use socket activation to parallelize the boot process. As far as I know, OpenRC doesn't use this, so even if they try to accomplish the same thing, it's not the same thing at all. Therefore, you can't say systemd parallelization capabilities are buggy because OpenRC ones are.
Socket activation seems to be a great way of making something simple (serialized startup) extremely complicated, all in the name of shaving microseconds off the boot time.

I also like the way the second article makes a big deal of starting CUPS on-demand, which would previously have required one line of text in /etc/inetd.conf. But no, in order to cater for every possibility (heaven forbid we leave anything for the user to decide or configure), a hideously complex system of 4 different "activations" are designed to start CUPS.

It continues to amaze me how anyone can say with a straight face that this is in any way an improvement.
 
2 members found this post helpful.
Old 06-18-2013, 06:01 PM   #499
elvis4526
Member
 
Registered: Aug 2011
Posts: 114

Rep: Reputation: Disabled
Quote:
Originally Posted by Ser Olmy View Post
Socket activation seems to be a great way of making something simple (serialized startup) extremely complicated, all in the name of shaving microseconds off the boot time.

I also like the way the second article makes a big deal of starting CUPS on-demand, which would previously have required one line of text in /etc/inetd.conf. But no, in order to cater for every possibility (heaven forbid we leave anything for the user to decide or configure), a hideously complex system of 4 different "activations" are designed to start CUPS.

It continues to amaze me how anyone can say with a straight face that this is in any way an improvement.
It's not just some microseconds, but more like several seconds.
My boot time with systemd on a SSD is like 3 seconds.
On slackware it is a least 10 seconds,
I didn't know 7 seconds was the same thing as a microsecond

Anyway, the url that you pointed out is for developper, not user.
I don't believe an average developper can't make an effort to understand the basics behind socket activation.

Last edited by elvis4526; 06-18-2013 at 06:07 PM.
 
Old 06-18-2013, 06:13 PM   #500
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,999

Rep: Reputation: Disabled
Quote:
Originally Posted by elvis4526 View Post
It's not just some microseconds, but more like several seconds.
My boot time with systemd on a SSD is like 3 seconds.
On slackware it is a least 10 seconds,
I didn't know 7 seconds was the same thing as a microsecond
Even Mr. Poettering himself uses an example in the article where he describes the startup time as "slightly smaller", which does not seem very significant. And as I've mentioned earlier, startup times on any system other than an end-user PC that for some reason doesn't use hibernation is pretty much irrelevant.

My main point about the added layer of unnecessary complexity added by systemd still stands. Even if systemd didn't introduce compatibility issues and breakage (which it does in spades), there are plenty of reasons why it isn't a viable replacement to SysV, inetd, syslogd and who knows how many other components the project will attempt to absorb before it falls over.
 
1 members found this post helpful.
Old 06-18-2013, 06:52 PM   #501
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
Quote:
Originally Posted by TobiSGD View Post
This must be the reason why RHEL 7, scheduled for the second half of 2013, will come with systemd as init system. Where did you get the information that Red Hat thinks systemd is not production ready?
We will see what RHEL's "systemd" will have in common with "systemd" from freedesktop.org git. I think not much.

Despite this it's just GPLed vendor-proprietary infrastructure. There is no open standard at all.
 
Old 06-18-2013, 07:01 PM   #502
astrogeek
Senior Member
 
Registered: Oct 2008
Distribution: Slackware: 12.1, 13.1, 14.1, 64-14.1, -current, FreeBSD-10
Posts: 1,953

Rep: Reputation: 727Reputation: 727Reputation: 727Reputation: 727Reputation: 727Reputation: 727Reputation: 727
Quote:
Originally Posted by jtsn View Post
Despite this it's just GPLed vendor-proprietary infrastructure. There is no open standard at all.
Nail... hammer... whack!

Last edited by astrogeek; 06-18-2013 at 07:01 PM. Reason: Typo
 
Old 06-18-2013, 07:01 PM   #503
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,999

Rep: Reputation: Disabled
Quote:
Originally Posted by jtsn View Post
Despite this it's just GPLed vendor-proprietary infrastructure. There is no open standard at all.
True, and that's more than a little worrying. Ripping out the Unix-y guts of Linux and replacing it with something very much vendor-specific looks an awful lot like step 2 of an "embrace - extend - extinguish" strategy.
 
1 members found this post helpful.
Old 06-18-2013, 07:03 PM   #504
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,239

Rep: Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577
Quote:
Originally Posted by elvis4526 View Post
It's not just some microseconds, but more like several seconds.
My boot time with systemd on a SSD is like 3 seconds.
On slackware it is a least 10 seconds,
I didn't know 7 seconds was the same thing as a microsecond
I think you misunderstood - I think he was referring to a "per service activation". And socket activation is what inetd/xinetd does.

The 7 second start is still there - after all, when you start to print it still takes time to get the service running. And adding up the time for all services still gets you the 7 seconds.

The problem with it is that you don't know if the printer is ready for use when the system is "ready for use". Normally, if there is a configuration problem with CUPS you know it as soon as the service attempts to start, and can start getting ready to fix it before users get to the system. With systemd, you don't know... until users start complaining.

And if you want about 5 second boot on Slackware, try bypassing the initrd...

The other thing about SysVinit and parallel startup - SysVinit does permit it, if it is implemented. Those services with the same start value (the Snn... and Knn...) are permitted to run in either order, or in parallel. It is just that none of the implementations actually did that. They all used the alphabetic sort order of the file name - so those services with the same Snn/Knn values determined the start order based on the rest of the name.

Most of the implementations I've seen were rather simple shell scripts.

So yes, things COULD be improved. I just don't think systemd is the right one.

Look up the information on PERT charts and their use. You will recognize a less complex form of scheduling that is equivalent to what systemd does.

http://en.wikipedia.org/wiki/Program...view_Technique

And you will see why it isn't used that much anymore.

One problem with socket activation is that it depends on TCP starting properly. I worked with a UNICOS system back in the mid-to-late 90s that had "optimization" for socket services added to inetd. What they did was put the entire listen/accept loop in inetd. This was done because a fork/exec was quite slow, and if the connection was denied, it wasted a fork/exec, and cause possible swapping activity (which on a Cray was quite expensive).

Worked well in the lab. Improved response rates something around 5%, reduced system overhead as well.

Unfortunately, when it was installed at our site - it hung the system (as far as external users could see).

What was happening was the initial connection from a user came in... and the acks/response sent back. But a router/switch (fairly close tot the user) had an error... and forwarded the acks out the wrong interface, so the client system never saw them. And hung their connection. Of course since the client system didn't see the acks, it had no way to complete the TCP setup handshake. Since the handshake wasn't completed the server (the Cray inetd service) never completed the accept. That meant that the entire inetd service hung.

All we had to do when it occurred was abort inetd and restart it... and inform Cray of the problem.

It took their engineers only about three days to identify the solution (undo the optimization). We had that by the end of the week, and the restored functionality was there.

The result was that instead of hanging inetd, it would hang the specific service for a specific accept - and that would timeout after 10-15 minutes (or when we aborted it). But users not on that particular client system had no problems.

I vaguely remember that it took the network people about another week to find out which router/switch had the error. (Having three different network groups involved didn't help, too many "no problem on my network"...).

But for reliability that optimization was dropped.
 
Old 06-18-2013, 07:08 PM   #505
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,771

Rep: Reputation: 205Reputation: 205Reputation: 205
Quote:
Originally Posted by elvis4526
My boot time with systemd on a SSD is like 3 seconds.
You can easily make any Slackware installation boot you to a shell prompt within microseconds by pointing the kernel toward /bin/sh instead of /bin/init.

Of course, no services will be started, but hey, it's all about speed isn't it?

Seriously dude, nobody cares about boot times.
 
Old 06-18-2013, 07:35 PM   #506
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,239

Rep: Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577Reputation: 577
Quote:
Originally Posted by elvis4526 View Post
...
2) You are the one having deaf ears, stop commenting on what you don't even understand. Systemd use socket activation to parallelize the boot process. As far as I know, OpenRC doesn't use this, so even if they try to accomplish the same thing, it's not the same thing at all. Therefore, you can't say systemd parallelization capabilities are buggy because OpenRC ones are.
Only partly. This is the "assimilated" inetd/xinetd functions.

For others it just starts them and assumes that they have completed.

This is why they have so much trouble with the network. Originally, it would start NetworkManager, and because NetworkManager had not exited then "the network was ready".

Except that it isn't.

The problem was that it takes time for NetworkManager to read its configuration, and then initialize network interfaces. In that gap, other services that depend on the network COULD start... and fail because the network really wasn't ready.

So they added another target (more complexity) called "NetworkManager-wait-online"... Which causes systemd to wait until NetworkManager sends a message back (I believe via dbus) to tell systemd it has started. Sounds good. Works... well sometimes.

The problem with NetworkManager is that it has to wait for dhclient sometimes. So it appears that NetworkManager sends the "ready" message when it has started dhclient.. but dhclient can take up to a minute or so to initialize the network. So again, services that need the network can fail. Granted, static networks do seem to get initialized (as long as there is only one interface) properly. DHCP seems to defeat it - as does complex networks. I still can't get the networks to function properly when hosting VMs. Networks don't work until I completely disable NetworkManager and go with the legacy startup scripts. Then everything works OK.

This is the problem with systemd - it has no way to know if a service is actually running. In the SysVinit method, the script is delayed until the service becomes a daemon. At that point, the service has read its configuration file, and initialized any network/socket requirements. If this fails, you know it immediately. Systemd has no way to know unless EVERY service gets modified to send a "Working" message back.

And what to do with compound services (like NetworkManager and dhclient)? Make dhclient send a message to NetworkManager so NetworkManager can then send a message back to systemd? What happens with multiple networks and one DOESN'T come up? Is the network ready? Or not???? Does the boot hang?
 
Old 06-18-2013, 08:06 PM   #507
Ser Olmy
Senior Member
 
Registered: Jan 2012
Distribution: Slackware
Posts: 1,999

Rep: Reputation: Disabled
Quote:
Originally Posted by jpollard View Post
This is why they have so much trouble with the network. Originally, it would start NetworkManager, and because NetworkManager had not exited then "the network was ready".

Except that it isn't.
This is why any mention of systemd causes my blood pressure to rise ever so slightly. Starting network services before the network is ready? How is it possible for such a monumental design error to ever make it past testing and out of the lab? Daemons that provide network services need network connectivity, that's so obvious a 5-year old would see it.

But that only really applies to severs. On a desktop system you may not even notice that CUPS is only bound to localhost.

Same goes for the abomination that is firewalld. Even the documentation can make your hair stand on end; it makes it possible for other processes to reconfigure the firewall using D-BUS messages. Why on earth would you ever want that? That's a potential security hole right there.

But of course, it may make sense on a desktop system where an application suddenly wants to listen to incoming connections.
 
Old 06-18-2013, 08:19 PM   #508
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0
Posts: 3,411
Blog Entries: 15

Rep: Reputation: 953Reputation: 953Reputation: 953Reputation: 953Reputation: 953Reputation: 953Reputation: 953Reputation: 953
Quote:
Originally Posted by elvis4526 View Post
I think he's a troll, I shouldn't answer him anymore.
I'm sorry you feel this way, but maybe you need to stop being such a elitist with your high-and-mighty programmer status and become a lowly system/network administrator for a change and see how we see things on our end along with all the bullcrap, headaches, and endless screw-ups we have to deal with from programmers with holier-than-thou attitudes and I-wanna-be-always-right agendas.

We know systemd isn't ready because we've dealt with systems and distributions that have implemented it and it's nothing but a burden. I use ArchLinux, and honestly it's very poorly implemented for a distribution that prides itself on being bleeding edge. There's a fine line on having bleeding edge software, and being reckless with unstable software. As I stated, I know from experience that systemd is not ready regardless of what Red Hat keeps projecting, or YOU keep spouting off.

A well seasoned administrator knows when software is NOT reliable, and what is reliable. Until you are a seasoned administrator of systems and networks... you don't have much room to talk.

Quote:
Originally Posted by jpollard View Post
Only partly. This is the "assimilated" inetd/xinetd functions.

For others it just starts them and assumes that they have completed.

This is why they have so much trouble with the network. Originally, it would start NetworkManager, and because NetworkManager had not exited then "the network was ready".

Except that it isn't.

The problem was that it takes time for NetworkManager to read its configuration, and then initialize network interfaces. In that gap, other services that depend on the network COULD start... and fail because the network really wasn't ready.

So they added another target (more complexity) called "NetworkManager-wait-online"... Which causes systemd to wait until NetworkManager sends a message back (I believe via dbus) to tell systemd it has started. Sounds good. Works... well sometimes.

The problem with NetworkManager is that it has to wait for dhclient sometimes. So it appears that NetworkManager sends the "ready" message when it has started dhclient.. but dhclient can take up to a minute or so to initialize the network. So again, services that need the network can fail. Granted, static networks do seem to get initialized (as long as there is only one interface) properly. DHCP seems to defeat it - as does complex networks. I still can't get the networks to function properly when hosting VMs. Networks don't work until I completely disable NetworkManager and go with the legacy startup scripts. Then everything works OK.

This is the problem with systemd - it has no way to know if a service is actually running. In the SysVinit method, the script is delayed until the service becomes a daemon. At that point, the service has read its configuration file, and initialized any network/socket requirements. If this fails, you know it immediately. Systemd has no way to know unless EVERY service gets modified to send a "Working" message back.

And what to do with compound services (like NetworkManager and dhclient)? Make dhclient send a message to NetworkManager so NetworkManager can then send a message back to systemd? What happens with multiple networks and one DOESN'T come up? Is the network ready? Or not???? Does the boot hang?
The boot process should always perform a load and check of required dependencies for services being used, and even then of all services. SysVInit does this well, so does BSDInit, OpenRC, and other properly done Init programs. Why systemd fails to do this is yet, as stated in plain English, is part of the problem that systemd just isn't ready yet. Too much is still broken or improperly implemented.

Last edited by ReaperX7; 06-18-2013 at 08:39 PM.
 
Old 06-19-2013, 06:00 AM   #509
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by ReaperX7 View Post
As I stated, I know from experience that systemd is not ready regardless of what Red Hat keeps projecting, or YOU keep spouting off.
So, first you claim that even Red Hat thinks that systemd isn't ready for production to make your point, now that we have pointed out that it will be the init system in RHEL 7 it is irrelevant what Red Hat thinks about it. That is interesting, you seem to shift your argumentation how it works best to make your point. It seems to me that you are the one with the
Quote:
I-wanna-be-always-right agendas
Anyways, reading this
Quote:
A well seasoned administrator knows when software is NOT reliable, and what is reliable. Until you are a seasoned administrator of systems and networks... you don't have much room to talk.
I am not quite sure what you want to say. Do you think that the engineers at Red Hat are not seasoned enough to know that systemd is not production ready, so they integrate this unready software into their product, which creates a revenue of more than one billion dollars for them?
If so, maybe you should ask them for a job, since you seem to be so much more experienced and can help them to make a better product.

Last edited by TobiSGD; 06-19-2013 at 06:01 AM.
 
1 members found this post helpful.
Old 06-19-2013, 07:41 AM   #510
dfwrider
Member
 
Registered: Feb 2010
Location: San Antonio, Texas, USA
Distribution: slackware
Posts: 32

Rep: Reputation: 17
There are good programmers, and there are bad programmers.

The good programmers eat their own dog food, and more importantly provide support to others who eat it as well.

This has a tendency to keep solutions tied to simplicity and necessity.
 
2 members found this post helpful.
  


Closed Thread

Tags
cgroups


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Slackware: Is Systemd Inevitable? LXer Syndicated Linux News 5 07-22-2013 04:54 AM
[SOLVED] slackware and systemd fl0 Slackware 512 08-29-2012 11:07 AM
slackware and systemd (OT) eloi Slackware 44 08-24-2012 04:36 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 11:40 AM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 09:02 AM


All times are GMT -5. The time now is 08:07 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration