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

11–20 of 357 posts

Re: Avoiding Complexity with Systemd

#11

Post by zozbot234 »

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…

There's a lot of poorly-understood incidental complexity in the systemd codebase, and this can bite users even when doing basic service and runlevel management. The systemd approach is to try and make it 100% declarative based on simple .ini files, but the semantics of this seemingly "declarative" configuration was never properly specified. Even many systemd fans seem to be quite aware of this, and there seems to be a common understanding that some ground-up reimplementation of these ideas based on a clearer underlying "philosophy" will be needed at some point. Systemd has been a successful experiment in many ways, but relying on throwaway experimental code for one's basic production needs is not a good idea.

Re: Avoiding Complexity with Systemd

#13

Post by midasuni »

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 of typing cat /etc/resolv.conf

Even when you remember and type that in, you don’t get a simple list of nameserver and host, you get 100 lines of text you have to spend effort parsing to work out what’s going on.

When it’s less mental effort to run tcpdump port 53 to see where your DNS is going, there’s a problem.

For decades it was /etc/init.d/myserice restart

Now is it systemctl restart myservice or systemctl myservice restart? I have no idea as I’m not at a computer.

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. Even if there was something really wrong that log files don’t reveal, running init.d with bash -x allowed easy debugging

Systemd came in and changed working processes and systems and gave very little benefit to people with working processes and systems from a operator point of view.

Re: Avoiding Complexity with Systemd

#15

Post by mhitza »

djhworld wrote: post #8

Really enjoyed reading this article. The LoadCredentials thing reminds me of configmaps in K8S, is there a more general thing in systemd e.g LoadConfig

Disclaimer, no idea what LoadConfig does.

A more generic approach than LoadCredentials I think is the EnvironmentFile= directive if you want to pass along multiple env variables to your process without individual Environment= directives

Re: Avoiding Complexity with Systemd

#16

Post by southerntofu »

zozbot234 wrote: post #11
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…

There's a lot of poorly-understood incidental complexity in the systemd codebase, and this can bite users even when doing basic service and runlevel management. The systemd approach is to try and make it 100% declarative based on simple .ini files, but the semantics of this seemingly "declarative" configuration was never properly specified. Even many systemd fans seem to be quite aware of this, and there seems to be…

I hope you're right and we get a better, simpler declarative format in the future. systemd isn't bad but i've found when writing service files that some stuff is not as obvious as it should be.

Re: Avoiding Complexity with Systemd

#17

Post by baybal2 »

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…

> Systemd is 10 years in making

Systemd is 10 years in making, and still manages to brick production servers.

The problem is not with SystemD or its coding as such, but the ideology it came with, and bad developers who push it.

The last attempts to make it saner basically reverted it back to sysvinit. So, not much difference now.

Re: Avoiding Complexity with Systemd

#18

Post by bonzini »

baybal2 wrote: post #17
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…

> Systemd is 10 years in making Systemd is 10 years in making, and still manages to brick production servers. The problem is not with SystemD or its coding as such, but the ideology it came with, and bad developers who push it. The last attempts to make it saner basically reverted it back to sysvinit. So, not much difference now.

> The last attempts to make it saner basically reverted it back to sysvinit

Uhm, how so?

Re: Avoiding Complexity with Systemd

#19

Post by bonzini »

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…

> Now is it systemctl restart myservice or systemctl myservice restart

Actually long before that it was service restart myservice, which still works.

Post reply on HN