LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Closed Thread
 
Search this Thread
Old 06-04-2013, 03:08 AM   #376
Martinus2u
Member
 
Registered: Apr 2010
Distribution: Slackware
Posts: 345

Rep: Reputation: 56

elvis, i can only admire how much time you spend to try and educate a bunch of verabally violent conceited people. I don't even share your admiration for systemd for lack of experience with it (but a boot time under 4 seconds is impressive). I just want to pat your back publicly and say don't let them get you down.
 
Old 06-04-2013, 09:17 AM   #377
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, Slackware64
Posts: 1,722

Rep: Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830
Allow that I draw a parallel from the history of Roman civilization here, since this was also part of my studies at the University of Montpellier.

The Romans were basically suspicious of everything new. If you were a marketing consultant living at the time of the Emperor Augustus, let's say somewhere in Nemausus at the Via Domitia (ten miles from where I write these lines two millenniums later), you'd be extremely circumspect about the attributes with which you'd describe a new product.

Say you want to launch a new brand of something on the market, you'd be careful to put an "OLD!!!" sticker on every package. "Old" meant reliable for the Romans, proven and well-tested. "NEW" on the contrary meant "suspicious" and "has yet to prove its worth".

Of course, this particular concept of perennity is more familiar to those who have been using Linux since the days of Tiberius and Caligula.

We few, we happy few, we band of Slackers...
 
5 members found this post helpful.
Old 06-04-2013, 09:26 AM   #378
Bazzaah
Member
 
Registered: Mar 2007
Distribution: Slackware64-current, Slackware64 14
Posts: 327

Rep: Reputation: 49
Quote:
Originally Posted by kikinovak View Post
Allow that I draw a parallel from the history of Roman civilization here, since this was also part of my studies at the University of Montpellier.

The Romans were basically suspicious of everything new. If you were a marketing consultant living at the time of the Emperor Augustus, let's say somewhere in Nemausus at the Via Domitia (ten miles from where I write these lines two millenniums later), you'd be extremely circumspect about the attributes with which you'd describe a new product.

Say you want to launch a new brand of something on the market, you'd be careful to put an "OLD!!!" sticker on every package. "Old" meant reliable for the Romans, proven and well-tested. "NEW" on the contrary meant "suspicious" and "has yet to prove its worth".

Of course, this particular concept of perennity is more familiar to those who have been using Linux since the days of Tiberius and Caligula.

We few, we happy few, we band of Slackers...
Nice leap from Rome to Shakespeare there!
 
Old 06-04-2013, 09:42 AM   #379
kikinovak
Senior Member
 
Registered: Jun 2011
Location: Montpezat (South France)
Distribution: Slackware, Slackware64
Posts: 1,722

Rep: Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830Reputation: 830
Quote:
Originally Posted by Bazzaah View Post
Nice leap from Rome to Shakespeare there!
And Lennart is an honorable man.
 
1 members found this post helpful.
Old 06-04-2013, 10:21 AM   #380
Anonymo
Member
 
Registered: Dec 2004
Location: The Woodlands, Texas
Distribution: Slackware, Archlinux, CentOS
Posts: 184

Rep: Reputation: 27
Quote:
Originally Posted by kikinovak View Post
And Lennart is an honorable man.
I can't afford to have an independent programmer monitoring me. Do you have any idea how many outside systems I've gone into? How many programs I've appropriated?
 
Old 06-04-2013, 11:01 AM   #381
JWJones
Member
 
Registered: Jun 2009
Location: Cascadia
Distribution: Slackware, LinuxBBQ, OpenBSD, Mac OSX
Posts: 723

Original Poster
Rep: Reputation: 187Reputation: 187
systemd woes, right here at LQ:

http://www.linuxquestions.org/questi...md-4175464430/
 
2 members found this post helpful.
Old 06-04-2013, 01:04 PM   #382
TracyTiger
Member
 
Registered: Apr 2011
Location: California, USA
Distribution: Slackware
Posts: 276

Rep: Reputation: 65
Quote:
Originally Posted by kikinovak View Post
Of course, this particular concept of perennity is more familiar to those who have been using Linux since the days of Tiberius and Caligula.
I've seen others reveal their experience with computers by references to punch cards, paper tape, time sharing systems and similar references. Although you weren't specifically referring to yourself, your smooth association with your place of residence, ancient Rome, and years of Linux experience deserves applause.

There is no substitute for experience. In any field it's great to have theory, science, creativity, fresh ideas, etc. but the experience of those practicing in the particular field should be carefully considered. Experience tells us what worked and what didn't.
 
3 members found this post helpful.
Old 06-04-2013, 04:58 PM   #383
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, FreeBSD 10.0
Posts: 3,400
Blog Entries: 15

Rep: Reputation: 950Reputation: 950Reputation: 950Reputation: 950Reputation: 950Reputation: 950Reputation: 950Reputation: 950
Quote:
Originally Posted by husten View Post
Just when I had sort of learned setting runlevels - here comes dumb systemd pushed down my throat by opensuse.

Mediatomb starts before ifplugd brings up the net - FAIL! AAARG!

Yes I have found the problem in the journal file, but no idea how can I fix this? Anyone out there that knows the workflow/commands? Most of the literature I googled assumes that you already are an systemd expert ('just use before='! duh!). It seems to vary between distro's too, some stuff is in /etc/systemd some in /lib/systemd what a bloody mess....

Please help!
Quote:
Originally Posted by edorig View Post
I believe you cannot fix that since systemd is designed for parallelizing your system startup. So you can't
have certainty that a daemon will start after another. Systemd expects that all messages to a daemon can
be queued and that the daemon will process them after it starts.


My solution would be to install Slackware that is still using System V Init, or Gentoo (uses OpenRC) or Debian
(uses Upstart) or one of the BSDs. But of course, what works for me (Slackware) may not be practical for you. Is there some software provided by OpenSUSE that you absolutely need ? Also, do you have a maintenance contract with
SUSE ? If so, cannot you let them fix the problem they have created ?
Quote:
Originally Posted by husten View Post
Thanks unSpawn way forward, but...

funny enough as this is a hybrid thing in opensuse, there is no service file for mediatomb:

(and probably no ifplugd service file to refer to either, in runlevels i have "network" though it is named "ifplugd"in the journalctl:

Unfortunately the blog entry you sent (isn't this guy the cause of our sleepless hours?) does not address any of these. He assumes you just know already....
Thanks edorig, but I am an amateur and not smart enough for Slackware, maybe Sabayon which I am running on my laptop - where knwoing a handfull of equo commands get you a very long way.

Please, any more details on how to create and presumably register this 2 service file(s) greatly appreciated.
As an admin, I don't even know where to begin with this...

However, this is what happens when you don't take the obvious into consideration about Parent and Child Processes. Systemd tries to put everything in parallel instead of partial parallelization where as you can batch load certain elements that start and end with a dependency resource tree.

When start up service files do not exist, starting the daemon just simply can not be done unless the proper files exist, period. In this case, MediaTomb needs ifplugd to start first as a Parent/Dependency Process. However, since both are trying to start at the same time, ifplugd is NOT already loaded and configured and therefore there is no Parent/Depenedency Process offered at load time and MediaTomb can not function.

This is where Dependencies within a structured Linear system like SysVInit completely show the fail points of systemd entirely. Processes that rely on other Parent Processes or even Dependency Processes have to be started AFTER their Parent/Dependency is started so that the resources can be setup.

Now, SysVInit can be scripted to load in Partial Parallel with Linearity concepts. This means things are loaded in a tree like fashion and structure system. And by comparison it's very efficient and I use it myself to make sure that certain processes get started at the right time within my system rather than just waiting or all at once creating a mess. Everything needed to load at boot time is loaded correctly, has it's parent/dependency loaded prior, and all the services work flawlessly.

I actually admire where Edorig suggested the usage of a SysVInit, OpenRC, and Upstart Init system is mentioned as an alternative that's viable, like Slackware, Gentoo, Debian/Ubuntu, or a BSD.

I still will argue that SysVInit and BSDInit based Init systems are completely superior to systemd in every way because they offer so much flexibility where systemd just doesn't or even can.

To me that stated clearly, other people are seeing the faults with this software, and they aren't small issues, they are major issues that were clearly, if not haphazardly or intentionally overlooked.

Quote:
Originally Posted by Systemd for admin website
Shell scripts tend to be slow, needlessly hard to read, very verbose and fragile. Although they are immensly flexible (after all, they are just code) some things are very hard to do properly with shell scripts, such as ordering parallized execution, correctly supervising processes or just configuring execution contexts in all detail. systemd provides compatibility with these shell scripts, but due to the shortcomings pointed out it is recommended to install native systemd service files for all daemons installed. Also, in contrast to SysV init scripts which have to be adjusted to the distribution systemd service files are compatible with any kind of distribution running systemd (which become more and more these days...).
1. Shell scripts aren't slow. Unless you are intentionally loading everything in linear aspects. Again, as I stated,, you can use SysVInit to load in Linear Tree Structured Parallel. And honestly, if you can't read simple English you have no business being an administrator.

2. Yes, they are flexible. They were designed to be flexible for administrative purposes and ease of use.

3. Forcing people to install systemd is not what Linux is about. Linux was about freedom and choice.

Quote:
Originally Posted by Systemd for admins
What follows is a terse guide how to take a SysV init script and translate it into a native systemd service file. Ideally, upstream projects should ship and install systemd service files in their tarballs. If you have successfully converted a SysV script according to the guidelines it might hence be a good idea to submit the file as patch to upstream.
Oh, but wait, I thought SysVInit scripts were compatible with systemd and didn't need conversion to service files. Now we have to convert them,, and submit them as patches to expand systemd even more even if we aren't using that service in our system?

Quote:
Originally Posted by Systemd for admins
The first step when converting such a script is to read it (surprise surprise!) and distill the useful information from the usually pretty long script. In almost all cases the script consists of mostly boilerplate code that is identical or at least very similar in all init scripts, and usually copied and pasted from one to the other. So, let's extract the interesting information from the script linked above:

A description string for the service is "Daemon to detect crashing apps". As it turns out, the header comments include a redundant number of description strings, some of them describing less the actual service but the init script to start it. systemd services include a description too, and it should describe the service and not the service file.
The LSB header[1] contains dependency information. systemd due to its design around socket-based activation usually needs no (or very little) manually configured dependencies. (For details regarding socket activation see the original announcement blog post.) In this case the dependency on $syslog (which encodes that abrtd requires a syslog daemon), is the only valuable information. While the header lists another dependency ($local_fs) this one is redundant with systemd as normal system services are always started with all local file systems available.
The LSB header suggests that this service should be started in runlevels 3 (multi-user) and 5 (graphical).
The daemon binary is /usr/sbin/abrtd

And that's already it. The entire remaining content of this 115-line shell script is simply boilerplate or otherwise redundant code: code that deals with synchronizing and serializing startup (i.e. the code regarding lock files) or that outputs status messages (i.e. the code calling echo), or simply parsing of the verbs (i.e. the big case block).
So wait... LSB headers and licensing and other important distribution information is now pointless babble in the script? So, systemd now wants me to violate a distributor's license or wishes by erasing their intentional distributed documentation in the Init file, as well as important explanations of switches and such? Pardon me, but if the original developer states that his license can not be altered in any way... and you alter it, you are breaking the terms of the license and usage agreement.

Last edited by ReaperX7; 06-04-2013 at 05:15 PM.
 
1 members found this post helpful.
Old 06-04-2013, 06:30 PM   #384
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by ReaperX7 View Post
Oh, but wait, I thought SysVInit scripts were compatible with systemd and didn't need conversion to service files. Now we have to convert them,, and submit them as patches to expand systemd even more even if we aren't using that service in our system?
When someone says: Here is a guide to do that, if you want that doesn't mean that it is mandatory. That one user has problems with Mediatomb can be caused by systemd, but it doesn't have to. It can also be caused by Mediatomb's init-script:
Quote:
LSB header dependency information matters. The SysV implementations on many distributions did not use the dependency information encoded in LSB init script headers, or used them only in very limited ways. Due to that they are often incorrect or incomplete. systemd however fully interprets these headers and follows them closely at runtime (and not at installation time like some implementations).
http://www.freedesktop.org/wiki/Soft...mpatibilities/
Before simply blaming systemd here one should check the Mediatomb script if it has correct dependency information. Because systemd does not try to start anything in parallel, it first assembles a dependency tree and starts the services in the correct order, if necessary. From the same page you lnked to:
Quote:
However, if both are started (and usually they are) then the order in which they are is controlled with this dependency.
So they clearly are not started in parallel.

Quote:
So wait... LSB headers and licensing and other important distribution information is now pointless babble in the script? So, systemd now wants me to violate a distributor's license or wishes by erasing their intentional distributed documentation in the Init file, as well as important explanations of switches and such? Pardon me, but if the original developer states that his license can not be altered in any way... and you alter it, you are breaking the terms of the license and usage agreement.
I can't follow your reasoning at all here. If all you need from the LSB headers is the dependency information, information that you surely can get from other documentation, too, then you use no code at all from the script and the license information for that script is simply irrelevant. You can't break a license from code that you are not using.

You don't have to like systemd, but at least be fair, otherwise it takes the weight out of your argumentation.
 
5 members found this post helpful.
Old 06-04-2013, 07:41 PM   #385
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,263

Rep: Reputation: 648Reputation: 648Reputation: 648Reputation: 648Reputation: 648Reputation: 648
Quote:
Originally Posted by ReaperX7 View Post
This is where Dependencies within a structured Linear system like SysVInit completely show the fail points of systemd entirely. Processes that rely on other Parent Processes or even Dependency Processes have to be started AFTER their Parent/Dependency is started so that the resources can be setup.
With a Slackware-style SysV init you still need to place the start stanza in the appropriate place, which means knowing the program's dependencies anyway. You can explicitly state dependencies in systemd which has the same effect. This is six of one, a half dozen of the other.
Quote:
Originally Posted by ReaperX7 View Post
I still will argue that SysVInit and BSDInit based Init systems are completely superior to systemd in every way because they offer so much flexibility where systemd just doesn't or even can.
If you want a process to restart if it dies, you need to add a wrapper daemon in the start script to restart it. This is definitely a waste of resources because either an additional binary daemon is needed for each restartable service or that shell must stay open to monitor the exit status, both of which are taking up resources for *each* service. systemd solves this by monitoring (designated?) processes itself, saving resources. Thus, SysV is most definitely not superior to systemd in *every* way. (And as stated before, I am not a fan of systemd)
Quote:
Originally Posted by ReaperX7 View Post
1. Shell scripts aren't slow. Unless you are intentionally loading everything in linear aspects. Again, as I stated,, you can use SysVInit to load in Linear Tree Structured Parallel. And honestly, if you can't read simple English you have no business being an administrator.
I hate to burst your bubble but shell scripts are slow. This is why Debian used dash for years instead of bash -- it saved a ton of time because the shell was more resource-friendly. systemd is even more resource-friendly in this aspect. (Note that I am still pro-shell scripts in the init system because of the additional transparency and simplicity associated with them, but your speed argument is ridiculous)
Quote:
Originally Posted by ReaperX7 View Post
3. Forcing people to install systemd is not what Linux is about. Linux was about freedom and choice.
Is Linux about choice?
Quote:
Originally Posted by ReaperX7 View Post
Oh, but wait, I thought SysVInit scripts were compatible with systemd and didn't need conversion to service files. Now we have to convert them,, and submit them as patches to expand systemd even more even if we aren't using that service in our system?
They are compatible. If you want to use systemd as intended, you should convert the scripts, and that page explained how. It didn't say you *had* to. You intentionally bent the truth to make a point.
Quote:
Originally Posted by ReaperX7 View Post
So wait... LSB headers and licensing and other important distribution information is now pointless babble in the script? So, systemd now wants me to violate a distributor's license or wishes by erasing their intentional distributed documentation in the Init file, as well as important explanations of switches and such? Pardon me, but if the original developer states that his license can not be altered in any way... and you alter it, you are breaking the terms of the license and usage agreement.
LSB headers have nothing to do with licensing. I have no idea where you got that. The license agreement doesn't state that you need to ship their init script (and if it did, any LSB-compliant software included with Slackware would certainly be shipping illegally, since Slackware's BSD-style scripts are often written by hand rather than included from upstream).

Right now Slackware (and people at slackbuilds.org) have to manually write init scripts because most (not all) upstream projects write init scripts only for SysV-style SysV init systems as opposed to Slackware's unique BSD-style SysV init. And, of course, different distros have different policies with their init scripts, so there is variation there too. At least with systemd the upstream developers can just ship one policy file that should work across multiple distros regardless of their policies.

Again, I am in no way in favour of systemd, but there has been more FUD than fact in this thread.
 
5 members found this post helpful.
Old 06-04-2013, 08:27 PM   #386
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware
Posts: 193
Blog Entries: 13

Rep: Reputation: 113Reputation: 113
Quote:
Originally Posted by T3slider View Post
Right now Slackware (and people at slackbuilds.org) have to manually write init scripts because most (not all) upstream projects write init scripts only for SysV-style SysV init systems as opposed to Slackware's unique BSD-style SysV init.
This is wrong. Slackware added support for SysV-style init scripts many years ago. Applications which install SysV-style init scripts will have their scripts invoked at the expected runlevel transitions.
 
Old 06-04-2013, 08:45 PM   #387
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,768

Rep: Reputation: 204Reputation: 204Reputation: 204
Quote:
Originally Posted by ttk View Post
Slackware added support for SysV-style init scripts many years ago. Applications which install SysV-style init scripts will have their scripts invoked at the expected runlevel transitions.
What he said. Have a look under /etc/rc.d. What do you think all those rc.* directories are for?

This is what I use whenever I create a package which uses an init script. It is much easier and neater than adding 'start stanza' entries to rc.local, and allows for complete "without-a-trace" package removal.

The only requirement is that /etc/rc.d/rc.sysvinit is executable. You can disable it on installation, but I never do.
 
Old 06-04-2013, 08:46 PM   #388
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,263

Rep: Reputation: 648Reputation: 648Reputation: 648Reputation: 648Reputation: 648Reputation: 648
Quote:
Originally Posted by ttk View Post
This is wrong. Slackware added support for SysV-style init scripts many years ago. Applications which install SysV-style init scripts will have their scripts invoked at the expected runlevel transitions.
No default Slackware package uses SysV-style init scripts and I don't know of any SBo packages that do. To ship such a package would be considered poor form. Slackware's support for SysV-style init scripts is a little-used technicality and is more meant for compatibility with non-Slackware packages than to be used by default. I would not appreciate having to manage two different init script systems at all, and thus, what I said stands.
 
2 members found this post helpful.
Old 06-04-2013, 08:50 PM   #389
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware
Posts: 193
Blog Entries: 13

Rep: Reputation: 113Reputation: 113
That is so blatantly disingenuous that there is no need to write a rebuttal. Anyone worth convincing will be convinced by the obvious contradiction between your two most recent posts.
 
Old 06-04-2013, 08:54 PM   #390
rkelsen
Senior Member
 
Registered: Sep 2004
Distribution: slackware
Posts: 1,768

Rep: Reputation: 204Reputation: 204Reputation: 204
Quote:
Originally Posted by T3slider View Post
To ship such a package would be considered poor form.
Never used Dropline Gnome? They extensively leverage Slackware's SysV capabilities, because it is easier and yields a cleaner result. It means that they don't have to mess with any of the default scripts and that when the user decides to uninstall Dropline, their system will be restored to a pristine state.
Quote:
Originally Posted by T3slider View Post
Slackware's support for SysV-style init scripts is a little-used technicality and is more meant for compatibility with non-Slackware packages than to be used by default.
Quote:
Originally Posted by T3slider View Post
I would not appreciate having to manage two different init script systems at all, and thus, what I said stands.
It is pretty clear that you haven't used this.

What you said is patently wrong. SysV init is fully supported in a default installation of Slackware.

You can't say that it doesn't work merely because it offends your principles...

Pat's implementation of SysVinit is nothing short of genius. I highly recommend that you at least look at it. As an exercise, download one of the Dropline packages and see how they use it. You don't have to install the package... Just pull it apart and see how it works.

Last edited by rkelsen; 06-04-2013 at 09:08 PM.
 
  


Closed Thread

Tags
cgroups


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


Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Slackware: Is Systemd Inevitable? LXer Syndicated Linux News 5 07-22-2013 04:54 AM
[SOLVED] slackware and systemd fl0 Slackware 512 08-29-2012 11:07 AM
slackware and systemd (OT) eloi Slackware 44 08-24-2012 04:36 PM
[SOLVED] systemd and Slackware's future kikinovak Slackware 95 07-14-2012 11:40 AM
Boot Delay 30min: systemd-analyze blame systemd-tmpfiles-setup.service BGHolmes Fedora 0 07-27-2011 09:02 AM


All times are GMT -5. The time now is 09:35 PM.

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