It is, on the most part, not needed. It eventually gained some capabilities which genuinely help GNOME developers with some security problems intrinsic to using Linux as a desktop, but otherwise it replaces known-good old components with dubious new ones.

The picture also gets muddled because of claims that systemd facilitates things which sysvinit does not, when it really does -- like killing all subprocesses of a process. From what I've seen, the people making such claims genuinely believe what they are saying, but do not know sysvinit well enough to realize sysvinit can do (or facilitates scripts to do) what systemd does.

Yes. The ways they claim systemd is "better" for servers are actually worse. For instance, not starting a service until the first request is made will mask problems that service might have (think erroneously edited httpd.conf), which you really want revealed as early as possible -- say, at boot time, when the administrators are watching the machine for problems anyway (or should be).

The sysvinit and inittab approach to monitoring/restarting services does have some genuine shortcomings, which IT professionals are still getting a handle on, but imo the chef/puppet approach is more effective and flexible than systemd's hard-coded behavior.

Some simply don't care, some are GNOME-oriented and thus constrained by GNOME's dependency on systemd, and some are reverting from systemd. I keep some relevant notes here: http://ciar.org/ttk/public/systemd.html

Not just Slackware, no. Three major distributions have refrained (Android, Slackware, Gentoo) and several minor ones as well. These are enumerated here http://forums.debian.net/viewtopic.php?f=3&t=118319 and here http://without-systemd.org/wiki/index.php/Main_Page

This adds insult to injury, yes. The systemd folks have been evangelical in their advocacy, and quite tactical in subsuming systems (like udev) which most Linux distributions depend upon. They have been stymied, to a degree, by their failure to get device driver developers moved over from the traditional netlink API to the systemd-specific API. Had these developers been more co-operative, it would be game over.

I've heard the conspiracy theories, but imo none of them hold water. I think we're just seeing people aggressively pushing their favorite project.

Regarding the GNOME systemd dependency, this is relevant and could help facilitate migrating GNOME-oriented distributions off systemd:

http://ostatic.com/blog/hpe-donates-...e-sans-systemd

1 members found this post helpful.

I wrote the below in another thread on systemd, but from my understanding, the reasoning had nothing to do with getting a faster boot, that was just the biggest "benefit" that people spoke about, even though it is just a side-effect of parallelization. There is a large list of things that systemd provides that isn't provided with Slackware's stock init system. I wrote this as a response to someone asking the benefits of systemd. I included my personal belief on whether that particular feature might be beneficial.

Overall, you're right, systemd is not needed... but it does provide several features that many distro maintainers have felt are important enough that makes it worth it to add systemd to their distro. In general, a lot of times new software isn't needed, but that doesn't mean that it doesn't contain stuff that's wanted. However, so far, I'm glad that Pat hasn't wanted systemd and that it hasn't been forced by other dependencies yet.

Sorry for the wall of text below

2 members found this post helpful.

Even upstart boot starts services in parallel with its event based model, its not half bad.

I use gnome classic desktop , am on ubuntu 14.04 and there is NO systemd here , everything has been fine for a long time.
It does work without systemd pretty decently. I find it highly irresponsible for distros to not care about users.

Also if systemd is good for servers, they shouldnt be including it in desktop version of distros(ubuntu for eg.)

logging - it still loses data. What is NOT mentioned is that what was done was to make the log buffer bigger. The only way to ensure that you capture the very early logs is to not use an initrd.

unit files - no gain. They are not generic. And if you have to have generic, you STILL end up writing shell scripts.

dependencies - no gain. Having a dependency graph makes it next to impossible to add a service without completely destroying the net. This was learned back in the 1970s with PERT graphs (which are a dependency graph). The other problem with them is that there isn't just one dependency graph, but several.

parallelization - same topic as dependencies. Having it is nice - but being able to CORRECTLY set them up is mandatory. And that is not possible to do except in the simple cases.

cgroups were handled before systemd. Shutting processes down arbitrarily is wrong. PIDS are still used - just not necessarily pid 1 (see prctl system call).

Addtitional core elements - and make the entire system fall to a small bug in one. This is overly complex and ties too many independent functions into one failure prone result. It also eliminates the possiblity to substitute other elements with other capabilities.

7 members found this post helpful.

I doubt any log is foolproof in retaining all data. However, where did you find that you can't capture early logs via initrd? That was mentioned in a lot of sources when I was looking up that information previously. Personally, I don't like the idea of binary logs. They are far too easy to corrupt and I don't like requiring a special viewer to read them.

Sure, there'll probably be difficult unit files. GazL posted a link to a story about getting the unit file for nfs to cover more obscure cases, which seemed quite complicated... but the work they did ended up covering pretty much any use case, where rc. scripts would need to be custom-tailored for certain situations. Overall, it's not necessarily bad to edit an rc. script to handle a specific case, but having it work without editing is even better.

However, for a basic service, it seems like writing a unit file is much easier than writing an rc. file. I've written several rc. files, and the declarative statements of unit files seem quite simple and straightforward (however, I haven't used/created them in practice, so take that with a grain of salt). Personally, I feel I have more control over an rc. script, but that is probably because I'm not familiar with unit files. After reading through that article, it seems systemd's unit files have the potential to cover extremely complicated situations.

How can you say there is no gain? Yes, it can end up being extremely complicated, but that doesn't negate the benefits it provides when everything syncs. Knowing you have a service which relies on NFS being up and running and being able to tell the system to wait until it is can be quite beneficial. It is much better than adding some sleep commands to your init scripts and hoping NFS finishes coming up before the call to start your service, or adding a delay with an until statement waiting for NFS to become active enough to start your service.

It isn't possible to do, yet many init systems offer parallelization? You can get some degree of parallelization with Slackware's init by backgrounding processes, but without having dependency information, you could run into failures during the boot process. I'm not saying it isn't complicated to pull off properly, but many distros are obviously doing it, so it can't be "not possible". However, slightly faster boot times (theoretically... some have documented the same boot times or even longer than whatever previous init they were using) are an insignificant benefit in the overall scheme of things (especially when you don't need to start your system frequently), but it is still a "nice to have".

cgroups isn't just to shut down processes, but it also allows you to track what created what and allow the system to monitor child processes even after the parent process has ended. It also allows you to limit resources to certain cgroups (so you could theoretically create one for Chrome and prevent it's ever expanding memory from taking 90% of your RAM). And I know cgroups were handled before systemd, but as I said, Slackware's init does not manage cgroups (however, if you have it set up, it can at least start it), which is why I added it to the list.

I agree with this, however, some tout this as a feature of systemd, so it should still be included in an unbiased list. Personally, I think it is systemd's biggest drawback, which we can obviously see a great example of the issues this can cause based on the original post of this thread.

Overall, I tried to remain as unbiased as I could with providing the information I did (except for my personal opinion at the end on whether the benefits were worth the costs). I feel far too many articles/wikis/publications either rave about systemd or attack it. It is not very easy to find unbiased information out there. And while I tried to stay unbiased with my list, I still would prefer to not use systemd and I'm glad Pat has been able to stay away from it thus far.

1 members found this post helpful.

There is no place to write the logs... The initrd, though writable, is a memory resident filesystem wiped out on any reboot (nearly mandatory if for some reason it can't find the root filesystem - and still can not be recorded until AFTER the root filesystem is mounted read/write) - thus anything that MIGHT have been recorded is lost. The only way to be sure to have at least some records is to not use an initrd, going directly to a root filesystem with persistence.
Being able to debug it when it doesn't work is even better.
The problem is not the unit files... it is the complexity of the dependency graph that creates the most failures.
The problem is that when it DOESN'T sync you can be at a total loss to figuring out WHY. The other problem is reliability - sometimes things work... and sometimes they don't. When the dependency network is incorrect it is next to impossible to fix when it just happens to work. You don't see the problem until adding another service causes the system load ordering to change... and then fail.
And yet, adding sleeps is EXACTLY what people are resorting to use to work around the failures in systemd.

The key is "complicated to pull off". A dependency graph is NOT easy to work with. Even with Fedora, systemd took several years before the dependency graph was barely workable. It was supposed to be available in Fedora 14. Nope, wasn't usable. It was presented in Fedora 15... with boot hangs, shutown hangs, nonstarting services, unworking NFS... It was in Fedora 16 - which sort of worked... if you didn't have anything complicated (multiple network interfaces and VM networking didn't work at all, setting default routes on the wrong network, not starting networks at the right time, not starting network services...) and still had boot hangs and shutdown hangs. Didn't bother with 17, 18, 19 - there were still too many reports of hangs, lost logs, nonstarting services, startup/shutdown failures... 20 mostly worked. It FINALLY did the network properly. But still people were having trouble with services - even resorting to putting long sleeps in rc.local along with systemctl service restarts to get things working (which some are still doing).

Even in Fedora 23 problems still exists trying to add a new service... sometimes the service starts... sometimes it doesn't. Getting in the right place in the graph is very difficult.

I had worked with dependency graphs before (back in the old days of the 1970s). It took weeks to get a relatively simple, one level graph workable (less than 100 nodes, one direction only); just adding one node to the list could completely tangle up the network. What systemd uses is a two level graph at best... and dynamic, not static. It also ignores the possibility of external dependencies...
"nice to have" doesn't make it reliable. Reliability is "nice to have". The normal way is "First make it work. Then make it faster". The problem is that systemd doesn't work reliably.

cgroups wasn't created for that purpose. It was originally designed to provide better resource allocation control for batch jobs. That it also can be used for interactive jobs has been known for ages. One interactive UNIX based system did the same function by making the interactive connections part of the batch scheduling system. It worked... mostly. The problem then (and now) is the loss of control over the processes. The "nice" utility is now useless - where formerly it allowed a user to determine what priority their processes should be.
no problem there. IMO it is one of the drawbacks of systemd, though I personally am not sure about it being the biggest drawback. I find the lack of flexibility, reliability and debugging the biggest drawback, and this is just a symptom of poor design.

2 members found this post helpful.

Hi,

I am very happy with Slackware and the init system. I really do not have issues with my logs. I can read them directly and rotate with no issues.

I am comfortable with the way PV & Team have kept Slackware from the systemd mess. KISS is working for users of Slackware so why even think of changing to what advantage because a commit developed by a committee that desires change for the sake of change to an unproven system without thinking things out intrinsically. Sure, improvements happen everyday but usually the changes are done in stages not all in all one time one shot.

I do still believe in the UNIX way and Slackware meets that for me.

Not to start an argument or debate but Slackware is stable an steadily meeting the needs of the community without systemd.

Have fun & enjoy!

4 members found this post helpful.

A couple of things:

Where I work, we've started phasing in CentOS7, and discovered failure modes where RAID controller problems weren't getting logged during boot-up. I wasn't part of the effort to troubleshoot that, but the people who did, blamed systemd's wacky logging.

Regarding binary logs, you can get the same advantages by using JSON-encoded structured logs, and they're still text, so you can still use standard unixy tools to filter/manipulate them, and eyeball them directly as needed (though they're more readable with a filter such as json2json).

Example of an unformatted JSON log entry (newline-delimited from other entries):

That same entry filtered through "json2json -l":

For very complex records, there is also "json2json -P" for maximum formatting:

JSON is well supported by almost every programming language in use, and there are many many existing tools for manipulating it, on top of the standard unixy tools like grep. It imposes almost no processing overhead to encode or decode, and only a slight increase in space (the ""[]{}:, make it about 20% more "fluffy" on average than a pure binary format).

All of my projects use JSON-encoded structured logs. If one needs more than an unformatted plain text log, it's the way to go.

Actually, this post led me to this page that states that /run/ should be passed pre-mounted to the main system when running systemd. Per this page, "By default, the journal stores log data in /run/log/journal/." Then, once the system comes up, journald should automatically copy the contents to /var/log/journal/ (assuming you have it set up that way).

Maybe I'm not understanding things properly (after all... this was just based on research into the "features" of systemd, not any specific implementations, as I have no desire to try any other OSes anymore), but how are Debian, Arch, Fedora, etc, able to use systemd if there's such a complete failure of the dependency graph? Based on what you're saying, the OS should be unable to boot in a lot of different scenarios. But, these distros have released "stable" versions based on systemd and there are plenty of people out there who are using it without issue (that's not to say there aren't people who are having issues, but if it's as bad as you're implying, then it sounds like there should be a lot more people complaining).

However, it should also be kept in mind that any new init system, whether that was the initial BSD, SysV, OpenRC, runnit, etc would likely have run into similar issues during development... working out the order that things need to start. The order of Slackware's scripts wasn't just written off the top of somebody's head... it took a lot of trial and error, and people are still finding issues where the scripts don't match their needs (I know Richard Cranium runs into some issues with the default scripts since he has /usr/ on a separate partition from his root partition).

But right now, there isn't even necessarily reliability with Slackware's init system. Because if a service fails to start, then it fails to start and things move along. Other services that depend on that service may try to start and fail too. There's no accountability for that in Slackware's init system.

Wasn't created for what purpose? I covered several in that response. Wikipedia states that cgroups is used for resource limiting, prioritization, accounting, and
control.

Don't get me wrong... I am NOT a fan of systemd. I hope it never needs to get implemented in Slackware, and I've been grateful how Pat and team have avoided it thus far. However, the feature list is provides (whether or not they are currently implemented well) does have some nice things in there. In the other thread (that my quoted response is from), I was not well-versed on what systemd was trying to bring to the table. I saw all the hate behind it, and I was constantly seeing people spouting off completely incorrect information (like systemd was created to just speed up the boot process... which is totally not true -- as I said above, this was just a result of parallelization). I was frustrated, because pretty much everyone was either for or against it, but it'd always turn into a flame war without any valid substance from either side. I tried to find resources to better explain what systemd offers that are missing in other inits... because there had to be something since many distros were making the switch. There were very few knowledgeable people who shared unbiased opinions on it. That is what led to my research and my post. The things I listed are what systemd claims to offer that Slackware's init system does not. It doesn't mean that Slackware needs them (personally, I have no issues with Slackware's init system... it works great for what I need it to do), but it is still something that a competing init system offers that Slackware doesn't. For some, that is a big deal. Unfortunately, as you showed above, claims don't always equal results (all those fat loss commercials can be a testament to that).

My post was not meant to be "reasons why Slackware should switch to systemd", because I don't think it needs to (assuming upstream doesn't eventually force it due to systemd dependencies that don't have alternatives available). It was more of a "what's different between Slackware's init and systemd". There's a lot of differences, not all of them good.

It is still in a memory resident filesystem. If for some reason you can't mount the destination and copy it, it is still lost. Thus no gain - just more complexity.
It does provide some benefit for laptops - anywhere that already has a relatively simple hardware configuration. It seems to handle wireless a bit better.
Yes - they did. but it only takes a few seconds to reorder the sequence. It is also trivial to get them working. Most of the added complexity was done by third party vendors. IRIX (SGI) was the first place I saw the "chkconfig" utility. Nice - but it also required a more complex init script that contained the metadata that chkconfig used. AT&T didn't use it at the time - all that was needed was to add a symbolic link or put the actual script in the rc directory. Order was determined by an alphabetic sort. Even then those startups that were in the same Snn specification could be done in parallel (never was though - but that simplified the startup).

Slackware scripts migrated - it never did really use rc scripts (being a bit more BSD/SunOS derived). These were provided for compatibility with SysV init scripts, and worked exactly the same way.

Except that you KNOW they failed, when they failed, and can do something about it.
Nope. It is VERY good for handling batch jobs. This was how the "fair-share" scheduler worked in supercomputers in the early 1990s. That fair-share scheduling evolved - and when Linux made significant inroads into supercomputing, there was again a need for good resource management.

The major difference in the way cgroups are actually used doesn't include the long-term accounting. Only the resource control. But that accounting can still be done.

As long as you realize they are lying about them. They SOUND nice - the problem is they cannot deliver.
That was one of their statements - now gradually being dropped.
That is part of the problem. The "claims to offer" are not necessarily true. The systemd developers gloss over the part where it fails to deliver.

There have been cockups by the systemd developers breaking things, then trying to coerce the kernel developers to change something to handle the systemd failures. At least one of them has been banned from making kernel patches. Using kernel defined options for systemd use... then trying to put the blame on the kernel developers for another failure of systemd...
First, the alternative has to ACTUALLY work. So far, systemd is still limping along - but imposing itself on a lot of formerly independent projects to compensate for its own failures.

3 members found this post helpful.

I understand a lot of what you're saying, but if things are so bad, then why have so many distros embraced it? It just can't be as bad as you're painting it with only a few major holdouts not jumping on the systemd bandwagon. And it isn't even just distro maintainers... you're also seeing a large number of upstream projects adding systemd support, while dropping support (or not providing any additional support) for non-systemd alternatives (not the direct spinoffs of systemd services like Consolekit2 and eudev, but the ones previous to those). Things can't be as bad as the systemd naysayers are saying if a HUGE chunk of the Linux market is moving towards it.

systemd can't impose itself on anything but fedora (and RedHat driven programs). Everyone else, both distro maintainers and upstream developers had a choice and the majority chose to embrace systemd. Why would everyone do that if systemd is as bad as you make it?

I think most distro maintainers don't care, and adopted it when it became a dependency for udev. Nearly every distribution uses udev to load device drivers.

Some distributions (including Slackware) have adopted eudev, which avoids the dependency. Such distributions are listed here: https://forums.gentoo.org/viewtopic-p-7648392.html

That's 47 Linux distributions in all. That's a lot of distributions rejecting systemd, they're just mostly minor distributions.

1 members found this post helpful.

Upstream projects don't really support it - most of them do accept updates from systemd developers, with the Linux kernel being one of the biggest hold outs, having rejected kdbus as something to fix user space performance issues.
I keep saying "it works in relatively simple setups". I haven't seen it really work in complex configurations... Not that it can't work, but it will require some rather large resources to fix the problems that crop up.

The more complex the dependency network, the less reliable it gets.

and a number of distributions accepted it when udev became dependent on it.

Now that there is eudev as an alternate those rejecting systemd are using it instead of udev.

1 members found this post helpful.

Isn't KDE working towards logind support and not really tinkering with the other options? I figured based on Eric's comments about researching it that the other alternatives are losing support from KDE. Granted, I haven't dug into this a ton.

So, RHEL7 and SLES12 are working with simple setups? Both have had systemd for around 2 years. I have a hard time imagining the enterprise is willingly accepting as bad of a system as you're portraying it is.

I didn't ever put the two together. That does make a lot of sense. But it seems like many distros have gotten beyond the point of just simply switching to eudev (and/or logind). It's not impossible, but it still seems not likely.