I see no reason at all why this shouldn't be possible.

the major problem is that it and the services it starts is a complete replacement.

It can't be optional. If you use systemd, then you must also use services designed to be used with systemd. If you prefer the current system, then you must use a completely different set of services.

When you try to mix the two, things break. The system will not boot reliably, and will not shutdown reliably.

OK so lets say I oblige and ask a question in a new thread. If you have observed the other threads, they fall apart for a number of reasons. One that has been seen before is the group of people that say "OH no, not another systemd thread!". Another group will say, "Well it's already being discussed <here>" and pointing to some thread that has some supposed authority on the topic. Another group will start openly discussing systemd much as if they haven't got a chance to explain things in previous threads.

When will we finally just say, in order to solve the issue on "what if ... systemd," we need to compare and contrast, even when painful, and let the conversation just take place, or are we going to keep focusing on a narrow interpretation on what a topic is, and create threads for every question? If we had a thread for every question, we actually would start filling up this form with how much discussion has taken place already? Can't we just leave people alone, let one thread hash it out in every way, rather than deciding what's right or wrong approach to a conversation? I'll tell you what, without a "just let people be" there really is no point to even trying talk here on systemd anymore. This is why I and other people have just stopped, because the constant threat of moderating the thread into oblivion.

If you have a problem with my style of moderation feel free to discuss that with Jeremy. In the meantime, just abide to the LQ Rules:

That being said, I think this would warrant the possibility of creating a testing fork exclusively designed for systemd just to make sure anything and everything that might go wrong with cross-contamination of the init systems is avoided. At least this way any work can be done in an exclusive environment solely for systemd.

Your libpwquality SlackBuild installs Python bindings under /lib or /lib64 which seems weird to me. Any reason why you're not just using --prefix=/usr --bindir=/bin --libdir=/usr/lib${LIBDIRSUFFIX} and --with-securedir=/lib for all arch (like udev)?

Let me step in here for a second.

First of all Linuxquestions.org has always been and will always aim to be the friendly place to talk all things Linux. This takes the will to discuss things properly and cooperation, and in some cases patience and restraint. Fellow LQ members and moderators alike are, should be, responsible and committed to make LQ succeed. And as I see things peer moderation plays an important role in keeping things running smoothly. Please realize LQ moderators only step in on behalf of the LQ Community when the situation warrants it. Please remind yourself that a moderator may post in a thread both as moderator as well as regular participant. Should there be any confusion about that please ask for clarification. Next Linuxquestions.org was selected as the primary forum for your distribution so one should not only try to keep things running smoothly out of respect for Jeremy, who owns and pays for LQ and therefore sets the rules, but also out of respect for your distributions figure head(s).

Now you may be under the impression that you're bringing a game-changing argument to the table or that the discussion wasn't handled in a definitive way already. The Facts dept. tells me that right now there have been thirteen threads in this specific forum on Systemd, the first of which was started on 08-06-11, about a year before you started posting in Systemd-related threads, and the authoritative answer on System was given in both the [SOLVED] slackware and systemd and [SOLVED] systemd and Slackware's future thread. *Also please note any threads closing notes as they unfortunately shed a light on the MO a lot of forum users seem to favour.


So where does that leave you all? Note that since 2011 only two LQ members have had the guts to step up to the plate and actually try and make a difference. Since elvis4526 seems to have ceased his efforts, in which poor responses seem to have at least played some part, the only remaining one is bartgymnast.

As the OP said in his initial post:
Ergo, if ones intent is to contribute in a constructive manner to the topic on hand then this is the thread to post in.
If that is not the case then this clearly is not the thread to post in.
I can not make it any simpler than that.

Clear?

Absolutely 100% crystal clear, like a mountain spring.

I'm not saying the listed threads wasn't definitive on the current path on the matter. It certainly my own opinion I have no need to discuss this and no more threads are necessary. What I am saying that other people don't feel that way. This thread is a prime example where bart found something that he thought wasn't definitive. But research into the matter is being hampered by an insistence that narrow objective that other members questions be asked in new topics. So a moderator is feeding the creation of new threads, and has posted so several times, and certain forum members are following his lead. This only means more systemd threads are now going being created. That is way I'm suggesting to the moderators just leave it alone, especially with the moderator becoming emphatic "I can't take this anymore" type attitude.

i like to read the technical discussion here since i like technical stuff
i, like some others, don't personally like systemd on a couple levels, but still will not clutter this topic with it
the topic is getting systemd to run on slackware
ty

Getting systemd to "run" is not the problem. It most likely will run once you get binary(s)...

Getting the rest of the system to run with systemd is a bigger problem.

yes
my simple mind implies everything working properly

bdw i had a thought
cant you just make the (high part of) slackware scripts a .service that depends on the lower parts (udev and such) ?

Nope. Because those "high part" can depend on other "high parts"... and if they are not started in the proper order, they don't work. And "proper order" means that the first process must be ready to receive a request from the dependent service. The way systemd is designed, it cannot know that - so it assumes it is ready when started... which is not always true. So the only way for that to work is to modify the service to tell systemd when it is ready - then systemd can start the dependent service.

A new update will soon be comming with systemd-210

Please Note, that I will save the 208 slackbuild as it is considered stable.

209 introduces systemd.networkd and requires some other programs, like dbus and NetworkManager to be patches (a specific git commit has been made to work with systemd-209+ (or need to wait for there new version)

systemd-210 is basically 209 with bug fixes.

@bartgymnast: Thanks for your continued work on this despite so much negativity. I must admit I have not found the time to play with your SlackBuilds yet but making it easier for others to test this is something I greatly appreciate!

^^ THIS! As one who has taken part in the wailing and gnashing of teeth in threads regarding the philosophy and end-game of systemd, I have to say this is the most "rubber meets the road", useful, and interesting for longterm of them all. Keep up the good work Bartgymnast! Kudos.

the wonderful thing about OpenSource is it is open. We can see what the Dev's are doing and working on. http://comments.gmane.org/gmane.comp...md.devel/16849
struggles can be helped or thrown away by the community. Stability is the key.

After some testing with 209 and 210 I decided to wait a bit more as they are still in the process of including the online state notification of systemd-networkd.
for the kdbus implementation a newer kernel is needed, which is not available on 14.1

as soon as I have new news, I will update it here.

Hello barygymnaast, Thank you.. I had been wanting to learn this stuff for a while, I am running your slackbuilds of systemd on slackware-current x86 fine. I did it without pam, I had no love from networkmanager and switched back to inet1 and am fine. This is on a lenovo T61, I also had to blacklist mei_me as I had problems with this module on other live systemd distros I tried in the past. Keep up the great work! I even used your slim.service file and found xwmconfig was able to switch me from xfce to kde without a hitch.

Has the Linux Foundation developers even implemented kdbus yet?

Hi ReaperX7,

It depends on how you interpreter your line.

1. Q. Is the kdbus code in the kernel yet?
A. NO

2. Q. Is a Linux Foundation Developer working on the project ?
A. Yes (Greg Kroah-Hartman is 1 of the main developers of kdbus)

Thanks Bart, and yes it was Question #1 specifically.

Have you seen, if there is, a time table for it's official deployment, or is that still in speculation?

Hi All,

I just want to update everyone with the new status of the project.
I moved the project to sourceforge.

https://sourceforge.net/projects/systemd.dlackware.p/

there are 2 groups for building systemd for slackware
-min: which are minimal required packages
-all: rebuilds of existing slackware packages to convert/work with systemd

Currently I am working on having KDE work with systemd-logind

We intend to make a Gnome based on systemd and Slackbuilds

http://www.dlackware.com (work in progress)

Bart have you found any possible way to install only the init system and udev without journald or is that as minimal as it can get?

I have not tried to install it without journald.

Even without journald, you still need dbus.

As I understand it, I don't think you can do without journald. Any system logs to be generated are done by systemd - it receives the stdout/stderr and then uses dbus to log them to journald.

If you could find a way to isolate init and udev without dbus you could kill possibly kill journald off and have the only required parts.

Ummm. I've been using Fedora... and if you remove dbus, the system doesn't run...

Systemd uses dbus to communicate with udev, and from udev back to systemd. And it uses it to communicate with every other "non-forking" service such as NetworkManager for the same reason. There is no other way for these modified services to tell systemd that things are "ready".

I also think dbus is integral to the systemd ability to monitor processes, and stop/restart other processes based on the state reported (via dbus).

I think thats right, if one removes systemd as udev provider in favour of eudev, some packages may need to be recompiled with the --disable-systemd option.

Some clues: https://aur.archlinux.org/packages/d...stemd/PKGBUILD
https://aur.archlinux.org/packages/?O=0&K=nosystemd

The startup configurations will also have to be changed... as systemd would no longer know when they are ready for use (have to change them all to "forking").

And that may require "readjusting" of the network of services...

If you want eudev instead of systemd, you just reinstall the replaced/updated packages.
And look for eudev slackbuilds.

Dbus is required for systemd, that is the only real required package that systemd needs.

The rest can basically be options.

systemd is still working together with The CoreOS team, to implement kdbus directly into the kernel.
This would remove the need for dbus, and the I/O communication is shorter.

This would also make it easier to switch to and from systemd.

After months of working on this project I can give a better opinion about how well systemd is operating compared to slackware's stock init.

my v208 of systemd uptime

root@systemd-slackware:~# uptime
12:59:40 up 100 days, 1:21, 1 user, load average: 0.56, 0.51, 0.45
root@systemd-slackware:~#

A question I have asked myself is:
Is systemd required, handy, needed ?

for required I would say NO
a systemd can easily be used without systemd

for handy I would say YES
there are alot of things that makes systemd handy for server admins.
pid/child pid, display and killing/monitoring of processes
The extra feature like multi-seat sessions is pure dependable per user

for needed I would say FOR NOW NO
as it is not required, the question regarding the needed all depends on what's the gain when using it.
I have an uptime of 100 days, and reports about crashing of systemd are older than 2y.
RH released RHEL 7 and included v208 showing everyone: we think/believe systemd is stable.

I dont see any real difference in operating side, except that the bsd startup scripts will be useless and replaced by systemd.service files.
as long as there is no functionaly and features loss in other software when systemd is not used, than systemd is not needed.

So for now I am asking myself, What functionality would be a loss if we dont use systemd to make systemd needed/required for slackware
I think, that PV has that question in his mind and when he answers that questions, systemd will enter slackware.

Untill than I will keep on creating the slackbuilds for systemd.

Uptime is also not any kind of 'good sign' that systemd has done anything so great as to replace any other init system. Superb long uptimes can be found all over the place long before systemd was around.

If it weren't for being in an area that has constant blackouts to the point my UPS is just there to keep my hdd safe, I'd have uptimes far exceeding 100 days (and I actually have hit 123 once, which I thought was amazing, heh) and my load averages are like this ever since the year 2000:

So is journald.
It is not an option when those services depend on systemd. You have to recompile them (at a minimum) to be able to function without systemd.
Not unless the services will work with and without systemd without recompiling. Unfortunately, to have both means you STILL have to have the systemd libraries installed even if they function without them.
My 486 system ran for a year... until I had a power failure.
There are other ways that have been done for quite a while for those features.
Look for system hangs... on boot and shutdown.
http://forums.opensuse.org/showthrea...r-systemd-fsck
http://superuser.com/questions/76741...-during-reboot

On the second one, note the problem: hangs 1 out 10 reboots...

Still happening, still unreliable, still not fixable.

Reliability is lost with systemd.
No functionality is lost without systemd. Most of the time systemd does boot a little faster...

the 2nd one is very case specific: upgrading from v196 to v198

the problem on opensuse is a user error.

dbus would not be a requirement and will be able to operate with or without systemd. no special systemd libraries needed.
both connect to kdbus. no need to recompile.

No. The services using dbus have to have systemd to respond.

Now, having the services compiled WITHOUT systemd would remove that dependency, and remove the dependency on dbus.

Now, kdbus is a different animal... and uses a different library. But in either case, as those services are written now, they use a dbus specific library that has all the systemd communications requirements built in. I would expect anything using kdbus to also use/require those libraries as well. Though there might be some internal differences in the library itself. So any alternate init system would also have to supply an equivalent library.

At least, until a generic library is written with yet another configuration file...

But that becomes borderline with a different distribution...

On Gentoo it is no problem at all to have a fully functioning system with OpenRC and systemd installed, where you decide at boot time, using the init= kernel option, which init system to use. No recompile needed.

Thanks - that does indicate that the services have both capabilities compiled in.

On fedora that isn't true. If you try to replace systemd, you get lots of failures - and the system is unusable.

I would guess that the Fedora developers don't deem replacing the init system as something someone would do (after all, it is somewhat like systemd's "main distro"), so it may indeed be that they have stripped away or patched parts of the services to better run with systemd without looking for compatibility with other init systems.
This would indicate that it should not really be a problem for distros that want to have several init systems available. I know at least that this is possible for Gentoo and that this will be possible Debian 8/Jessie, which comes with systemd by default, but is fully capable to run with sysvinit instead.

Quite - there was a LOT of pushback about systemd not working with F14, and was rammed down the users throats at F15, though it actually almost worked (the network support broke though). SysVinit was available as an option, but those that tried it reported the results non-functional. Even in Fedora 16 things were still broken (complex networks with more than one interface didn't work at all, virtual networks for VMs failed, though simple wireless laptop connections did start working better). Even in 17/18 people were still having to disable NetworkManager to use legacy startups to get the network just usable.

Even in F20 it doesn't work reliably, but for the simple case of desktops and laptops it appears to work tolerably well. Servers are where the problems are still occurring, and still without the ability to be easily debugged, log files get corrupted on crashes...

If it's still going poorly on Fedora 20 then chances are it's usage could get heavily re-evaluated eventually and a few decisions on it's future might have to be made. I doubt if by Fedora 22~25 at least, things haven't changed, by Fedora 26~30 they very well could be in-search-of yet another init system.

I doubt Red Hat's engineers are thrilled as well at this outcome. Isn't RHEL and Fedora somewhat tied together developmentally?

I really don't see how this could have gotten so out of hand, if systemd is a major project, it should have, in theory, top quality level quality assessment and control.

It hasn't! You and jpollard are spreading FUD in your own little land where sytemd is a catastrophic failure.

You are so, so out of touch with reality. When systemd is in RHEL 7 and you say:

I honestly don't know how to respond.

You have any evidence otherwise please by all means post Frog... We'd love to know otherwise... and if not... Pipe down!

@unSpawn
thanks

my post post on this page might been misleading.
I just wanted to share my hands on experience while working on the project.
and telling you guys that you dont have to be affraid that systemd will enter slackware soon (I think)

but untill it is, I will continu with the project.
my 1st aim is to branch systemd when a new slackware comes out. (within 1 week)
and branch everytime a new slackware comes out.

so people can try and experience systemd on slackware.

and the thread here is to discuss problems in the script or things that are not working correct on slackware with my slackbuilds.