Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoiding Complexity with Systemd

mgdm.net

Post reply on HN
Print view View original

81–90 of 357 posts

Re: Avoiding Complexity with Systemd

#81

Post by loudmax »

idoubtit wrote: post #71
midasuni wrote: post #13

Earlier quoted context omitted.

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

I doubt answering rants is useful, but I'll try to give factual counter-arguments. > there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years of typing cat /etc/resolv.conf systemd-resolved is not enabled by default in Debian and many distributions, and it is not needed in any way by systemd. If you don't like it, don't use it! Your rant does not sound very serious. Did you real…

I tend to agree with most of the points you're making but I do want to point out that "If you don't like it, don't use it" isn't helpful advice for system administrators who weren't given a choice in the matter. It's fine if you're designing a system from the ground up, but most of the time, most of us have to work with what we're given.

I think most of the resentment against systemd is that it felt like it was forced down our throats. Systemd may be an improvement over the mess of shell scripts we had before but it isn't perfect. It's one thing to choose to give up decades of experience so one can voluntarily switch to a new system. It feels very difference when the choice isn't one's own.

Re: Avoiding Complexity with Systemd

#82

Post by diegocg »

bitwize wrote: post #20

You incur complexity with systemd. You avoid complexity with runit.

runit isn't comparable with systemd. It isn't even trying to be a powerful init system.

You will incur in lots of complexity trying to deal with init systems that aren't much better than traditional init.

Re: Avoiding Complexity with Systemd

#83

Post by throw-8462682 »

knorker wrote: post #53

My problem with systemd is that it's just so poorly written. The ideas are not inherently bad. But they're not thought through, and the implementation is pure garbage. Like taking the most stable software in the world[1], and going "nah, I'll just replace it with proof-of-concept code, leaving a TODO for error handling. It'll be fine.". And then the "awesomeness" of placing configuration files whereever the fuck you…

Care to elaborate? Off the bat, your comment comes across as a cynical rant due to its high use of strong words (garbage, fuck) and lack of examples. And even if you have anecdotes, to be convincing, it would have compare something like bug density to the software projects that collectively replaces. As written, your statement is unlikely to convince anyone that isn’t yet already.

Re: Avoiding Complexity with Systemd

#84

Post by pjmlp »

midasuni wrote: post #13
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

I only used Linux mostly during university, while at CERN and only after most UNIXes gave up fighting against it.

From what I remember, everyone else on UNIX world was already following up on systemd like systems before it got adopted on Linux world, and on Red-Hat/SuSE distributions daemon scripts existed for quite a long time as well, so no it wasn't * /etc/init.d/myserice restart* for decades.

Re: Avoiding Complexity with Systemd

#85

Post by sgt »

If you are looking to run your containers in a very light weight way and also easily understood, you can use systemd for this and use tips from this article. You will have to do the orchestration yourself so I think it would have to be more suitable for very simple deployments with small teams and / or part time projects.

Re: Avoiding Complexity with Systemd

#86

Post by iso1210 »

jbverschoor wrote: post #28
turminal wrote: post #24

Earlier quoted context omitted.

> * If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd? Because the only two alternatives are 1) running mainstream distros from before 2014 or 2) running obscure distros that still don't use systemd.

Or you could've actually improved init.d and add all the features to is, and make easy to use/create.

I suspect many sysadmins, certainly the ones who complain about syslog, were quite happy with init.d

Traditionally developers would write code and packagers would package them into a distro specific rpm/deb -- including the init scripts (which may be pushed back upstream). Developers wanted to bypass this slow process, and there were far more developers than people willing to package the software.

Personally I've never had a problem writing an init.d script.

Re: Avoiding Complexity with Systemd

#87

Post by viraptor »

midasuni wrote: post #13
Dinux wrote: post #10

I'm glad to see more people sway to systemd. Systemd is 10 years in the making and it was met with skepticism right from the first day. Some of that is now slowly changing with systemd being accepted in more and more distributions. Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. I remember when it took multiple days testing the configu…

For people who had well working low maintenence environments, systemd came in and changed everything - breaking things, requiring changes to get things working again. Its not just breaking init.d scripts, it’s ntp, dns, syslog. Systems throughout the OS fail to things that were no longer short commands with muscle memeory, there were now ridiculous convoluted commands like systemd-resolve --status instead of 30 years…

> Or the restart fails it doesn’t tell you why, it gives you two locations to look for log files about why it might have broken. Init.d scripts didn’t do that.

Some things are a matter of preference, but this bit is just wrong. Init.d was hilariously worse. Some services had their own configuration locations, some had those exposed via /etc/defaults, some used syslog, some redirected stdout/stderr, some redirected one and discarded the other.

You're right that there are two places now - logs are either in the journal or in app-specific log location. And stdout/err go to the journal. Those 2 places mean fewer places to look through than we had before.

Re: Avoiding Complexity with Systemd

#88

Post by iso1210 »

morelisp wrote: post #61
bonzini wrote: post #19

Earlier quoted context omitted.

> Now is it systemctl restart myservice or systemctl myservice restart Actually long before that it was service restart myservice, which still works.

Unfortunately, it was `service myservice restart`, which is the wrong order if you want to be able to do multiple things at once (or even just align with any other `cmd subcmd args` program).

  service myserver restart

  /etc/init.d/myserver restart
Seems the traditional order to me

  $ service myserver status
  $ service myserver reload
  $ service myserver restart
makes perfect sense when tackling a single service

Re: Avoiding Complexity with Systemd

#89

Post by stefanha »

knorker wrote: post #53

My problem with systemd is that it's just so poorly written. The ideas are not inherently bad. But they're not thought through, and the implementation is pure garbage. Like taking the most stable software in the world[1], and going "nah, I'll just replace it with proof-of-concept code, leaving a TODO for error handling. It'll be fine.". And then the "awesomeness" of placing configuration files whereever the fuck you…

My understanding is that default unit files provided by the systemd packages are in /usr/lib where they can be read-only, whereas users can add/override them by dropping their own unit files into /etc (which is more likely to be read-write).

This provides a clean separation between the default configuration and the user configuration.

Can you explain why this is a bad thing?

A counter-example that comes to mind is when a package upgrade requires manual intervention due to file conflicts in /etc. That's what happens when the packager's default configuration interferes with the user's custom configuration.

Re: Avoiding Complexity with Systemd

#90

Post by pjmlp »

stefanha wrote: post #48

Recently I have been wondering if systemd solves problems that are becoming less and less relevant to developers. New services are often deployed as containers. While systemd has a bunch of container-related functionality, it does not integrate well into the Kubernetes or even Docker workflow. It's used very little in those environments. If you are building CoreOS or NixOS system images, or traditional Linux system s…

Those of us using Java, such problems were already kind of irrelevant in 2005.

Where you deploy your EAR/WAR file doesn't matter, so the application container can be running on Windows, any UNIX flavour or even bare metal, what matters is there is a JVM available in some way.

Also on the big boys UNIX club (Aix, HP-UX, Solaris,...) systemd like alternatives have been adopted before there was such an outcry on GNU/Linux world.

On cloud platforms if you are using a managed language, this now goes beyond what Java allowed.

You couple your application with a bunch of deployment configuration scripts, and it is done, regardless of how it gets executed in the end.

The cloud is my OS.

Post reply on HN