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

131–140 of 357 posts

Re: Avoiding Complexity with Systemd

#131

Post by mananaysiempre »

Nursie wrote: post #114
einpoklum wrote: post #100

Earlier quoted context omitted.

1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. 2. Some of the systemd logging is binary, so good luck with that if there's a problem. 3. Have you tried non-systemd init systems other than sysvinit? 4. Yes, it is convenient when everything below your development is cenrtalized by a single entity. It can easily provide a consistently useful underpinning. But…

> 1. This can, and should, all be done without systemd, and not with idiosyncratic shell scripts and guesses. What other system is there, right now, that can do this so well? I'm definitely onboard with the issues around tight coupling, I'm really not a fan of binary logs etc. But the unit files are pretty awesome IMHO. So serious question - what else does those as well or better?

In addition to s6 itself, the author of s6 also wrote a survey https://skarnet.org/software/s6/why.html> that provides a good large-scale view of the design space.

(My gripe with how systemd does a traditional init’s job is mostly the unit and dependency types, all of which AFAICT are specified in terms of actions on state transitions, not consistency conditions on states, so for all that it has a positive boatload of them I can’t actually figure out how to specify which configurations are permissible for my system.)

Re: Avoiding Complexity with Systemd

#132

Post by mmis1000 »

dagw wrote: post #22
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…

Service and runlevel management wasn't any better in the sysv era, nor were any of the multitude of custom start and boot scripts. They might not have been better or more robust, but they where easier to understand and reason about. You could explain the entire thing to the most junior of sysadmins in a few minuets, tell them to read the boot scripts, and they would basically understand how everything worked.

Until service restarts and error recover, log storage sneaks. In the past I just call pm2/forever(or something like that, I write nodejs most) to do the rest. Because roll those yourself... is really a pain.

And a few months ago I retried that with systemd. It's really just about 10 line of configs. And you are done.

Besides that, it also has a build-in scheduler with a command for you to tell when was the task runs, did it success? And what about the outputs. Although you could say it is just a cron replacement with better ui. But why no? I don't really care about the unix philosophy, I just care what do solve the problem for me.

Re: Avoiding Complexity with Systemd

#133

Post by 5e92cb50239222b »

jbverschoor wrote: post #36
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…

You do know that resolving something involves other things than a simple udp query to port 53?

Here's a decent overview if anyone is interested in details.

https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-l...

Re: Avoiding Complexity with Systemd

#134

Post by sseagull »

5e92cb50239222b wrote: post #128
geofft wrote: post #104

Earlier quoted context omitted.

I really don't understand the scenario where binary logging is a problem. journalctl is a command just like, I dunno, gzip, and people are fine with gzipped logs. If something goes horribly wrong with your system, you're not looking at logs with an oscilloscope, you're looking at logs by mounting the disk on some other working OS - whether it's the initramfs, or a live CD, or whatever. You can run gunzip (Not to ment…

A thoughtful comment downvoted into oblivion without any explanation. Classic HN. I too don't get the hate that binary logs receive. They aren't any harder to work with than text logs. journalctl makes it easy to read logs from an offline system, too. The compression it automatically provides saves a lot of space across our machines. I know that it can be achieved without binary logs, but does any popular distributio…

I think the argument is really about transferablilty of skills. I already know how to manipulate compressed files because I have to do that in other places. And once you realize logs are just text files, I can immediately transfer all my skills of dealing with text files to dealing with logs.

But now I have to learn another set of tools (or at least another command to convert it to text files). It's not really a huge issue (I'm not really a systemd hater), but there can be a bit of dread when all the tools move off of standard formats, like simple text files, to custom formats, requiring you to learn idiosyncrasies of lots of different packages.

(And the reverse is true. Knowing how to use journalctl only helps me with systemd, and nowhere else. It's a piece of knowledge helpful in only one area that I cannot transfer anywhere else)

Re: Avoiding Complexity with Systemd

#135

Post by nh2 »

atoav wrote: post #4
whateveracct wrote: post #2

Use NixOS and you'll love systemd. You'll be defining your own systemd units with ease. systemd to you will be journalctl and systemctl. So pretty good.

I use mostly Ubuntu and Debian and defining systemd units just means you have to spit the right text into a .service file placed at the right spot. How does NixOS make that easier?

You can override NixOS's predefined systemd settings from _outside_ using NixOS module options. This allows you to change default settings that are not optimal for your use case, without having to patch NixOS itself, or write your own unit config.

For example, systemd by default permanently gives up restarting services after a few number of tries (e.g. 5), even if you have set `Restart=always`. This is suboptimal for web servers that should recover by themselves after arbitrarily long failures (e.g. network downtimes outside of your control).

On NixOS, you can, from your machine config, set:

    systemd.services.nginx.unitConfig.StartLimitIntervalSec = 0;
This sets/overrides just that specific systemd option for the existing nginx module. On other distros, you often have to resort to global mutation in `/etc` that does not compose well.

We use NixOS for our infra (having used Ansible before), and this ability to override anything cleanly and keeping defaults otherwise made for much easier to maintain infra code and less ugly/surprising compromises.

Re: Avoiding Complexity with Systemd

#136

Post by aerique »

cpach wrote: post #27
bitwize wrote: post #20

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

IMO runit is abandonware at this point. No release since 2014. Have you looked at s6? It’s a compelling alternative.

Void Linux, "the BSD of Linux", uses runit and it has been fine since forever.

If there were any issues they would be worked on.

Re: Avoiding Complexity with Systemd

#137

Post by morelisp »

iso1210 wrote: post #88
morelisp wrote: post #61

Earlier quoted context omitted.

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

The traditional order is more like

    # /etc/init.d/myserver reload
    unknown command reload
    # /etc/init.d/myserver restart
    unknown command restart
    # /etc/init.d/myserver stop
    myserver: warning: frobulator did not fully unfurl
    # /etc/init.d/myserver start
    myserver: still running on pid 1234
    # kill -TERM 1234
    kill: (1234) - No such process
    # grep "running on pid" /etc/init.d/myserver
            echo "$0: still running on pid `cat /var/run/myserver.pid`"
    # rm -f /var/run/myserver.pid
    # /etc/init.d/myserver start
What you're calling "traditional" is the minor, purely UI-facade-level consistency we got after 10 years trying to clean that mess up. But actually we eventually gave up, and went on to invent something better.

Re: Avoiding Complexity with Systemd

#138

Post by josephcsible »

bonzini wrote: post #130
dane-pgp wrote: post #111

Earlier quoted context omitted.

I believe that Red Hat employees were some of the main contributors to Gnome, which quickly made systemd a hard requirement, forcing distros which used it as the default desktop to make systemd the default init system.

It's not a hard requirement, GNOME still runs on the BSDs.

Thankfully, sanity eventually did prevail in GNOME (just related to this matter, not in general), but there was a period of time where systemd absolutely was a hard dependency,

Re: Avoiding Complexity with Systemd

#139

Post by axaxs »

stefanha wrote: post #89
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 wh…

Not going to really argue here, but I have to use mlocate every single time I want to find a unit file, because there's no telling where it would be.

Perhaps blame lays on the distro packager, but still, it ends up to a user being strange.

Re: Avoiding Complexity with Systemd

#140

Post by RunningDroid »

stefanha wrote: post #89
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 wh…

> 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?

The normal way to do this is to put the default configuration in /usr/share/.

Post reply on HN