How about to write a little program, capable to watch the initialization of a Slackware-like service and to communicate with SystemD via DBUS, when everything is ready?

There is Mancha, Jason Woodward (JAOS), also even I, I known C/C++ and I'm not at first written app, so Slackware have some programmers to do the job...

But, to write this program, first, we need to known its workflow. How it react to events.

I think systemd has to use the process exit for monitoring purposes. The problem with that and scripts of course, is getting the pid back to systemd to add to its list... I think that would require another modification to systemd.

The way I understand systemd:
The normal manner:
Systemd is attempting to eliminate the middle two steps by:
1) doing what the script does now
2) force the service to tell systemd when it is ready.

The simple case is where the service exits (it has completed intialization and started handling service requests). The exit is the signal that it has started (normal exit) or failed (anything else).

The problem for systemd is that it MUST know what the service daemon process is. Unfortunately for it, that is impossible when the current fork/setsid is done to become a daemon. That is why the service HAS to be modified so that systemd can perform the monitoring.

One shot startup of a service will work. But that isn't what systemd is designed to do. It must monitor each service so that it knows when it can start any other service that depends on the one being started.

It will work for those services that have no depending service. But those are rather rare.

The way I'm reading that is systemd eliminated the need for shell scripts so it doesn't have to operate actually within the shell, but in it's own subsystem. Basically if that's right... there is no more administrator level control of individual service daemons without systemd, so the shell is not required, and you have to use systemd's service control interface.

Yes. And the service daemons have to be modified so that it would work. The loss of control HAS to be made up somewhere. And that somewhere is in the source code for the service. Which is also what makes it incompatible with other init systems.

network problem solved by NetworkManager

systemctl enable enable NetworkManager-wait-online.service

so programs that needs to wait for the network to be up, can be started after NetworkManager-wait-online

this has been already fixed in beginning of 2013

yes - it just demonstrates one of the shortcomings of systemd. The requirement to change the service daemons for systemd, making them incompatible with other init services.

How many daemons within Slackware would have to be modified to work with systemd without presenting a problem for the inclusion of systemd towards it's interface?

Hard to tell...

All the database servers.
All the network servers (ldap, NIS, Apache, kerberos, named, portmap/rpcbind... firewall setup, and just basic network setup. dhcpd is going to be a hard one...the network filesystem servers, time servers...)

Not sure about iscsi (I haven't used that one), or sshd.

And there is the fibre channel setup and filesystem discovery/mounting... And what happens with fibre channel over ethernet...

Logic would say "all of them", one reason for that is that there can be a ton of unknown dependencies that are trivially handled/implied by rc.?? run level handling. Using the Snn/Knn
sequence allows the scripts to be sorted, so any service with a higher number has an implied dependency on the lower numbered one.

Even in Fedora 20 they are still finding new things that don't work right... and what is worse, just adding a new service could cause another unknown dependency to crop up. (the thundering herd scheduling reordering things).

Another problem is that the dependency network changes as some services are optional. But adding an optional one can cause a service to gain a dependency. Consider the dependencies for NFS servers. It depends on the network. The network could depend on dhcp... But NFS mounts might have a dedicated wired network use, so they don't depend on DCHCP... but if DHCP is used to configure that network then it does... And all could depend on network naming (DHCP may depend on external naming... or not; as it depends on the dhclient configuration).

Adding the network time servers introduces additional service dependency. Normally nothing requires that service... But if it is added, then suddenly network services like kerberos, NFS, gluster now need to be delayed until after it is started... or they could get inconsistent time operations (kerberos connections fail if the clock happens to be wrong...and starting the kerberos servers before the time has been stabilized/set can cause remote failures. NFS could get inconsistent file dates during boot.

This kind of thing is trivially handled by sysVinit... systemd uses the "Before=" nomenclature to try and handle it. But knowing all the possible "befores" is impossible. Any local service added would require going through ALL the existing services to decide if the existing service also has to be "Before" the new one. Just as knowing all the "after" list for that service. It is only "after" an optional service if that option is used.

The original technique was explored in the 50s through the 80s as "critical path analysis" (CPM and PERT). The technique is very useful for small projects... but editing the network NOT trivial - the time it takes grows roughly N^2 where N is the number of nodes. Systemd attempts to reduce the time by using fake node points, so that only a subset of the entire network is analyzed (this is the network of "target" nodes). within targets there is a more limited number of nodes (usually fixed) that can be easily checked. Unfortunately, adding these nodes also reduces the efficiency of the result. The schedule is better, but not optimum.

This is workable for small static networks. And I count single user workstations as small. Large servers on the other hand... or in clusters... not small. Not static either...

The other problem is that if a daemon is modified to work with systemd, it will not work without it. The services would get dbus errors at a minimum... It likely could be worked around - but would end up with two completely different startups - the normal one AND one for systemd... And it would still require all the systemd/dbus libraries to run even if the system used the traditional init startup (the bloat caused by systemd).

I grant that the concept of reducing the number of forks is reasonable... I even (sort of) understand the added bloat for the interface. I'm just not sure it is worth throwing out all the compatibility with other systems (AIX, Solaris, HP, Mac, BSD, hurd, ...), and the loss of administrator control.

3 members found this post helpful.

if you follow the gits on systemd, the network problem will be solved within systemd itself.
there is a small catch to this.

It is called systemd-networkd

And administrator control is not just a key structural point of Linux... It's the key structural point of all known operating systems for proper administration.

Not to make a comparison and venture into a sub topic, but isn't systemd treating the GNU OS as nothing more than a virtual machine with systemd as the hypervisor? This reminds me exactly of a Playstation 3's OS design and without control of the hypervisor, there is no real control of the system and you're locked in a sort of user mode regardless of privileges.

Anyway so basically, we'd have to more or less start from rc.M at least creating from scratch service files in Before and After sequences until we get to the ends of those batches where services that don't have dependencies start a new batch set then Test, restructure, and redraft until correct?

They added another whole sub-service just to solve one problem? The problem was forcing parallel loading and aggressive handling of services.

1 members found this post helpful.

And repeat when adding one new service...

Make comparisons all you need Reaper. We can talk about getting it to building, running systemd, but that doesn't solve the overall question on replacing an existing init service, or everything else systemd now replaces. Remeber, we are not starting over here, on a completely new OS. Many people are invested in things working well. In order to do that, we must make comparisons, otherwise, the review is not complete, and potentially botched.

I frequently review software at work. We sometimes get bad management in that says, use this in place of existing software. When we start showing comparisons, and they throw out valid comparisons and silencing us in the report, they have an agenda. It comes out later, that stuff breaks, and the managers get fired. (I have seen this happen several times!) We find out sometimes they were buddies with the vendor, and basically getting kick-backs. I'm not saying that is the agenda here, but the constant bombardment of the thought-police which is practically censorship is still an agenda (it's even showing up in other threads!). I do not agree with them. I do not know much about these init services, and I don't always agree with you, but you are showing analytical thinking that is required on a proper evaluation.

If you are thinking my reply is off-topic, it is not. I want a good outcome for systemd, but makes threats to people like Reaper, for making valid comparisons is only botching feedback from the community, and leaving people on edge, in fear. We can't even ask questions on systemd anymore, like WHY, without being accused.

2 members found this post helpful.

http://ewontfix.com/14/
https://bugzilla.redhat.com/show_bug.cgi?id=1043212
http://www.phoronix.com/forums/showt...l-With-Systemd
http://www.phoronix.com/scan.php?pag...tem&px=MTYwMzg

[I ain't sayin', I'm just sayin'.]

1 members found this post helpful.

You can ask questions about systemd, its design and whatever all day long, if you want, but the topic of this thread is not systemd in general, it is about bartgymnast's efforts to get it running properly on Slackware. Ask your questions in a different thread, nobody will hinder you.

2 members found this post helpful.

Maybe that's the $64,000 question Tobi.

When this is all said and done, can we get systemd properly integrated into Slackware, get the Slackware management tools rebuilt to support systemd, and maybe get working correctly?

1 members found this post helpful.