What If .........Slack needs Systemd (Slackbuilds)
SlackwareThis 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.
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.
While most software is created to make things work, other software specifically is created to break things that work. The latter is called malware.
hear, hear!!
Quote:
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.
Not significantly - the major difference is in how a process is started. Linux uses a fork, followed by an exec. Windows uses the VMS approach which does both in one system call. It also makes it easier for the "parent" to know how far along the child process has gotten, and for more information than a simple exit code to be returned.
Quote:
So Fedora is broken. And a lot of Linux distributors copy them.
IMO, yes. It is definitely broken. The latest failure was that MariaDB wouldn't start properly when being started by systemd at boot (it just exited), yet it would start properly when manually started later. Did they fix systemd? Nope. butchered (my opinion) MariaDB. Likely the same "xxx wait-online" problem. (reference: http://forums.fedoraforum.org/showthread.php?t=295518)
This just papers over the problem, it doesn't fix inherent design flaw.
Last edited by jpollard; 12-01-2013 at 07:41 AM.
Reason: forgot the reference...
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...
Indeed, let's get back on topic. Systemd has its flaws, but let us discuss those in a different thread.
Distribution: slack 7.1 till latest and -current, LFS
Posts: 368
Original Poster
Rep:
This thread is ment for the persons who would like to test/play with systemd on slackware.
But instead of saying systemd sucks etc. we as slackware community are able to make sure that the problems that systemd has gets solved upstream.
Dont get me wrong, there are thing I like and dislike about systemd.
The facts are as follows:
- Red Hat is behind systemd and will use it in their RHEL versions.
- systemd is 1 of the most active open-source project at the moment.
- most software is written with redhat or ubuntu/debian systems compatibility
With the above facts in mind, its almost certain to say that systemd is here to stay.
If and when pat decides to switch to systemd, it would be good that the we have already systemd working.
- It makes it easier for PAT & CO, for transition
- We might have found/reported bugs to solve issue related with slackware & systemd.
and ofc it is so active since it has much to do to integrate itself into everything and everything into itself
also; afaik RHEL wont have systemD in the next release and RHEL people stated they have not much to do with fedora people
i like what you are doing and might change my mind on systemd some day in the distant future
just dont be like other systemd fanboys and tell facts that dont really matter (or in many cases are plain wrong, not in yours thou as far as i can tell)
(like on-demand daemon starting; when you look at it objectively it is useless)
personally i dont like its design (a layer instead of fixing things) and want to punch its creator for being a lying ass
but that is my personal opinion
about the thread:
good work bart
i learned some about systemd here that i wouldnt elsewhere
keep up the good job
This thread is ment for the persons who would like to test/play with systemd on slackware.
But instead of saying systemd sucks etc. we as slackware community are able to make sure that the problems that systemd has gets solved upstream.
Considering that the developers are ignoring significant failures even on the system it is used for, they are unlikely to accept any fixes from anyone else.
Quote:
Dont get me wrong, there are thing I like and dislike about systemd.
The facts are as follows:
- Red Hat is behind systemd and will use it in their RHEL versions.
Only if it works.
Quote:
- systemd is 1 of the most active open-source project at the moment.
arguable - but it is active only because it doesn't fundamentally work
Quote:
- most software is written with redhat or ubuntu/debian systems compatibility
false.
Most software is written for AIX, BSD, Windows, and the UNIX systems. The fact that it also runs on Linux has been because of the compatibility with the UNIX systems.
Quote:
With the above facts in mind, its almost certain to say that systemd is here to stay.
Some form of it MAY be around - but its current configuration is very buggy, unreliable, and not easily fixed - and any actual fixes defeat the purpose of systemd.
Quote:
If and when pat decides to switch to systemd, it would be good that the we have already systemd working.
- It makes it easier for PAT & CO, for transition
- We might have found/reported bugs to solve issue related with slackware & systemd.
So far, the developers have been ignoring whether it works for any system, security issues have been ignored, suggested workarounds have been ignored, and most get dismissed as "not our problem". IF it worked, it would be easy to substitute. Unfortunately, it is so intrusive into all aspects of the system that it isn't easy to use even on the system it is "designed for".
I do think it is an interesting experiment, the parallel startup would be very useful. Unfortunately the network of dependencies this particular implementation uses makes it unworkable. A number of people using it have resorted to even putting filesystem mounts into rc.local just to be able force the proper ordering of startup processes. Which mostly works... the remaining problem is that it seems rc.local gets run before the system seems to be completely ready for it, so even then some people have been putting sleeps in it to get things working.
It does seem to work in relatively simple startup environments (such as a desktop with only one network, and a single filesystem mount). It starts having trouble when things get more complex. The latest round of "fixes" has even removed swap from being mounted from the fstab file after mounting root - mounting swap got moved into the initrd. (I've wondered why, unless the processes mounting it didn't get run soon enough).
The problem that causes is that the initrd must be rebuilt if you change your swap configuration (the system crashes if you don't - it turns out that the /etc/fstab file got copied into the initrd. Right now only root and swap are mandated, previously neither were required, with root specified on the grub kernel command line - where root was easy to handle). Of course this would impact how Slackware would get booted...
Can it be coerced into working? yes - but only by defeating the purpose of systemd.
One of the nicest things with systemd is the interface to enable/disable/start/stop services. Unfortunately, that damages the web of dependencies - adding a single service causes things to be reordered in startup (mostly due to the thundering herd scheduling), and that exposes more failures in the dependency web. And in any such web, removing a service also reorders things causing yet more failures.
If RH has any sense, they will test it, and refuse to use it in its present form, just as they refused to use Gnome 3 in its form (the developers are redoing a lot of work to present a "Classic" capability).
One thing that could improve the situation a lot is to do the same type of thing Pat did with the sysVinit - The current Slackware startup is more BSD than it is SysVinit, yet the SysVinit capability is completely present - with full ordering capability. The thing in systemd isn't (services started there still seem to get out of order somehow, though it may be with things outside of the SysVinit control).
Considering that the developers are ignoring significant failures even on the system it is used for, they are unlikely to accept any fixes from anyone else.
Only if it works.
arguable - but it is active only because it doesn't fundamentally work
false.
Most software is written for AIX, BSD, Windows, and the UNIX systems. The fact that it also runs on Linux has been because of the compatibility with the UNIX systems.
Some form of it MAY be around - but its current configuration is very buggy, unreliable, and not easily fixed - and any actual fixes defeat the purpose of systemd.
So far, the developers have been ignoring whether it works for any system, security issues have been ignored, suggested workarounds have been ignored, and most get dismissed as "not our problem". IF it worked, it would be easy to substitute. Unfortunately, it is so intrusive into all aspects of the system that it isn't easy to use even on the system it is "designed for".
I do think it is an interesting experiment, the parallel startup would be very useful. Unfortunately the network of dependencies this particular implementation uses makes it unworkable. A number of people using it have resorted to even putting filesystem mounts into rc.local just to be able force the proper ordering of startup processes. Which mostly works... the remaining problem is that it seems rc.local gets run before the system seems to be completely ready for it, so even then some people have been putting sleeps in it to get things working.
It does seem to work in relatively simple startup environments (such as a desktop with only one network, and a single filesystem mount). It starts having trouble when things get more complex. The latest round of "fixes" has even removed swap from being mounted from the fstab file after mounting root - mounting swap got moved into the initrd. (I've wondered why, unless the processes mounting it didn't get run soon enough).
The problem that causes is that the initrd must be rebuilt if you change your swap configuration (the system crashes if you don't - it turns out that the /etc/fstab file got copied into the initrd. Right now only root and swap are mandated, previously neither were required, with root specified on the grub kernel command line - where root was easy to handle). Of course this would impact how Slackware would get booted...
Can it be coerced into working? yes - but only by defeating the purpose of systemd.
One of the nicest things with systemd is the interface to enable/disable/start/stop services. Unfortunately, that damages the web of dependencies - adding a single service causes things to be reordered in startup (mostly due to the thundering herd scheduling), and that exposes more failures in the dependency web. And in any such web, removing a service also reorders things causing yet more failures.
If RH has any sense, they will test it, and refuse to use it in its present form, just as they refused to use Gnome 3 in its form (the developers are redoing a lot of work to present a "Classic" capability).
One thing that could improve the situation a lot is to do the same type of thing Pat did with the sysVinit - The current Slackware startup is more BSD than it is SysVinit, yet the SysVinit capability is completely present - with full ordering capability. The thing in systemd isn't (services started there still seem to get out of order somehow, though it may be with things outside of the SysVinit control).
Being slow today, I can't understand how your glorious speech can help the OP top successfully port/build a functional SystemD under Slackware.
My bet is that you are missed the right room. There is the engineering room, but you are trying to find the lawyers room, which is next on right...
Being slow today, I can't understand how your glorious speech can help the OP top successfully port/build a functional SystemD under Slackware.
The key word is "functional". It isn't even functional now.
Porting it is relatively trivial - but to make system actually work means you have defeat the design, which makes it nearly useless. To make it reliable requires every service file (most of them anyway) to be forced into a proper ordering. Of course, that defeats the purpose. It also becomes fragile because optional services become problematical - which can be worked around... but only by creating additional control points in the dependency network that isolate the service.
Quote:
My bet is that you are missed the right room. There is the engineering room, but you are trying to find the lawyers room, which is next on right...
Don't need the lawyers room - the problem is a technical nightmare.
Not significantly - the major difference is in how a process is started. Linux uses a fork, followed by an exec. Windows uses the VMS approach which does both in one system call. It also makes it easier for the "parent" to know how far along the child process has gotten, and for more information than a simple exit code to be returned.
The Windows services framework does a little bit more than just a CreateProcessEx() and waiting the call to succeed. The first thing is that you can't have a regular executable be a "service". Services specifically have a ServiceMain() callback, which then registers another callback using RegisterServiceCtrlHandlerEx() and then calls StartServiceCtrlDispatcher(). It will then be steered by the Service Control Manager using a control connection. BTW: Windows drivers are services, too...
The main point is: Windows has a well-defined API and its services are designed specifically around it. The SCM always knows what a service is doing and how to change its state. Systemd now takes our traditional unix daemons, tries to emulate that and fails miserably, because the API isn't just there. And their "solution" to this mess is, of course, that every damn unix daemon of the last 30 years should to be redesigned for systemd, using D-Bus for "service control".
The main point is: Windows has a well-defined API and its services are designed specifically around it. The SCM always knows what a service is doing and how to change its state. Systemd now takes our traditional unix daemons, tries to emulate that and fails miserably, because the API isn't just there. And their "solution" to this mess is, of course, that every damn unix daemon of the last 30 years should to be redesigned for systemd, using D-Bus for "service control".
Yes, that's the point. Windows have a well-defined API, Linux not. Every Linux service will do it in its frakking personal way. But, if I remember right, there are talks about including D-Bus services even at kernel level, right for "service control".
We should expect a new wave of standardization on Linux World, and D-Bus will be its messenger.
Now, with all respect, I will implore my Slackware colleagues to do their frakking academic speech about how stupid is SystemD, in another thread, at their choice.
This thread is about SystemD's frakking Slackbuilds, not about academic speeches about how stupid is SystemD!
What part of this phrase you don't understand?
Last edited by Darth Vader; 12-02-2013 at 08:59 AM.
Yes, that's the point. Windows have a well-defined API, Linux not. Every Linux service will do it in its frakking personal way. But, if I remember right, there are talks about including D-Bus services even at kernel level, right for "service control".
Linux has had a VERY well defined API. One defined for far longer than Windows has ever existed. It also works EXTREMELY well. Unlike Windows. And "its ... personal way" happens to be the same for all standard services. initialize reporting any problems. detach from controlling terminal (requires a fork). Parent process takes normal exit.
Last I hear about Dbus and the kernel was that it got dropped because of all the user mode destruction it causes. Trying to turn Linux into Windows is not the way to go.
Quote:
We should expect a new wave of standardization on Linux World, and D-Bus will be its messenger.
Now, with all respect, I will implore my Slackware colleagues to do their frakking academic speech about how stupid is SystemD, in another thread, at their choice.
This thread is about SystemD's frakking Slackbuilds, not about academic speeches about how stupid is SystemD!
What part of this phrase you don't understand?
It IS about what doesn't work. Sure systemd can be put on Slackware... but with all the required changes to Slackware it won't be Slackware anymore. It might look like Fedora. And be about as stable.
You are talking about what does not work with systemd in general. That is not the topic of this thread, the topic here is: How to make systemd available for Slackware.
Technical discussions about systemd in general and philosophical discussions if it would be Slackware when running on systemd should go into a different thread, not this one.
We've, at least for now, never once actually trashed and bashed directly on Lennart and systemd in this thread. We've been pointing out the more than obvious flaws that are the main issues that will affect it's implementation on any system, including Slackware, and why at the moment, there are other alternatives that could and/or should be considered at the moment until upstream issues can be resolved, if they ever will be resolved.
The issue we're asking is now that we know the obvious problems, where do we go from here?
Do we:
A) Keep working on the Slackbuild until upstream repairs the issues?
B) Abandon the SlackBuild and search for an alternative?
C) Implement maintenance mode while searching for a viable alternative?
D) Abandon it altogether and stick with doing nothing?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
