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

211–220 of 254 posts

Re: Why I dislike systemd

#211

Post by groks »

weland wrote: post #201
groks wrote: post #160

Earlier quoted context omitted.

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

Polkit is a great idea, don't get me wrong. However: * Like pretty much anything from freedesktop.org, the documentation is a joke. * The security system implemented through it is next to impossible to debug. It's very easy to add "allow to happen", but I can't do things like "ok, tell me who can mount filesystems" or "give me a list of all things that users in the wheel group are allowed to do". Normally this would…

> Like pretty much anything from freedesktop.org, the documentation is a joke.

  man polkit
Looks pretty good to me. It even includes an ascii-art architectural diagram! Here's the webified version: http://www.freedesktop.org/software/polkit/docs/master/polki...

> polkit doesn't have a textual interface, it only works through D-Bus. This makes it useless for scripting.

polkit(8) and pkcheck(1) describe how to use the pkcheck program. It returns 0 on success (access granted).

> I can't do things like "ok, tell me who can mount filesystems"...

I think that's the nature of the problem domain. polkit seems to be for enforcing arbitrary rules, when the built-in rules of something like sudo can't cope. Therefore: arbitrary code snippets as rules, therefore, no introspection.

However...

> ...or "give me a list of all things that users in the wheel group are allowed to do".

  pkaction | grep mount
  org.freedesktop.udisks2.filesystem-mount
  org.freedesktop.udisks2.filesystem-mount-other-seat
  org.freedesktop.udisks2.filesystem-mount-system
  org.freedesktop.udisks2.filesystem-unmount-others
Gives a list of actions. Use pkcheck to probe for access.

Re: Why I dislike systemd

#212

Post by groks »

digi_owl wrote: post #197
groks wrote: post #160

Earlier quoted context omitted.

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

The difference appears to be that the sudoers file supports the finite set of access checks the authors of sudo anticipated. If you need something more elaborate than that, write arbitrary javascript to the polkit api.

Re: Why I dislike systemd

#213

Post by EmanueleAina »

pnathan wrote: post #167
EmanueleAina wrote: post #144

Earlier quoted context omitted.

If your needs are simple, the resulting unit file is trivial and you can basically copy and paste from any example without looking at any documentation. If your needs are complex, you have better chance by mixing different options in the completely declarative syntax of systemd than mixing shell snippets from different scripts using different styles. In any case systemd happily launches LSB-compatible init scripts, y…

Complex needs are better solved with source code rather than special blobs of $system. > In any case syst emd happily launches LSB-compatible init scripts, you literally don't lose anything. Yes, I do. I literally have piles of unwanted systemd on my system.

> Complex needs are better solved with source code rather than special blobs of $system.

Arguably, reinventing multiple complex wheels is often a not particularly good choice.

So either you're implementing something really novel in your init script (which does not sound like the best place for it) or it's something that may benefit from a single, shared and tested implementation.

And, again, you can still fallback to LSB shell scripts if you really need something incredibly special: my point was that, bloat notwithstanding, you don't lose any feature but gain many.

Re: Why I dislike systemd

#214

Post by EmanueleAina »

weland wrote: post #200
EmanueleAina wrote: post #143

Earlier quoted context omitted.

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

Never heard about it, is there any link with more details?

Re: Why I dislike systemd

#215

Post by EmanueleAina »

yellowapple wrote: post #171
EmanueleAina wrote: post #143

Earlier quoted context omitted.

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.

I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".

It worked before, it stopped after a change in the kernel, another change made the problem disappear: the root of the problem was definitely a bug in the kernel.

That said, it's perfectly fine for the kernel developers to clarify that a flag is for their own exclusive use, and indeed it seems that this is how things ended up. Note that there are multiple userspace applications parsing the flags on the kernel command line: the most striking example when discussing the "debug" flag is the "quiet" flag.

Re: Why I dislike systemd

#216

Post by EmanueleAina »

yellowapple wrote: post #185
the_why_of_y wrote: post #181

Earlier quoted context omitted.

http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01537.html

That says nothing about why the systemd folks are entitled to hijacking a kernel flag instead of (more sanely) namespacing their own debug flag, which is the actual bug that was filed (and in turn met with "it's not a bug it's a feature, so go whine to the kernel folks about the thing of theirs that we broke and don't feel like fixing", as if the systemd folks have become one with the Microsoft). Whether or not there…

Honestly I find that a single global "debug" option would have been useful, instead of having to know which component (the kernel, the ramdisk, sysvinit, sysv-rc, systemd, upstart, udev, whatever) is at fault.

Unfortunately such mechanism introduced a feedback loop in the presence of a bug in the kernel. I understand that it would be difficult for the kernel to guard from such loops, but my sincere impression is that they threw out the the baby with the bathwater.

Re: Why I dislike systemd

#217

Post by weland »

EmanueleAina wrote: post #214
weland wrote: post #200

Earlier quoted context omitted.

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

Never heard about it, is there any link with more details?

https://bugzilla.redhat.com/show_bug.cgi?id=753882

Enjoy.

Re: Why I dislike systemd

#218

Post by weland »

EmanueleAina wrote: post #215
yellowapple wrote: post #171

Earlier quoted context omitted.

I fail to see how systemd hijacking a kernel boot argument for its own purposes is a "bug in the kernel".

It worked before, it stopped after a change in the kernel, another change made the problem disappear: the root of the problem was definitely a bug in the kernel. That said, it's perfectly fine for the kernel developers to clarify that a flag is for their own exclusive use, and indeed it seems that this is how things ended up. Note that there are multiple userspace applications parsing the flags on the kernel command…

> That said, it's perfectly fine for the kernel developers to clarify that a flag is for their own exclusive use

Oh for fuck's sake. It's a parameter passed to the kernel. Programs shouldn't parse it for precisely the same reason why Firefox doesn't parse sshd's arguments. I.e. because they're passed to sshd, not to Firefox.

It's a ridiculous clunky hack that stinks of large company coding practice: what they actually needed was a way to pass arguments to systemd itself.

The logical way to do that in an OS that has to be portable and flexible is to implement a mechanism for the kernel to pass some of the arguments it receives to init. Because there's no reason to assume that init is going to be systemd, that there's going to be a procfs ready for it so as to be able to read the kernel's parameters, or that the init process can read it for that matter.

The way the systemd development team chose to do that (widely seen in many other projects from the same lineage, like Pulseaudio) was ha look at that we can see the kernel's arguments so how about we use those and what do you mean "this can have unwanted side-effects", it works perfectly fine on my system.

The fact that the developers (again, it's a known pattern) decided to play the PR game and call it "expected behaviour" doesn't make it less of a bug. It's also expected that a division by zero will crash your program. It doesn't mean that blindly accepting any input values is not a bug, nor that the correct way to solve "your program crashes if I pass 0 as the first argument" is "well stop passing 0 as a first argument ya evil bastard."

Re: Why I dislike systemd

#219

Post by EmanueleAina »

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…

> A -> B -> C -> D. Easy.

Oh, sure, sequentially starting up a fixed list of services is probably easier with sysvinit, given that's the only thing it does.

With systemd you probably want to set Requires=foo and After=foo in bar.service to have foo running before bar. It does not seem overly complex, or you meant something else?

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

Wouldn't you create 10 different init script for sysvinit, each with its own LSB header listing the dependencies such that tools like Debian's insserv could correctly schedule them?

I'm quite sure that it's far easier to express complex dependencies with systemd than with sysvinit, if that's your concern.

Correct me if I'm wrong, your dependencies could be handled like the following:

[A] Requires=B Requires=C

[B] Requires=D

If A needs B to be running before A even starts (ie. they cannot be run in parallel) just add After=B to A. With sysvinit I'm not sure if there's a way to say that A needs B but that they can be started in parallel.

I don't get your question "can C then start at same time as D": if they do not depend on each other, I don't see the problem. If they have a dependency, just add After= to the one that needs to be launched later in the process. If you don't know, add After=C to D and you've got a slightly slower but sequential boot as with sysvinit.

> That's... not true. From the first line of the hostname manpage: "Hostname is used to display the system's DNS name, and to display or set its hostname or NIS domain name."

Oh, indeed, sorry. I then guess `hostnamectl` only provides notifications and some extra info on top what `hostname` already does.

> If I lived in a blue sky world, where I was fresh installing one new server with a simple set of services that I had built in systemd, I think I be quite happy with it. The problem is that I have thousands of servers, and a decade or more of accumulated infrastructure that relies on those traditional tools. Then systemd comes barging in and breaks a bunch of stuff, and that is frustrating. I'm not saying I hate systemd, in fact I agree that many of the new tools are quite nice. But it's kind of like the loud hipster that shows up at your party and starts talking shit about the music you are playing, and making fun of your choice in beer. Maybe my music does suck, and maybe these clothes aren't cool anymore, but we were sitting around having a fine time until he came around.

I totally understand your concerns. I guess you don't have many options: you can stick with sysvinit for a while (eg. Debian still officially has full support for it) and in the meantime start making sure your scripts run fine with the LSB compatibility support in systemd (if you're just starting services they should work transparently with no effort).

But consider that in any case, staying with sysvinit has never been an option: during the Debian debate, the contenders for the default were systemd and Upstart, sysvinit has always been kept only as the baseline to test compatibility.

With that in mind, the LSB support in Upstart (and in every other contender) is far less mature than the one in systemd. As the incredibly smooth migration done by the Debian systemd team proves, systemd has the best compatibility support of the pack.

(I mention Debian as that's what I use and for the fact that the systemd maintainers poured a big deal of effort to provide the best systemd/sysvinit compatibility)

Re: Why I dislike systemd

#220

Post by EmanueleAina »

falcolas wrote: post #140
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.

That's not a DSL, that's a shell script. As for what `pexp="..."` does - it's just setting the pexp variable. If you'd like to know what that does, you can just look up the bash source of `/etc/rc.d/rc.subr`, another bash script. No DSL knowledge required, at all. Just shell knowledge, and the willingness to look at sourced shell scripts.

I mean, I know that it sets a variable, I can't even guess what are the effect of setting that variable.

And "look at the source" is a sad answer, no matter if the source is a shell script or C program.

The point is that with your example you need domain knowledge, knowing bash is not enough: what does the pexp assignment do, what rc_reload=NO means, should flags be specified in the daemon variable or that's meant to only contain the binary, does that path be full or it takes in consideration a standard PATH?

And now you got two things to know: the bash (or even strictly posix sh) language (which, admittedly, isn't the best one in the world) and the domain specific functions/variables.

This isn't much different than with systemd: the language is much more simple and far less surprising being INI-like (the same as .desktop files), and it's basically just setting a list of rather well documented variables.

Post reply on HN