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

Why I dislike systemd

steven-mcdonald.id.au

Post reply on HN
Print view View original

191–200 of 254 posts

Re: Why I dislike systemd

#191

Post by digi_owl »

JdeBP wrote: post #183
EmanueleAina wrote: post #136

Earlier quoted context omitted.

I don't think it's really fair to compare writing unit files to being able to program in shell. True, knowing the systemd unit options is not a reusable skill, but it's not a huge effort either: the syntax is trivial (INI-inspired, the same as .desktop files) and the options themselves are rather well documented. And for sure, these options are immensely more reusable when writing a new unit file than mixing and matc…

knowing the systemd unit options is not a reusable skill That is, to an extent, not true. There is at least one system that can import systemd unit files, subject to some fairly obvious limits on Linux idiosyncrasies. http://homepage.ntlworld.com./jonathan.deboynepollard/Softwa...

Heh, i was wondering how long it would take before we would get something like this.

Re: Why I dislike systemd

#192

Post by digi_owl »

ben_bai wrote: post #154
EmanueleAina wrote: post #139

Earlier quoted context omitted.

Indeed. But at that point you have a DSL which is no longer obvious when one only knows about shell scripting (eg. I have no idea what `pexp="smtpd: \[priv\]"` does), so using a completely declarative language with a trivial syntax doesn't seem a huge issue either. One may think about systemd's unit files as a set of shell variables that gets sourced by the real script.

man rc.subr pexp A regular expression to be passed to pgrep(1) in order to find the desired process or to be passed to pkill(1) to stop it. By default this variable contains the daemon and daemon_flags variables. To override the default value, an rc.d script has to redefine this variable after sourcing rc.subr.

That you can import shell scripts into shell scripts is one of those things that catch many off guard when first encountered. But when grok-ed, really demonstrate how far shell script can go.

Re: Why I dislike systemd

#193

Post by digi_owl »

yellowapple wrote: post #165
jveld wrote: post #19

It got the job done by making the 99% majority of use cases more difficult in order to make the 1% minority simpler. This is a design pattern I think is being repeated in systemd. I kinda had the opposite impression. I first encountered systemd when I started messing around with arch for a couple little vps projects. At the time I was doing sysadmin that involved both Ubuntu and CentOS, and I definitely found day-to-…

The nice thing about initscripts, though, is that you can get the best of both worlds by sourcing in common functions, as is the default and recommended practice on OpenBSD. For example, here's the initscript for dovecot on my (OpenBSD-running) mail server (with some comments and newlines omitted for brevity): daemon="/usr/local/sbin/dovecot" . /etc/rc.d/rc.subr rc_cmd $1 Pretty straightforward: you set $daemon to th…

That is the crazy part, systemd at its core is a reaction to sysv (and upstart).

In part part the reaction is to the boilerplate nature of sysv scripts, as they bring all their logic with them.

but if you glance outside the RH/Debian sphere you find the likes of Slackware, that has been using BSD style init for decades.

Re: Why I dislike systemd

#194

Post by digi_owl »

XorNot wrote: post #48
stormbrew wrote: post #42

Earlier quoted context omitted.

So I have not yet had to use systemd in any serious way, so I may be misinterpreting here, but I think this: > ... and config/daemon reloading as things that could be made automatic, I'm assuming with e.g. inotify change events. is a misinterpretation of the author's complaint. It sounds like with systemd, if you tell it to restart a service it will continue to use the old definition until you run a separate command…

Because systemd is event-driven, you can't actually be sure the service file won't be re-used in the running configuration - or that it won't trigger other service reloads/starts/stops due to its dependency specifications. Ergo systemd requires an explicit reload to commit the state of the unit files once you're satisfied they are as intended. This is very important when you consider that unit files can kill other un…

And in the end i will gladly trade a few seconds longer boot for a system i can actually reason about rather than treat as some kind of black box voodoo. The latter is why i moved away from Windows in the first place.

Re: Why I dislike systemd

#195

Post by digi_owl »

keypusher wrote: post #156
EmanueleAina wrote: post #141

Earlier quoted context omitted.

> The problem is that when I have 10 or 20 units with interlocking dependencies, it's an absolute nightmare to try and untangle because I have to jump between so many different files How that's different from sysvinit? > The longstanding /var/log/messages is now replaced by journalctl tool, and the logs are actually in binary. `journalctl` prints plain text on its stdout, so you can think of it as a glorified `cat` i…

> How that's different from sysvinit? In sysv I can just make a list of startup tasks. A -> B -> C -> D. Easy. 10 things that must start in specific order? No problem, 10 things in list. There is no easy way to do this in systemd. I must create 10 different unit files, and then create a bunch of different dependencies (A depends on B and C, B depends only on D, can C then start at same time as D?, etc). When those de…

And in the end you hit a sore point square on the head.

Systemd is not built for traditional server farms, it was initially built to scratch a desktop bootup itch that Poettering (and perhaps Sievers) had that then got extended to deal with booting containers.

To them, and others working on systemd, the traditional server way is history and they are building for the containerized present/future.

Re: Why I dislike systemd

#196

Post by digi_owl »

weland wrote: post #87
olau wrote: post #61

Earlier quoted context omitted.

Interesting way to think about it. IMHO systemd is taking much of the hacks and weird glue that has historically held distributions together and replaced it with an active upstream project. Maybe some of the solutions they've come up with could need some improvements, but I have much higher confidence those improvements would happen now compared to how things used to be. Nowadays you can code something up and come to…

Unfortunately, the systemd development team is not that easy to work with, which is part of why a lot of people distrust systemd the way they do. In theory, yes, it should be the way you mention it. In practice, even bug reports end up unacknowledged and labeled as features after a few philosophical debates. No one who has used more than one Linux distro would disagree that a unified system to control init services i…

One lovely example i have seen is Poettering completely misunderstanding a perfectly valid use of su, and instead recommending that people ssh back to their own box if they wanted a shell under a different user.

This came up in relation to a systemd set environment variable that would break software by overwriting one user's config files with that of another's.

The variable was apparently set that way because of pulseaudio.

The really worrying part was any lack of "mea culpa" from Poettering once someone outside the bug report told him that pulseaudio could be changed so that the variable was no longer needed and Poettering implemented that change.

Instead he just left the bug report hanging, and others had to report on the changes and declare the issue sorted.

Re: Why I dislike systemd

#197

Post by digi_owl »

groks wrote: post #160
pjc50 wrote: post #58

Earlier quoted context omitted.

Polkit is a nightmare . And I agree with you on the churn. There was a time when Linux administration changed less frequently than Windows, round about the 95-XP-Vista era.

http://smcv.pseudorandom.co.uk/2015/why_polkit/

I can't tell the difference between sudo and polkit, except that the latter comes with some XML based presets and can be talked to via RPC (dbus).

Re: Why I dislike systemd

#198

Post by digi_owl »

geggam wrote: post #113
stefantalpalaru wrote: post #67

Why would you punish yourself with various *BSDs when you can have OpenRC and more advanced ports on Gentoo? Do people really associate systemd, Gnome and other nuisances with Linux?

Punish ? .... BSD is extremely user friendly. It just seems to be picky at who it calls friends. They ONLY reason I still use Linux anywhere is because I have to keep my skills for it fresh since its where I make a living. The metric I like to use for adopting new processes / services is pretty simple. I have _____ problem. What tool solves that problem for me. In my case systemd solves nothing and creates more.

> Punish ? .... BSD is extremely user friendly. It just seems to be picky at who it calls friends.

I seem to recall the same line being used about (GNU/)Linux at one point.

Re: Why I dislike systemd

#199

Post by cubancigar11 »

cubancigar11 wrote: post #51
empressplay wrote: post #5

I don't "hate" systemd either, I just think it's a bad approach. It flies in the face of the "open architecture" concept and stifles innovation. It discourages users from learning about how their operating system works, and it unnecessarily puts too much control of a fundamental component of the OS in the hands of a too-small number of people. None of these reflect the Linux I grew up with. Thus, I am not a fan of sy…

ossreality you are [dead]

People downmodding this have really nothing better to do?

Re: Why I dislike systemd

#200

Post by weland »

EmanueleAina wrote: post #143
weland wrote: post #117

Earlier quoted context omitted.

All over their bugtracker, but the most famous one is here: https://bugs.freedesktop.org/show_bug.cgi?id=76935

Which was ultimately caused by a bug in the kernel, and the systemd developer ultimately accepted the proposed changes just to avoid any kind of confusion (to me, it looked perfectly acceptable to parse the kernel command-line, multiple applications still do for other purposes). Arguably, the tone of the discussion resembles more the usual LKML tone rather than the one observable on the systemd mailing list.

If this one isn't satisfying, digi_owl has a nice one, too: https://news.ycombinator.com/item?id=9723476
Post reply on HN