Quote:
Originally Posted by husten
(Post 4963896)
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
(Post 4964132)
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
(Post 4964560)
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.