LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 02-13-2014, 12:27 PM   #286
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 659

Rep: Reputation: 138Reputation: 138

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.

Last edited by Darth Vader; 02-13-2014 at 01:02 PM.
 
Old 02-13-2014, 04:45 PM   #287
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,336

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
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:
Code:
systemd                        service daemon
 fork                           exec service (-nodaemon)

    add to monitor list         child initializes.

                                sends ready message via dbus.

 goes to next entry in          enters wait loop for requests
 dependency list
The normal manner:
Code:
 init (at run level)            startup script         service init             service daemon
    reads directory list
    sorts by name
    fork shell                  shell script runs

                                forks service daemon
                                                       initializes

                                                       forks daemon process
                                                       exits                    daemon enters
                                reports any errors                              wait loop for
                                exits                                           requests
 goes to next script in
 list
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.

Last edited by jpollard; 02-13-2014 at 04:46 PM. Reason: missed a code frame
 
Old 02-13-2014, 05:17 PM   #288
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,836
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
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.

Last edited by ReaperX7; 02-13-2014 at 05:21 PM.
 
Old 02-13-2014, 05:45 PM   #289
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,336

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
Quote:
Originally Posted by ReaperX7 View Post
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.
 
Old 02-13-2014, 06:02 PM   #290
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 272

Original Poster
Rep: Reputation: 93
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

Last edited by bartgymnast; 02-13-2014 at 06:05 PM.
 
Old 02-13-2014, 06:52 PM   #291
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,336

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
Quote:
Originally Posted by bartgymnast View Post
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.
 
Old 02-13-2014, 09:43 PM   #292
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,836
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
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?
 
Old 02-13-2014, 10:54 PM   #293
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,336

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
Quote:
Originally Posted by ReaperX7 View Post
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.
Old 02-14-2014, 03:08 AM   #294
bartgymnast
Member
 
Registered: Feb 2003
Location: Lelystad, Netherlands
Distribution: slack 7.1 till latest and -current, LFS
Posts: 272

Original Poster
Rep: Reputation: 93
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

Last edited by bartgymnast; 02-14-2014 at 03:12 AM.
 
Old 02-14-2014, 03:26 AM   #295
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,836
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
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.

Last edited by ReaperX7; 02-14-2014 at 03:28 AM.
 
1 members found this post helpful.
Old 02-14-2014, 09:26 AM   #296
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 2,336

Rep: Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594Reputation: 594
And repeat when adding one new service...
 
Old 02-14-2014, 10:19 AM   #297
the3dfxdude
Member
 
Registered: May 2007
Posts: 332

Rep: Reputation: 100Reputation: 100
Quote:
Not to make a comparison and venture into a sub topic
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.
Old 02-14-2014, 11:11 AM   #298
hpfeil
Member
 
Registered: Nov 2010
Location: Tucson, Arizona US
Distribution: Slackware Current, custom kernel, amd64, Beyond LinuxFromScratch
Posts: 130
Blog Entries: 1

Rep: Reputation: Disabled
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.
Old 02-14-2014, 11:21 AM   #299
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,653
Blog Entries: 2

Rep: Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095
Quote:
Originally Posted by the3dfxdude View Post
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.
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.
Old 02-14-2014, 02:56 PM   #300
ReaperX7
Senior Member
 
Registered: Jul 2011
Location: California
Distribution: LFS-7.6, Slackware 14.1, FreeBSD 10.1
Posts: 3,836
Blog Entries: 15

Rep: Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188Reputation: 1188
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.
  


Reply


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



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

Main Menu
Advertisement
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