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

Systemd has been a complete, utter, unmitigated success

blog.tjll.net

Post reply on HN
Print view View original

51–60 of 114 posts

Re: Systemd has been a complete, utter, unmitigated success

#51

Post by idoubtit »

thyristan wrote: post #28
haiku2077 wrote: post #11

I've worked as a sysadmin/devops for a double digit number of years. Across companies, jobs, and hobbyist collaborators - I've never met someone who didn't at least like systemd, if not sing its praises. It made so many incredibly painful things about Linux administration disappear.

And made a number of new ones appear. E.g. logging, now that there is journald, you have to pay attention to another hop in your logging chain and take care of journald in addition to rsyslogd. Boot and shutdown has previously been deterministic, now things just randomly hang. You do the "windows solution", reboot again, now it magically works through the power of race conditions that are inherent in systemd's mode o…

The grand-parent post was about the general consensus: sysadmins generally like systemd. So I'm not sure answering individual concerns is useful, but I'll take the bait...

> now that there is journald, you have to pay attention to another hop in your logging chain and take care of journald in addition to rsyslogd.

No, you don't have to, because a syslog daemon is not required any more. BTW, rsyslogd is not the only syslog service, I've had to work with alternatives like rsyslog-ng.

And the daily usage is now much simpler: `journalctl -b -1 -p err` or `journalctl -u mariadb --since "24 hour ago"` were painful queries with (rotated and compressed) syslog files.

> Boot and shutdown has previously been deterministic, now things just randomly hang.

That was not my experience. IIRC, with sysv-init boot dependencies were declared with comments inside shell scripts and parsed by insserv. That was a mess, and race conditions did occur. I have no experience with other boot systems, but I remember that upstart was not immune either.

> Network device naming is also a fun one.

The naming policy is vaguely relevant to systemd. `net.ifnames=1` is the default configuration of the Linux kernel. I think it's still possible to configure the kernel, udev and systemd to work with the old naming, but if it's just because "shorter is better", I don't think it's worth it.

Re: Systemd has been a complete, utter, unmitigated success

#52

Post by bigstrat2003 »

NewJazz wrote: post #15
bcoates wrote: post #14

Does anyone actually use journald? The last time I tried(2 years ago?) it didn't even work with any log management software (like cloudwatch for example). You had to either use some (often abandoned) third party tool or defeat the purpose by just reconfiguring everything to dump a text log to a file.

Cloudwatch fucking sucks. Plenty of log shippers can slurp journald. (Fluentd, filebeat, vector) Even ChromeOS uses it, even on devices that still use Upstart.

You're being downvoted but you're absolutely right. The fact that Cloudwatch doesn't support journald is a major, major fail on AWS' part. It's not like this is new or obscure software.

Re: Systemd has been a complete, utter, unmitigated success

#53

Post by akdev1l »

mrweasel wrote: post #45
scraptor wrote: post #37

I don't hate journald because it's not plaintext, I hate it because it's worse than plaintext. Somehow journald manages to provide a database which is 40x slower to query than running grep on a compressed text file. I'm all in favour of storing logs in an indexed structured format but journald ain't it.

Journald is an odd one. I don't think it being a binary log/database makes sense. If you have a tiny operation, with a single server, then the binary database doesn't really make sense, having plain text is just easier and faster. If you're a bigger operation, you'll have a central logging solution, in which case you need journald to store the longs as plain text as well, before you can do log shipping. The only use…

afaik journald can just forward logs via rsyslog directly to a remote server

Why would it need to store plaintext locally?

Re: Systemd has been a complete, utter, unmitigated success

#54

Post by msgodel »

idoubtit wrote: post #51
thyristan wrote: post #28

Earlier quoted context omitted.

And made a number of new ones appear. E.g. logging, now that there is journald, you have to pay attention to another hop in your logging chain and take care of journald in addition to rsyslogd. Boot and shutdown has previously been deterministic, now things just randomly hang. You do the "windows solution", reboot again, now it magically works through the power of race conditions that are inherent in systemd's mode o…

The grand-parent post was about the general consensus: sysadmins generally like systemd. So I'm not sure answering individual concerns is useful, but I'll take the bait... > now that there is journald, you have to pay attention to another hop in your logging chain and take care of journald in addition to rsyslogd. No, you don't have to, because a syslog daemon is not required any more. BTW, rsyslogd is not the only s…

It's a little weird to reply to someone complaining about administrative problems caused by systemd with "generally sysadmins seem to like it."

That kind of response is exactly why everyone gets emotional in these discussions. Technical problems are one thing but when you gaslight people experiencing and reporting legitimate problems you should not be surprised when they get mad and rip your solution out.

GP is being far kinder to the systemd devs than they deserve, I gave up on the project years ago for exactly this reason.

Re: Systemd has been a complete, utter, unmitigated success

#55

Post by akdev1l »

vinceguidry wrote: post #34
haiku2077 wrote: post #11

I've worked as a sysadmin/devops for a double digit number of years. Across companies, jobs, and hobbyist collaborators - I've never met someone who didn't at least like systemd, if not sing its praises. It made so many incredibly painful things about Linux administration disappear.

I used to be fine with it, until I started writing my own software tools, then looking at how to actually do stuff with systemd and I'm like, nope nope nope nope. At some point when I have space for a new project I'm going to migrate from Arch to Obarun, which uses a modern update on the excellent daemontools to provide init. When systemd works it's mostly fine, when it breaks, path of least resistance is often to re…

> when it breaks, path of least resistance is often to reinstall the OS

Can you elaborate how do you even break this?

Adding a systemd unit cannot really break much on systemd itself. Unless you’re messing with internal systemd stuff, I am not sure what is even there to break.

Re: Systemd has been a complete, utter, unmitigated success

#56

Post by msgodel »

amoe_ wrote: post #40

I was pro-systemd at the time of the controversial discussions. I still think it's a net positive relative to what was there before. But personally speaking, it's only the core of the software (service management) that improved things for me. The other things (timers, journald) I either ignore or don't like, but perhaps they're useful for distributions.

I think if it was just service management most people wouldn't mind it nearly as much.

Re: Systemd has been a complete, utter, unmitigated success

#58

Post by msgodel »

bryanlarsen wrote: post #36
pram wrote: post #19

I personally love the init/service/unit-file portion of systemd and have few complaints. It has a lot of powerful features for security, cron, etc that are very simple to use. I also really like journald. The parts I don’t really like are the half baked “ancillary” managers like resolvd, which are frankly baffling to use and tend to make simple things needlessly difficult.

Hard disagree. Name resolution feels like a solved problem, so why fix it if it isn't broken? But that's just like the old init & logging systems. They mostly worked, and yes it was annoying to relearn a new way of doing things. But the new way is better. I've got software that works with resolvconf, NetworkManager and resolved. I definitely prefer resolved. Yes, the cost of switching likely exceeds the benefits for…

I think even for new people the systemd configs are much more complex (and the APIs are certainly much more complex) than the libc ones which worked well (often better.)

The problem is that almost nothing in Systemd shares theory with the rest of the OS. It's entirely its own island of new ideas, commands, and configuration language that you have to learn and memorize.

Re: Systemd has been a complete, utter, unmitigated success

#59

Post by msgodel »

Analemma_ wrote: post #32
pessimizer wrote: post #26

No, it's terrible. I think what they mean by "success" here is that it functions, and is easier to use and more sturdy than init scripts. But any number of things would have been better than those. Instead of writing and adopting one or more, Linux allowed Redhat to take over the last piece of itself, its spine, after which Redhat sold itself to IBM. Linux is an IBM product. They basically mediate all Linux access to…

> Instead of writing and adopting one or more, Linux allowed Redhat to take over the last piece of itself, its spine, after which Redhat sold itself to IBM. Linux is an IBM product. Who exactly was going to write the systemd alternative? If by "Linux" you mean the kernel devs, that was never going to happen-- systemd is a middleware stack living in userspace, the kernel guys were never going to get involved. If you m…

OpenRC is great, there's just no flashy marketing behind it or team of consultants pushing it.

EDIT: Heh. At least I can debug a shell script, I can't debug a config file.

I think this is a fundamental disagreement many people have in what's ultimately desirable when designing software. I personally can't stand non-trivial config files and both at work and at home have wasted way too much time pulling apart software consuming them.

The problem with systemd is that, because of all the new userspace APIs it adds, we can't just agree to disagree. You either target a Systemd OS and the users get to suffer non-trivial, often broken, configs or you target a normal GNU/Linux OS and the systemd users suffer all kinds of surprises when systemd rug pulls them.

Re: Systemd has been a complete, utter, unmitigated success

#60

Post by akdev1l »

iambvk wrote: post #10

I am not a sysadmin -- so I keep forgetting the command to see logs cause I only need it once every 3 months. So, systemd change is a pain for me.

use a shell function/alia?

    show-logs() { journalctl -u "$1" } 

    show-logs nginx
(Not that I think journalctl -u even needs an alias tbh but if you want it you can have it)
Post reply on HN