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

211–220 of 357 posts

Re: Avoiding Complexity with Systemd

#211

Post by spinax »

_d7dt wrote: post #196
spinax wrote: post #188

Earlier quoted context omitted.

> You can run gunzip It's subtle, and you've accidentally missed it like many do - you made an assumption that everything logs through journald. On my personal system where I do not have rsyslog (aka trying to live the journald life) I have non-journald text logging for: httpd, sa (sar/sysstat), lightdm, audit, atop, Xorg, cups, fdsync and samba. If we just stick to httpd, sa and samba (most folks know how those work…

If you want to use journald for those programs you could just configure them to pipe the logs there, or you could just disable journald logging and have it pipe its logs to the syslog. If your distro didn't configure all those programs to log to the same place, that's more of a distro configuration problem than a problem with any specific syslogger. I personally dislike having a bunch of services that try to implemen…

System Ops (at scale, large company, lots of teams) in a nutshell: you did not build the system or choose what kind, it was most likely installed using vendor defaults by the systems owner and you were called in because it's misbehaving. Most likely 50 other people have touched various parts of it, some with skill some without.

"Give me an IP, username and password - what OS is it?" are about all you start with and go from there. It's probably a critical system to someone, and everyone swears on a stack of bibles that nobody did anything, touched anything or made a change. You have very specific domain knowledge (kernel, grub, SAN/storage, systemd, dbus, etc.) and typically ask a lot of questions to the systems owner as your fingers are flying ruling out reasons (low hanging fruit common issues).

Re: Avoiding Complexity with Systemd

#212

Post by zxzax »

knorker wrote: post #159
throw-8462682 wrote: post #83

Earlier quoted context omitted.

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.

It's a pile of proof-of-concept broken pieces duct taped together into a big mess. Here's an example: Someone read that fd-passing is a thing, so now systemd listens to just about everything and spawns stuff on-demand. Now, that may seem like a good idea, if you think it up in a vaccuum and don't have experience with the real world. It's a great idea, if you're in high school. But to have it actually accepted? WTF is…

You can just disable the fd passing for services that don't need it. I'm not sure what your actual issue is. I haven't had to reboot any more with systemd than I did with sysvinit or openrc, or the slackware rc init, or anything else really. If you have an actual crash that is causing you problems, you should consider reporting it or submitting a patch to fix it, just like you would with any other open source that you depend on.

>systemd is on the level of a re-think by a pretty bright high school student.

That seems like an odd statement, I believe systemd was inspired by other established unix service managers like macOS launchd and solaris SMF. The design is definitely not perfect but I wouldn't say the history was ignored when making it.

Re: Avoiding Complexity with Systemd

#213

Post by zxzax »

spinax wrote: post #211
_d7dt wrote: post #196

Earlier quoted context omitted.

If you want to use journald for those programs you could just configure them to pipe the logs there, or you could just disable journald logging and have it pipe its logs to the syslog. If your distro didn't configure all those programs to log to the same place, that's more of a distro configuration problem than a problem with any specific syslogger. I personally dislike having a bunch of services that try to implemen…

System Ops (at scale, large company, lots of teams) in a nutshell: you did not build the system or choose what kind, it was most likely installed using vendor defaults by the systems owner and you were called in because it's misbehaving. Most likely 50 other people have touched various parts of it, some with skill some without. "Give me an IP, username and password - what OS is it?" are about all you start with and g…

Ok so complain to the ops department that they need to unify their logs. That's their problem, not yours. If the company is big I would expect them to be doing that anyway, either they coalesce around a journald-type thing that aggregates the logs locally, or they'll use another centralized service like datadog, splunk, etc. Edit: If you are ops then this is your entire wheelhouse, you should be able to solve it at scale without messing everything up.

Re: Avoiding Complexity with Systemd

#214

Post by bkor »

josephcsible wrote: post #119
viraptor wrote: post #92

Earlier quoted context omitted.

If you can't opt out of systemd-resolved due to job policies, that's really not systemd's fault and there's nothing they can do to solve that situation. Why complain about it in that context?

What does this have to do with job policies? Systemd was forced down our throats by Red Hat adding hard dependencies on it to other software under their control, e.g., GNOME. Other distros then adopted systemd under duress, since many of the packages that Red Hat made depend on it are important to the Linux ecosystem, and the other distros didn't have the resources to fork them all.

> Systemd was forced down our throats by Red Hat adding hard dependencies on it to other software under their control, e.g., GNOME. Other distros then adopted systemd under duress

What utter drivel. I've participated in the discussions around systemd in various distributions. There was a huge amount of discussion, then one by one distributions switched. Some quickly, some took various years. Again, some distributions took various years to switch.

That you can only say things such as "forced down our throats" and "duress" says enough. Not capable to actually hold a discussion, let's be emotional and without any actual facts.

Re: Avoiding Complexity with Systemd

#215

Post by lanstin »

theranger wrote: post #113
kzrdude wrote: post #41

Earlier quoted context omitted.

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…

So the admins should really not rant about systemd but complain about the distributions who switched to systemd or about their employers who force them to use such distributions.

Or just buckle down and view a new chance to learn something as an enjoyable opportunity. Dammit people we aren’t paid for being experts but the ability to become expert-like in new areas.

Re: Avoiding Complexity with Systemd

#216

Post by bkor »

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

Earlier quoted context omitted.

It's interesting to see these allegations ("power play in support of a long-term RH strategy") without any proof or for that matter any explanation of what the strategy would be.

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.

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

Yet another person writing fantasy, not facts. Systemd wasn't "quickly" made a hard dependency. It was a soft dependency for ages, then eventually the release team made a mistake around systemd-logind. I was part of the GNOME release team at that time. Still, GNOME runs without systemd. Meanwhile we had loads of discussions with loads of distributions.

Yet the things you write: quickly done, apparently lots of people were secretly paid by Red Hat, forcing distributions? All devoid of any facts, just emotions that dismiss the amount of work me and loads of volunteers have done.

Re: Avoiding Complexity with Systemd

#217

Post by lanstin »

iso1210 wrote: post #86
jbverschoor wrote: post #28

Earlier quoted context omitted.

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 nev…

All I ever could do was add a line to rc.local that started a supervisor process to run my stuff. But I have many service unit’s as part of user-data.sh or cloud init and they work and restart on failure and are visible to other admins I haven’t talked to etc. it was surprisingly easy.

Re: Avoiding Complexity with Systemd

#218

Post by zxzax »

cpach wrote: post #172
Nursie wrote: post #129

Earlier quoted context omitted.

Looks quite neat, though perhaps just a little more complex than systemd service files, I guess they essentially boil down to similar things. Where systemd has one file with a bunch of settings in, this is split into a directory of single-purpose files in s6. I'd hesitate to call it "better", but from a surface reading it seems roughly equivalent from a usability perspective.

According to the author, Laurent Bercot, the code for s6 is much cleaner than the systemd code. For anyone curious I guess the best way to find out is to compare and make a judgment of one’s own.

In some ways yes, in other ways no. I've looked at both, and there is always a certain amount of "ugliness" that comes with writing low level C software for Unix.

Re: Avoiding Complexity with Systemd

#219

Post by bkor »

josephcsible wrote: post #138
bonzini wrote: post #130

Earlier quoted context omitted.

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,

> Thankfully, sanity eventually did prevail in GNOME (just related to this matter, not in general)

You've rewritten history to pretend you're right. Then you follow up with more drivel? Sorry, aside from trolling, what is your point?

Re: Avoiding Complexity with Systemd

#220

Post by lanstin »

rep_movsd wrote: post #151
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…

If you are using UNIX like environments, you are forced to remember arcane commands - after almost 25 years of using Linux, I still have to open the man page for something as ubiquitous as grep - because there's so many options and you are always finding new use cases. The best solution is to maintain infinite bash history and stop trying to remember arcane stuff. Don't even get me started on tools like jq - so convo…

It took like six attempts but I finally like jq. Very handy for one liners or quick bash scripts that read data from AWS cli output. It yeah in general prefer to remember the search terms for the working examples. I Google “Awk add total” at least one a month.
Post reply on HN