Hacker News Reader

Comment by esaym | Hacker News Reader

Wish I could get over it. But every time some random process fails to start at boot time I...well I cry a little knowing this is what we are now stuck with.

View on HN

With all of the valid criticisms of systemd, you've chosen an imaginary one. Systemd provides better process handling and failure reporting than the initscripts it replaces (and mostly better than upstart, as well).

I really wondered whether people would sympathize with me or just flame me.

I guess I can explain my 'imaginary' problems a bit. Like normal people, I had several random things thrown in rc.local(set drive power settings,disable blue tooth on laptops, set raid sync rates,ect).

The first issue was, systemd never even executed this file. I had to go do random googling just to get it to execute.

After that, it was hit or miss on whether everything within the file would even get successfully executed. I'm guessing because some dependencies or modules aren't loaded yet, which shouldn't matter since rc.local is normally ran last. Sure, I could take each individual command and make its own init file which is what systemd docs recommend over rc.local. But seriously, why should I have to go to that length to fix something that has been working fine for 15 years?

In the end, I have had to rewrite my init scripts for custom stuff and do extra work and I am left wondering why I even tried it in the first place. The only speed difference (which from what I can tell is the only reason anyone uses systemd) I have seen is on my desktop machine. Start up is way faster, and shut downs too. Although strangely shutdowns hang randomly for over a minute sometimes. But on my laptops, I have noticed no difference.

In summary, systemd has not simplified my life. I am not really sure what the rave about it even is. And no, I am not the one threatening the developers. I really don't care enough. I just find it odd that so many praise it so heavily, and I don't feel that way at all. I also know of no sysadmins that are looking forward to its global rollout....

> The only speed difference (which from what I can tell is the only reason anyone uses systemd)

Not even close. To the extent it improves performance, that's a nice side effect. For me, personally, it means a few lines of .service instead of a pile of init.d, service supervision when services unexpectedly exit, easy log integration to see what services are up to, and unified activation of services by a variety of means (socket, bus, path, dependency, etc).

In the long run, having a unified interface to every service on the system is a win. In the short run, we find ourselves with semi-broken, or somewhat less than ideal, tooling and interfaces and a reasonably large amount of learning friction where there was a low amount before.

I've been a UNIX/Linux system administrator coming up on 20 years now (professionally since about '99), and I understand the pain. It's hard to break the habits of all that time; it's always worked before. In a pinch we've always been able to stick some shell commands somewhere and have it fire up the stuff we wanted to fire up.

But, it's nice to have one "thing" to ask questions of that will tell us a significant amount of data about the state of our system. It's something Windows Server has had for a long time (for Microsoft-provided core stuff; third party stuff has always sucked way worse than the state of things on Linux has ever been), and was arguably one of the (very few) reasons one might choose Windows over Linux on a server.

I have reservations about systemd. It's big, seemingly over-engineered and intrusive into places that init never went, and does some things in seemingly fragile ways (someone else mentioned that dependencies failing can lead to failure to boot, which is not something init ever really had a problem with). But, it's better than init, on nearly every axis. And, it is the new de facto standard.

So, I will learn it. I will work to make all the software I work on (which has an installed base in the millions, in the case of Webmin) work well with it. And, I'll probably even come to like it, eventually.

" we find ourselves with semi-broken, or somewhat less than ideal, tooling and interfaces and a reasonably large amount of learning friction where there was a low amount before"

Yes! Exactly! When you start breaking people's stuff that was working you will certainly not be getting compliments!

    ~$ grep -r 'rc\.local' /lib/systemd/system
    /lib/systemd/system/rc-local.service:# systemd-rc-local-generator if /etc/rc.local is executable.
    /lib/systemd/system/rc-local.service:Description=/etc/rc.local Compatibility
    /lib/systemd/system/rc-local.service:ConditionFileIsExecutable=/etc/rc.local
    /lib/systemd/system/rc-local.service:ExecStart=/etc/rc.local start

"I really wondered whether people would sympathize with me or just flame me."

It was not my intention to flame you. From your tone and sparse message, I assumed you were making yet another unfounded accusation about systemd; so many people on both sides (but mostly on the anti-systemd side) have been making ridiculous and untrue statements so often and for so long that I tend to just expect random made up nonsense to fly with reckless abandon. In your case, you have had a bad usability experience with systemd; and I can't deny your experience. I wasn't there.

That said, it is my understanding that rc.local continues to work fine on systems that choose to enable the compatibility layer. Fedora is my desktop and laptop OS of choice, and I don't think I did anything to make my rc.local files work. I don't use them for much, but I do have some custom hard disk spin down times and such setup on one of my machines, which continued to function after upgrading to a systemd-based version.

If your distro opted not to enable the compatibility layer by default, I suspect there's an easy way to do it yourself with a single command line or installation of a package.

Our servers all run CentOS and we've put a couple of new CentOS 7 systems online recently, and while we don't have any rc.local bits running on them, we do still have a few old style initscripts (in our products, embarrassingly enough, even though our bootup and shutdown module supports systemd and upstart, we still ship initscripts to start our own stuff), and they have continued to function correctly on CentOS 7.

In short, it has not been my experience that doing things the old way has been dramatically cut off for people who need to continue doing so for the time being. In my, admittedly limited, experience, I haven't noticed any difference except the "service" command now recommends systemctl when you run it.

Agreed. I maintain my stance as a critic of systemD but it's better than what we had before.

I've very little to criticise it as an init system... My criticism falls more towards the issues of "why is this all in one process not task specific child processes launched by a core init process" and "why can't you make this work on BSD" and "why the f%*^# hell are you building kdbus... Please stop killing the kittens"

But why should someone writing for Linux think about OpenBSD? Are you saying every piece of BSD software runs on Linux? Go try telling Linus that you want a BSD compatible kernel.

Systemd does not run on BSD because of Cgroups and that is something the BSD maintainers don't want. Here's a small set of justifications why : systemd leverages core Linux infrastructure that has already diverged from OpenBSD

http://lwn.net/Articles/524920/

Having said that, there is work that the systems is sponsoring a project that implements systemd on OpenBSD

http://www.phoronix.com/scan.php?page=news_item&px=MTc4MjQ

It's sort of funny for me how the systemd attitude towards portability is quite similar to that of the OpenBSD community, whose software (OpenSSH, OpenSMTPD, OpenBGPD...) generally runs on OpenBSD only and where porting is done by a separate team, but somehow the interwebs aren't full of rants calling the OpenBSD people jerks for not caring about non-OpenBSD platforms...

OpenSSH seems to be the best known of the bunch, and even then it is loosely couples to the rest of the system.

Systemd on the other hand is rightly couples to the Linux kernel (to the point that you may have to update systemd and the Linux kernel in lockstep), and its many sub-systems are tightly coupled to the existence of systemd-pid1.

This makes systemd a whole other beast from OpenSSH.

You're not stuck with anything. Any major transition will have bugs that need to be ironed out. In a year or two, assuming you don't switch to Slackware, it will be more reliable than sysvinit.

Major transitions do inevitably have issues, but that doesn't mean they're all equally painful. Systemd folks have definitely not done a great job of easing the transition, both on the technical side with interoperability with existing tools and configurations, and on the human-interaction factors of project management and marketing.

If systemd is that bad, where is The Distro Without systemd?

You know, the Linux distro that sets itself apart from the rest by Not Having systemd. Just... not having it. Going with SysV init or BSD init or Something Which Is Not systemd.

Because I don't see one, which implies it isn't that bad.

There are distros that don't use systemd.

Slackware for one. Besides, appeal to popularity isn't a very good argument from my perspective.

It isn't appeal to popularity it's just noticing that if it didn't work nobody could possibly use it. Certainly not as many as do use it.

Guix, the GNU system, uses dmd.

"stuck" ? How was your init system choice enforced ? Did you have a gun pointed at your head ?

Is there absolutely no working alternative ?

You don't have to use systemd. If you keep using it when there are other working systems and you don't like it, the fault is entirely yours.

> "Did you have a gun pointed at your head?"

How did we get here? Because people on the internet continually use this highly charged language without regard. It is high time we as a community (at least on HN) commit to stop using such language.

We don't need to use such language. We don't need it. We can easily make our points without it. For example:

> "stuck"? There are many alternatives to systemd. There are many distributions which do not use it.

While keeping with the intent, this replacement no longer uses the violent language and also no lessens the attack on the parent commenter.

We should in general:

1. Not use violent language

2. Not attack commenters

3. Use non-adversarial language whenever possible.

> You don't have to use systemd.

Whatever the original problem was or the top link that is just not a viable solution. It is like saying "you don't have use libc, write your own". Or "Fine, Linus is a jerk, don't use the kernel, install minix but stop criticizing linux".

Let's say I follow the advice and apt-get remove systemd from Ubuntu 14.10. It doesn't look good. It takes along with it gnome-session, gvfs, nautilus, network-manager, pulseaudio, ubunt-desktop, softare-center, update-manager, update-notifier and others. Have you tried doing, maybe I am doing something wrong and there is a easier way to replace it.

Don't use Ubuntu, a distro that has explicitly said that they were going to support systemd and abandon sysvinit ?

One major problem is that gnome relies heavily on systemd. Good thing there are other DMs.

So now have to switch distro with its whole echo system.

Wasn't that exactly the point of the argument -- how saying "just replace systemd" doesn't work and is not a realistic answer to any of the criticism?

Perhaps. I was an early adopter. I switched because the news at the time was indeed, debian is switching and there will be no alternatives. It seems their will be some alternatives at least in the next release. Not sure about after that though. But too late, I already converted everything, not converting back.

Reply on news.ycombinator.com