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

41–50 of 357 posts

Re: Avoiding Complexity with Systemd

#41

Post by kzrdude »

turminal wrote: post #24
irl_ wrote: post #21

Earlier quoted context omitted.

I think you're missing a few things here: * Services started with sysvinit would put logs where they want, which is fine if you know where they are but per-service you might be guessing. Having everything always in the same place is handy. * sysvinit wasn't giving you any of these security benefits. * If your system really was working fine before, why did you need to upgrade it to a newer distribution with systemd?

> * 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.

yes, people forget that we are a village.

Contrary to “popular misconception”, Linux is not a settler's freehold where every holdout makes their own rules.

Admins have to work with a diversity of systems. They can choose how to setup new ones, but they have to work with a range of them. What everyone does has an effect on everyone else. If some distro introduces a new way of doing things, it has some chance of ending up affecting a lot of people - they might have to adapt to also support that way, or handle it in some way.

In that way we are a village, things are connected, and that’s why there is some degree of "social control" - looking across the neighbor’s fence and meddling with their way of solving the problem - it can in some sense become ours, if we are unlucky.

Fortunately, we can relentlessly copy good solutions from others in the village too.

Re: Avoiding Complexity with Systemd

#42

Post by Ballas »

kkirsche wrote: post #40

As someone who wants to learn systemd, even just to understand what I’m stuck with and why it was made, this is the best introduction I’ve found. Does anyone have other resources to help beginners learn how to use systemd efficiently and it’s relationship to Docker?

You have probably already seen this, but I found this an interesting explanation to the why question: https://www.youtube.com/watch?v=o_AIw9bGogo

Re: Avoiding Complexity with Systemd

#43

Post by delusional »

dagw wrote: post #31
jbverschoor wrote: post #23

Earlier quoted context omitted.

Really? Have you ever written init scripts for a hand full of services for your typical saas application? It’s always been a mess, and I’m very happy systemd was copied from / inspired by Apple’s launchd.

I'm not saying it was necessarily easier to use, just easier to understand what was going on. Explaining step by step how a Unix systems started up used to be trivial and make sense. I don't hate systemd, I just don't understand it. But that could also be symptom of me being old.

Naa. I'm young and generally positive about systemd, but I'd happily admit that the complexity gap is huge. It's practically impossible to explain systemd to anyone not intimately familiar with linux and systems programming without a bunch of handwaving.

Re: Avoiding Complexity with Systemd

#44

Post by tyingq »

My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation.

Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I had no idea it would have been logind doing that.

Similar for changes introduced with systemd-resolved.

Re: Avoiding Complexity with Systemd

#45

Post by TruthWillHurt »

I'd suggest you stear away from using systemd and a server to launch your startup.

While this is a good writeup, and you end up with a service, you still need to manage a machine with all risks involved - server reboots, updates, networking etc.

AWS Fargate, or the new App Runner will manage a container almost hassle-free

Re: Avoiding Complexity with Systemd

#46

Post by spindle »

delusional wrote: post #43
dagw wrote: post #31

Earlier quoted context omitted.

I'm not saying it was necessarily easier to use, just easier to understand what was going on. Explaining step by step how a Unix systems started up used to be trivial and make sense. I don't hate systemd, I just don't understand it. But that could also be symptom of me being old.

Naa. I'm young and generally positive about systemd, but I'd happily admit that the complexity gap is huge. It's practically impossible to explain systemd to anyone not intimately familiar with linux and systems programming without a bunch of handwaving.

This. I can easily believe that systemd is an improvement in many ways for people who have time to understand it (especially in NixOS, as noted by another commenter). But I'm not happy that so many parts of Linux now have such a steep learning curve.

Re: Avoiding Complexity with Systemd

#47

Post by throw-8462682 »

delusional wrote: post #43
dagw wrote: post #31

Earlier quoted context omitted.

I'm not saying it was necessarily easier to use, just easier to understand what was going on. Explaining step by step how a Unix systems started up used to be trivial and make sense. I don't hate systemd, I just don't understand it. But that could also be symptom of me being old.

Naa. I'm young and generally positive about systemd, but I'd happily admit that the complexity gap is huge. It's practically impossible to explain systemd to anyone not intimately familiar with linux and systems programming without a bunch of handwaving.

As a DevOps, having to know a bunch of Linux and system programming is a job requirement. In the old days Unix system admins were very familiar with this also.

Re: Avoiding Complexity with Systemd

#48

Post by stefanha »

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 services, then systemd matters. But I think way more services are being built for the container world where these problems are solved differently.

For example, the TLS configuration can be handled with common container patterns. The author's startup example would translate more easily to a full-blown Kubernetes environment once the VC funding hits their bank account if they had used containers from the start instead of first writing the service for systemd.

It's a shame because systemd is very powerful and I've enjoyed using it.

Re: Avoiding Complexity with Systemd

#49

Post by zeeZ »

kbumsik wrote: post #32
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 sometimes feel a bit weird when I see complaints like this. Because I have never experienced broken by systemd. For logging, can't you write a systemd service in bash with -x flag?

Recently a systemd update that came with a flatcar linux update added/enabled a systemd-resolved stub that hogged port 53, preventing the actual DNS server on the machine from starting up. Does that count as broken by systemd?

Re: Avoiding Complexity with Systemd

#50

Post by danny_sf45 »

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…

As a developer I prefer using systemd instead of containers to deploy Golang applications.

Without (Docker) containers it is:

- build Go binary and install it in production server

- write and enable the systemd unit file

With (Docker) containers it is:

- write Dockerfile

- install Docker in production server

- build Docker image and deploy container in production server

I get the appealing of containers when one production server is used for multiple applications (e.g., you have a Golang app and a redis cache), but the example above I think containers a bit of an overkill.

Post reply on HN