So why aren't you in favor of the Slackware approach?

While you are correct that such a misconfiguration is not a bug in systemd, it is a problem that is likely to arise again in the future given systemd's basic design philosophy.

With Sysvinit, if one wishes to have a daemon, it is necessary to edit /etc/inittab and then sighup init (or reboot). While doing this is straightforward for a human administrator, if upstream wants this to occur automatically upon package installation, their post-install script would need to be able to parse inittab and figure out how to insert the appropriate code without interfering with the other things happening. Again, most competent system administrators could tell at a glance what needs to be done, however, writing a program that does this is not exactly trivially (at least one that doesn't stomp on the existing setup).

Over the years, there have been alternative inits -- or proposed patches to sysvinit -- that address this by having an /etc/inittab.d directory or somesuch into which an install script could place the necessary additions to inittab, in the same vein as xinetd supplements inetd or Slackware's sysvinit-scripts can supplement the stock BSD-style init scripts.

Such a variation from traditional Sysvinit does not seem particularly troublesome, though it does increase the complexity and readability of init's configuration. Nonetheless, the fact that over the last fifteen years such a simple change hasn't seen mainstream adoption suggests that there has not been much demand for such facility (perhaps some even being adverse to it). Likewise, dedicated tools such as monit or daemontools address the same problem but have seen a similar lack of uptake.

Now with Systemd, the only effort required to change the behavior of a process so that it respawns indefinitely is for someone (upstream, packager, sysadmin) to substitute a keyword or two into the service file. Again, not in and of itself such an odious concept, but it is also undoubtedly to be expected that under such a regimen there are going to be more instances arising where someone in the pipeline makes the change without a full appreciation of the potential ramifications.

I am in favor of any approach that puts their money (or work) where their mouth is. I think that should be clear by now when you have read my posts in this thread and others about similar topics.
I appreciate your work to get runit working on Slackware, because you do something about things you are in favor of. The same is true for bartgymnast's project of systemd running on Slackware.
I am in favor of skarnet's work when he asks s6 users to tell him which features they miss in his software that is delivered by other service supervisors, so that he can work on improving it.
I am in favor of the systembsd project and I am in favor of Consolekit2, because those people do what is necessary for them.

I actually don't know what Slackware's official approach is, it looks like it is "Let's wait and see what happens".
What I can see is the approach many (not all) Slackware users seem to choose: remain ignorant about systemd, do nothing to support the status quo, but complain about systemd wherever and whenever possible. I am clearly not in favor that approach.

2 members found this post helpful.

And Heaven help you if a distribution creates a patch that fixes or changes something for a single distribution that enables or disables something triggered in the unit file.

I think Slackware has put its money where its mouth is. It's just not appreciated because it's not new enough.

@saulgoode: You are right, those issues can arise when some admins, developers or package maintainers don't know what they are doing. Nonetheless I don't see the point in blaming that on systemd, they merely offer that functionality. OpenRC offers the same functionality (I guess s6 and runit do also, I haven't studied them much), so it can be used in the wrong there also, but the duty to get this right lies entirely on the side of admins/developers/package maintainers.

Mind to provide a link to a case where such a patch is dismissed without good reason?

Get over yourself, but don't pat your own back too much, you'll dislocate a socket that way.

The atmospheric on this Slackware forum has been a bit more tense than usual.

I think you all need to relax a bit. Drink beer, wine or whatever, and don't take yourself too seriously.

Cheers!

I think the lack of visible development activity isn't helping. There hasn't been anything in slackwareland to talk about or engage with for a while. Back in the days of the sailing ships, I expect there were many more petty squabbles when they were becalmed for any length of time.

In the days of sailing ships, the officers had to keep busy the crew of a becalmed boat.

Maybe folks posting in this thread could instead occupy themselves contributing to SlackDocs?

Or other slackware related pet projects. Problem is, without the visibility of where slackware is going (and I'm talking in general, not specifically about init/systemd) no one is going to want to expend effort on something that might be invalidated by future changes. All my pet projects are on hold until we get to RC, or at the very earliest BETA.

But, you're certainly right: there are far more productive things to do than take part in this thread.

So I give you KDE 5 for Slackware-current today, something to sink your teeth into: http://alien.slackbook.org/blog/kde-...kware-current/

Eric

9 members found this post helpful.

When one exists I'll make sure to send you the memo. That's not the point though. The point is trying to give a generalized startup proceedure to something that is meant to be controlled by the distribution rather than upstream is not the best approach. Who knows better how to handle the startup of the system? Upstream or the Distribution maintainer(s)?

This is why parallelization of startup doesn't always work and why it takes more efforts to maintain parallel startup and dependency chains in startups. Plus, not every distribution is going to need or have equivalent software betwixt and between to accomplish this.

Even I was forced to admit Runit wouldn't be the best approach. As much as the benefits of a new init system would help any distribution, including Slackware on some level, I was forced to admit that the task of getting services up and running using parallelization is a daunting task in and of itself.

S6's approach is no different or better and has many of the same problems. Laurent's init and service supervision suite is very powerful and you can do a lot with it, and even use execline to handle fifos and other things, the problem of s6 is staggering. There is no generalized init script set that just simply works with any distribution, meaning if Patrick ever imported it, or anyone for that matter, you'd have to write the stage scripts from the ground up to handle the tasks of booting the system, starting it up, shutting it down, and you'd need at least several tools from s6-portable-utils and s6-linux-utils to gain the most out of the system. Even then, you still need to work out the details of dependency trees within the run and finish scripts for the services, work out the logging, and figure out how to best approach the issue of runlevels which are non-existant in these types of service supervision suites.

It doesn't matter if it's systemd, s6, runit, monit, init-ng, god, sysvinit+perp, or any init system trying to approach the problems of sysvinit and startups. The problem of init isn't within upstream or the init system. It lays squarely on the distribution which is responsible for maintaining its init scripts, and there's no excuse for poorly written service scripts for any init system, nor the willingness to "pass the buck" off to a scapegoat such as upstream or the developers of packages. The only reason launchd works for Apple is not just because they created it, but they are the distribution as well. The same goes with Solaris and SMF.

Upstream is trying to solve the problems on their end, but the problem still resides with the distribution.

And as stated, until shutting down the system properly can be addressed on any system to where you have 100% successful shut downs where the root file system isn't left dangling with a service still in the execution phases, you're going to have problems and moreso in systemd because a corrupted log from an improper shutdown damages the journal causing further problems.

In a nutshell, service supervision is nice, but there are still far too many flaws to have the proper benefits of service supervision over the standard design frameworks.

Will service supervision ever bring enough promise to be of use to UNIX? I don't know. Until distributions are willing to invest the time and effort into init systems and write effective scripts for handling the system and services, no init system is ever going to be the red pill that suddenly wakes everything up and automagically when there is too much reliance on outside interests.

Alien_Bob, thanks for the packages for KDE 5.2
I will sink my teeth into it.

I see gstreamer1 and wayland as new deps, I will look into those closely.

for those that wonder systemd and gnome3.14 with systemd for Slackware development is at https://github.com/Dlackware
How is the support on python3 going within kde application ?

Nice, I appreciate it when claims are backed up by facts, waiting for that.I don't quite get where systemd does not allow distributions to customize system startup as they see fit.
If a distribution does not want or need to run systemd or wants to use it without having to use all of its components, then so be it. Nobody is forcing them to use systemd and nobody is forcing them to use the optional components if they don't want to. While I use systemd-networkd for setting up the network on my systems I am free to use any other software that is available to do the same job. If I can do it I am quite sure that distro developers can do so also.
The point is, though, software doesn't maintain itself. If a distribution decides to not use systemd or some of its components then the alternatives that are used have to be maintained. Some developers have realized that and have started to work on compatible alternatives (systembsd), make changes as they would like to have it (eudev) or mainatin the status quo and improve on it, when necessary and possible (Consolekit2), while other developers (and users) just fled into complaining.
This is what I criticize.Of course introducing a new init system to an existing distro is a task that doesn't come for free, work will always be required for implementation and testing. Nobody denies that. But in the long run it can save a lot of work, not only for distribution developers, but also for upstream developers. For example, with traditional init every daemon that wants to run as unprivileged user but needs at start root privileges (for example to open sockets) has to implement the part where it switches to the unprivileged user themselves. This ends in a lot of duplicated code with all the implications (like security problems, time that is needed to maintain that code that possibly is better spent elsewhere, ...), while systemd (and possibly other service supervisors) can handle this functionality at a central point, which not only decreases general time for development and maintenance, but also eases up security reviews.
There is a reason why so many distribution have switched to systemd or provide it as an option and that reason is not that they are bored and need something to work on, the reason is that the work they have to do in the short run will benefit them in the long run.

But we have discussed these points over and over again and time may indeed be better spend with testing Alien Bob's work on KDE instead.