Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
|
11-29-2013, 04:15 PM
|
#121
|
LQ Guru
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
|
Quote:
Originally Posted by 55020
It's Friday night, and I'm dog-tired, and probably about to make myself look stupid, but here goes...
Would it be possible to run systemd *under* the old init system?
So systemd would be just another subordinate daemon that performs only those functions it has completely assimilated (cgroups, logind, udev), but it wouldn't be doing the stuff we can still do the old way, like starting daemons and changing runlevels.
I'm guessing that this would make "upstream" go ballistic, and it's a use case that they haven't allowed for, and will not consider patches for, and I'm stupid, and I hate disabled people and kittens ... but if we ever eventually *had* to use it, I'd prefer it to have its own small and rigidly defined area of doubt and uncertainty.
ps. Please, please tell me that the libqrencode dependency is an April Fool's that they forgot to take out...
|
Actually you're argument is valid, but then systemd would be completely unnecessary on the whole as GNU already has it's own daemon services management system within the collective efforts of the GNU project and the kernel.org maintained packages specifically to help manage the Linux kernel.
Remember, systemd isn't about doing things the proper way, the UNIX way, the right way... it's about doing things the Linux way, possibly the Red Hat way, and saying "screw you" to everyone else.
Basically in order to function, you still have to have sysvinit-based systemd scripts to have a properly working system that isn't improperly loaded. The question I have is, if this is what we need, why can't we just scrap systemd if the systemd method of parallel loading still doesn't work properly and falling back to sysvinit scripts is the only way maintain a working system environment.
If it doesn't work as intended, why bother? I still support Bart's effort to try and get a working solution, but honestly, it's just too much of a headache.
My question is this then:
Has any one tried to import another init and daemon management system like runit, s6, or OpenRC into Slackware and have better results? Before we commit to systemd, we should at least weight the options to see if there are other solutions that aren't as demanding on the system and user.
Last edited by ReaperX7; 11-29-2013 at 04:22 PM.
|
|
1 members found this post helpful.
|
11-29-2013, 04:28 PM
|
#122
|
Member
Registered: Feb 2003
Location: Almere, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 368
Original Poster
Rep:
|
@55020: untill v204 this was possible yes.
You were able to use just logind, but newer version does not support this.
@jprzybylski: it can be disabled or enabled. it is not a dependency, unless you enable it offcourse.
@ReaperX7: that makes it a big problem for the 1st time that users/distro maintainers switch to systemd.
but it does give the power to the user/maintainer to decide what has to start when.
you are in charge how it has to start, when it has to start, etc.
and all this in 1 config file, which makes it easier to maintain than doing in multiple files.
as said before, imo it is not ready yet to replace sysvinit and sysvinit scripts.
The project is for multiple reasons.
- making it easier for users that already played with systemd on slackware to make the switch (if pat goes that way)
- we as community to help pat if he decides to make the switch.
- if pat never makes the switch, users still have the freedom to use systemd on slackware if they want.
and thats all what it is about.
|
|
|
11-29-2013, 07:57 PM
|
#123
|
LQ Guru
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
|
Quote:
Originally Posted by bartgymnast
@55020: untill v204 this was possible yes.
You were able to use just logind, but newer version does not support this.
@jprzybylski: it can be disabled or enabled. it is not a dependency, unless you enable it offcourse.
@ReaperX7: that makes it a big problem for the 1st time that users/distro maintainers switch to systemd.
but it does give the power to the user/maintainer to decide what has to start when.
you are in charge how it has to start, when it has to start, etc.
and all this in 1 config file, which makes it easier to maintain than doing in multiple files.
as said before, imo it is not ready yet to replace sysvinit and sysvinit scripts.
The project is for multiple reasons.
- making it easier for users that already played with systemd on slackware to make the switch (if pat goes that way)
- we as community to help pat if he decides to make the switch.
- if pat never makes the switch, users still have the freedom to use systemd on slackware if they want.
and thats all what it is about.
|
I tend to agree. I'd like to ask how much has your research into systemd for Slackware progressed?
I'd also like to know if you, Bart, have any plans to look into importing other init solutions?
|
|
|
11-29-2013, 08:40 PM
|
#124
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912
|
Quote:
Originally Posted by 55020
It's Friday night, and I'm dog-tired, and probably about to make myself look stupid, but here goes...
Would it be possible to run systemd *under* the old init system?
So systemd would be just another subordinate daemon that performs only those functions it has completely assimilated (cgroups, logind, udev), but it wouldn't be doing the stuff we can still do the old way, like starting daemons and changing runlevels.
I'm guessing that this would make "upstream" go ballistic, and it's a use case that they haven't allowed for, and will not consider patches for, and I'm stupid, and I hate disabled people and kittens ... but if we ever eventually *had* to use it, I'd prefer it to have its own small and rigidly defined area of doubt and uncertainty.
ps. Please, please tell me that the libqrencode dependency is an April Fool's that they forgot to take out...
|
"Had to use" is the problem. Systemd takes over all functions of init, inetd/xinetd, network management, udev, syslog, and mandates the use of dbus (the tie ins are so bad it won't work unless dbus, udev are both functional). In fact, the interdependencies are so bad it will crash the system if any one of them crashes - especially if dbus quits.
One of the big ones is that it takes over a lot of the functions daemons should have - it opens any sockets itself (as in inetd), it creates the daemon processes itself, but also doesn't necessarily even start the service... so problems with a service don't show up until after the system is supposedly "operational".
Anyone that has had to work with PERT chart techniques would recognize the inherent shortcomings. It can't scale to handle really large problems. It is actually worse than the "simple" PERT chart comparison - at least the PERT charts only have ONE dependency path... systemd has at least 4. (before, after, requires, wanted by...), which makes it trivial to get things locked up, and not easily repaired.
Even now.. it STILL can't reliably shut a system down, and you can't debug it as the system gets hung...
And I'm not impressed with logind either for that matter. Another single point of failure making things hard to diagnose (problems like "can't login to find out what the problem is...").
One problem I have with Fedora is that it has become trivial to have a local DOS attack - since Fedora has used the /run for mounts, user credentials, AND service pid files - any user can fill the /run filesystem causing various system failures (can't login, services fail to start, mount failures, system out-of-memory crashes). Really bad security practice. Might be acceptable for a single user tablet - but useless for servers.
|
|
2 members found this post helpful.
|
11-30-2013, 11:58 AM
|
#125
|
Member
Registered: Feb 2003
Location: Almere, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 368
Original Poster
Rep:
|
I never had a problem with system shutdown.
|
|
|
11-30-2013, 01:47 PM
|
#126
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912
|
Quote:
Originally Posted by bartgymnast
I never had a problem with system shutdown.
|
You don't do anything very complex.
The problem is systemd keeps overlooking things. Databases that take a while, processes that depend on other activity...and go into a wait state when that other process is killed. Running multiple VMs...
The other problem is that SOMETIMES it will work... So very little chance of getting it right.
|
|
|
11-30-2013, 06:58 PM
|
#127
|
LQ Guru
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
|
Sometimes working is not proper implementation even on the developer's end. It simply has to work, period, no questions asked on any level and ground. As if we don't have enough problems with existing bad software like udev which occassionally still manages to entice a torch wielding mob, dealing with a non-diagnosable non-debuggable system is just totally improper against the UNIX way of doing things, hence my signature quote. To be honest, Bart, your effort is commendable, but as existing problems with scaled up systems on massive scales prove the point that systemd was not designed with servers and databases in mind, but rather for end-user systems such as desktops, workstations, and laptops, the chances of failure are just too great.
I think honestly, we just aren't ready for this, and probably will never be as Slackware is designed to be a universeal adapted system, and not just a niche distribution for servers, desktops, workstations, and/or laptops withina single poitn of argument.
There's too much at stake with the system to start relying on software that isn't carrying a proper level of ethics and developmental prowess within it's own implementation versus readily available alternatives, and existing architectures.
There are other ventures that could be made with more sound implementations, and right now, maybe systemd needs to be put on hold so we can research other methods to aid Slackware rather than hurt it.
S6 and RunIt both are prime candidates to research add-in software that can be made to either assist sysvinit or replace it. OpenRC is yet another viable alternative, so for now, maybe we need to research these and come back to systemd when the upstream fixes the most outstanding of issues.
|
|
|
11-30-2013, 09:16 PM
|
#128
|
Moderator
Registered: Dec 2009
Location: Germany
Distribution: Whatever fits the task best
Posts: 17,148
|
Quote:
Originally Posted by ReaperX7
There are other ventures that could be made with more sound implementations, and right now, maybe systemd needs to be put on hold so we can research other methods to aid Slackware rather than hurt it.
|
I don't see how bartgymnast's effort to create working systemd packages can hurt Slackware.
Quote:
S6 and RunIt both are prime candidates to research add-in software that can be made to either assist sysvinit or replace it. OpenRC is yet another viable alternative, so for now, maybe we need to research these and come back to systemd when the upstream fixes the most outstanding of issues.
|
Sorry, but I don't see the point in replacing Slackware's init system with anything but systemd. If you don't want systemd keep SysV init, it is well tested and works. For me the only reason to switch the init system (besides the just for fun aspect with learning how to do it) would be if I have to use software that has hard dependencies on a different init system. This will simply not be the case for anything but systemd.
|
|
1 members found this post helpful.
|
11-30-2013, 11:31 PM
|
#129
|
LQ Guru
Registered: Jul 2011
Location: California
Distribution: Slackware64-15.0 Multilib
Posts: 6,564
|
Doing things the right way to aid sysvinit/bsdinit or have the choice of replacing it with a tested, working, and VIABLE solution that is at least known to work well is what SHOULD be looked into Tobi. I'm not even saying we have to use S6, RunIt, or OpenRC. I'm suggesting that these software systems should be researched as ways to assist and aid sysvinit/bsdinit. Systems that are tested, known to work, work well, and not be aggressively invasive to the system. I never once said, we had to use them or Slackware will fall apart at the seams.
The problem is regardless of how much work has or will be done to create a minimally invasive working port of systemd to Slackware, the problem is, there are unresolved issues within the whole program, and the fact that upstream refuses to address some of the most common issues that makes me skeptical if it will work.
Bart's work has been incredibly commendable, and he's done well to minimize the impact of systemd to where it would fit into Slackware without any issues, but the problem is not with Bart, it's with the upstream developers not being willing to do fix known broken and outstanding issues.
Regardless of how well a package is made, how much care, time, and effort went into making it, and how much consideration was made into how it would deliver into the system on the whole, if there are problems with the software, it won't matter how much work you did to make as well designed of a package as you did, because bad software, is still bad software.
|
|
|
12-01-2013, 04:11 AM
|
#130
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912
|
Quote:
Originally Posted by TobiSGD
I don't see how bartgymnast's effort to create working systemd packages can hurt Slackware.
Sorry, but I don't see the point in replacing Slackware's init system with anything but systemd. If you don't want systemd keep SysV init, it is well tested and works. For me the only reason to switch the init system (besides the just for fun aspect with learning how to do it) would be if I have to use software that has hard dependencies on a different init system. This will simply not be the case for anything but systemd.
|
The problem with systemd is that it is NOT compatible with SysVinit at all.
Even Fedora tried to allow it to be an alternative... but when you went to use SysVinit package (as implemented in upstart) the system reported dozens of failures, and refused to work. So instead the developers forced it by dropping SysVinit entirely.
What they did was actually change the services to be compatible with systemd - and that breaks nearly everything. The services USED to be completely stand-alone, allowing them to determine for themselves if things were ready for operation - and choose whether to just wait a bit and retry, or report a failure. Now, they are dependent on systemd to perform all that - all they can do is report failure, but the reports are not complete, nor are they timely. And now they have destroyed syslog by putting a systemd dependent journald - with a binary log. And all logging must be routed through systemd...
Just look at the problems caused by NetworkManager - originally, it worked (though with some bugs). With the SysVinit it became mostly usable. Then they converted it to systemd - first systemd couldn't even determine if the network was up (NetworkManager was running), so it assumed the network was working and started network based services... and failed randomly (failing more often than working). So they added another design flaw - (NetworkManager-wait-online) to cause systemd to delay until NetworkManager believed the network was up. Works a whole lot better... except sometimes...
There were several reasons for the failure:
1) systemd assumes a service is running as soon as the process is started. The failure here is that it takes time for the process to complete its initialization, reading configuration files, and actually doing the setup. And this problem applies to ALL services.
2) the kludged NetworkManager-wait-online cannot always work - SOME network initialization requires external setup - think DHCP. Network manager has to assume the network is up because it may have started DHCP.. but DHCP itself has to process its configuration files... and request configuration from an external entity (usually once, but sometimes multiple times depending on network activity).
3) complex networks take longer to setup than simple ones. Just because one network is up doesn't mean the network subsystem is fully usable. Problem here is that VMs require an internal virtual network. And (at least in my case), multiple VMs would fail. The only reliable solution I have found so far is to completely disable NetworkManager. Even now, NetworkManager fails for others due to some complex network interactions (possibly due to timing errors).
4) complex services STILL fail. Databases are still failing (sometimes)- and having a complex of services (think Apache/MySQL (or any database, on the same system or different), with multiple networks... and you are a prime candidate for timing failures - which systemd cannot handle due to the complexity of the web of dependencies it has to use, and the thundering herd scheduling it uses.
Originally, DHCP would be started, but delay becoming a daemon until AFTER it had completed its own initialization (for all I know, it may even have delayed until the first query went out - never had any problems with it, so I never looked into it). Now, systemd starts NetworkManager and network Manager starts DHCP... which puts systemd two steps away from the network. SysVinit is only one step. The problem with the VMs was the same - starting virtd requires the networks that it may use be up... but due to timing errors it might not be (in my case, it looked almost like the network subsystem itself wasn't working).
Systemd cannot work properly - meaning reliably and under control of the system administrator. It needs too many feedback points (which why dbus gets added to the dependency list). Everything they have been adding to it is just papering over the basic design flaw - which is believing they can automatically determine a dependency list from the given web of specifications, which are extremely sensitive to system loads, and very error prone to set up.
|
|
1 members found this post helpful.
|
12-01-2013, 05:03 AM
|
#131
|
MLED Founder
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: CentOS, OpenSUSE
Posts: 3,453
|
Quote:
Originally Posted by jpollard
The problem with systemd is that it is NOT compatible with SysVinit at all.
Even Fedora tried to allow it to be an alternative... but when you went to use SysVinit package (as implemented in upstart) the system reported dozens of failures, and refused to work. So instead the developers forced it by dropping SysVinit entirely.
What they did was actually change the services to be compatible with systemd - and that breaks nearly everything.
|
I guess it's time to introduce the Poettering-Kruger syndrome: a cognitive bias in which unskilled developers suffer from illusory superiority, mistakenly rating their ability much higher than is accurate. This bias is attributed to a metacognitive inability of the unskilled to recognize their ineptitude.
|
|
4 members found this post helpful.
|
12-01-2013, 05:18 AM
|
#132
|
Member
Registered: Sep 2011
Posts: 925
|
Quote:
Originally Posted by bartgymnast
@55020: untill v204 this was possible yes.
You were able to use just logind, but newer version does not support this.
|
While most software is created to make things work, other software specifically is created to break things that work. The latter is called malware.
Quote:
Originally Posted by jpollard
1) systemd assumes a service is running as soon as the process is started. The failure here is that it takes time for the process to complete its initialization, reading configuration files, and actually doing the setup. And this problem applies to ALL services.
|
If someone is trying to copy the services concept from Windows, he should copy it correctly. Windows services are able to work reliable even with parallel startup. The reason for this: MS actually had some smart people available for their OS design, while Red Hat clearly has not.
So Fedora is broken. And a lot of Linux distributors copy them.
Last edited by jtsn; 12-01-2013 at 05:52 AM.
|
|
3 members found this post helpful.
|
12-01-2013, 06:09 AM
|
#133
|
Senior Member
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,307
Rep:
|
I guess we should remember that this is the constructive, positive systemd thread ... even if I agree with the points being made and admire the people making them...
(shockingly, LQ doesn't have a smilie that fits this situation!)
|
|
3 members found this post helpful.
|
12-01-2013, 06:14 AM
|
#134
|
Member
Registered: Sep 2011
Posts: 925
|
Quote:
Originally Posted by 55020
I guess we should remember that this is the constructive, positive systemd thread ... even if I agree with the points being made and admire the people making them...
|
If we want to fix the problems systemd has, we at least have to name them.
|
|
|
12-01-2013, 07:29 AM
|
#135
|
Senior Member
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,912
|
Quote:
Originally Posted by jtsn
If we want to fix the problems systemd has, we at least have to name them.
|
They have been named... for about 20 years. It is why the PERT process has been in the "depreciated" mode since about 1985. It is just that Pottering is reinventing the wheel and doesn't believe what he is doing has already been done, and discarded.
|
|
|
All times are GMT -5. The time now is 11:20 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|