Systemd, ten years later: a historical and technical retrospective • Hacker News Board

Re: Systemd, ten years later: a historical and technical retrospective

#351

Post by theamk » Mon, May 04, 2020, 2:23 PM UTC

dijit wrote: post #234

theamk wrote: post #135

Earlier quoted context omitted.

> All of the things you mentioned were already solved adequately really? Let's say (not entirely hypothetically) that you have a daemon. This daemon has a config file, which is large and complex. This daemon's /etc/init.d file builds command-line dynamically, then passes it to start-stop-daemon as usual. Puzzle level 1) You made a typo in init file, so that daemon does not start. The "start" command succeeds, but the…

Not sure if joking (since, sysvinit is very old and was in need of replacement) so I'll answer in good faith. > You made a typo in init file, so that daemon does not start. The "start" command succeeds, but there is no output anywhere, and process does not start. How do you debug it in the sysvinit world? "oh my process failed; let's add `-x` to the invocation." > You made a typo in init file, so that daemon does not…

Puzzle level 1) ini file:

you mean, "add -x to the invocation, get back a few screenful of text, wade through that looking for "export" lines and copy them to your terminal, find "start-stop-daemon" line, copy the part of the line and remove irrelevant parameters, and paste into your terminal as well?

I would not call this "easy" or "solved". Possible, yes. Pleasant, no.

Puzzle level 2) inherited env -- I think you made copy-paste error? You just copied the same paragraph again.

Puzzle level 3)

Surprise! Neither dmesg or /var/log/messages or /var/log/dmesg usually contain startup problems! Sometimes the nice daemon might log stuff there, but it is no way universal or required.

The sysvinit recommended way is to call things like "log_failure_msg" and "log_warning_msg", and those only print to stdout, which is the console. That's it. Gentoo's OpenRC does claim to have boot console logger, but it was broken every time I tried to use it.

Are you running any servers? If so, you might want to connect to the monitor, reboot and see if any service has error messages. Or you can use console scrollback after the server is booted, but you might need to recompile your kernel to increase is size, it is pretty small. Or just install systemd, it has full boot logging fully integrated with primary logging. And even a special command which lists all daemons which failed to start.

Re: Systemd, ten years later: a historical and technical retrospective

#352

Post by AsyncAwait » Mon, May 04, 2020, 2:26 PM UTC

jude- wrote: post #341

AsyncAwait wrote: post #326

Earlier quoted context omitted.

> elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. You do realize even the Linux kernel doesn't make any commitments regarding API stability, right? That's kind of an explicit choice to allow the maintainers to move forward with the limited resources they have without too much red tape. There's always *BSD, if you want compatibility back to the Sun days in some…

> You do realize even the Linux kernel doesn't make any commitments regarding API stability, right? It does for userspace APIs. Linus is notorious for chewing people out for breaking them (example: https://lkml.org/lkml/2012/12/23/75 ).

Yes, I should have clarified I meant kernel-level APIs, not userspace.

Re: Systemd, ten years later: a historical and technical retrospective

#353

Post by vezzy-fnord » Mon, May 04, 2020, 2:27 PM UTC

cycloptic wrote: post #349

vezzy-fnord wrote: post #314

Earlier quoted context omitted.

All models are wrong, some are useful, others not so much. There's no need to treat me with these banalities. The job model ought to have died with Upstart. It did not. Oh well. > The core problem has already moved to a different area and that's why it really doesn't matter if they are doing a bad job. Yes, I agree. Still, the losers of history deserve their voice, too. "Nobody" is a significant overstatement. A lot…

Sorry for the glibness I am just really bored with these complaints, it really feels like the same old bikeshedding. As far as I know there is no way to make a transactional state machine without having the concept of a single, reordable work unit. Daemontools did not solve this or present a different model that was more workable. For every developer that rewrote their daemon to get rid of forking, we got more new de…

> As far as I know there is no way to make a transactional state machine without having the concept of a single, reordable work unit.

You're basically taking systemd's architecture as an axiomatic premise, so no surprise your conclusion is obvious. I reject the premise, and the fruits of it I go into detail in chapter 3.

For the record I am mostly a Unix-hater, so your complaints about Unix are things I agree with. systemd, however, is simply more New Jersey design with unwarranted pretensions.

systemd, in a way, is exactly the init system that a community as infantile and disordered as Linux rightfully deserves. May they enjoy it.

I'll leave things at that.

Re: Systemd, ten years later: a historical and technical retrospective

#354

Post by AsyncAwait » Mon, May 04, 2020, 2:27 PM UTC

nlgza wrote: post #342

AsyncAwait wrote: post #322

Earlier quoted context omitted.

> It would be impressive if Lennart managed that by himself. Red Hat wanted it done RedHat wanted it done once Lennart convinced them it is the right thing to do and Lennart put in the effort to be at RedHat at the right time to have the ability to convince them. In fact Lennart is one of the few people willing to put in the effort to touch the fundamental building blocks that otherwise rot, but nobody is willing to…

RedHat has several people who take over projects and rewrite everything they see, with little or no benefit other than getting a high commit count.

Any examples?

Re: Systemd, ten years later: a historical and technical retrospective

#355

Post by pknopf » Mon, May 04, 2020, 2:30 PM UTC

dTal wrote: post #270

a-nikolaev wrote: post #83

Earlier quoted context omitted.

Void Linux, amazingly awesome distro.

Second this, an incredible distro with an impressive package manager.

Except its maintainer recently quit.

Re: Systemd, ten years later: a historical and technical retrospective

#356

Post by esarbe » Mon, May 04, 2020, 2:30 PM UTC

rleigh wrote: post #297

jcelerier wrote: post #206

Earlier quoted context omitted.

> It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a…

You're not disagreeing with anything I said. You're making a completely different point. systemd might be more convenient from the point of view of an end user. And unit files might seem superficially simpler than a script. But systemd is not simpler. It provides significantly more complexity, while also providing a lot of features. systemd is also not more reliable. The previous system, even with LSB dependencies, w…

Systemd is not only more convenient, it's also more simple.

Proof? sysvinit's surface is anything you can call. It's internal state is everything on the system.

Systemd's surface is the (well documented) commands in the systemd unit files. Each unit is pretty much independent, the dependencies are specified and well defined. Their internal state can be examined and explored.

Re: Systemd, ten years later: a historical and technical retrospective

#357

Post by realusername » Mon, May 04, 2020, 2:32 PM UTC

adwn wrote: post #325

realusername wrote: post #136

Earlier quoted context omitted.

Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already. What systemd is doing with this log storage system is reinventing sqlite, because systemd has a fairly new and not battle-tested database implementation, it has shortcomings. I would argue that either they use plain text logs like before or use sqlite but they should not reinvent a new db.

> Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already. That's great, but you've completely ignored theamk's argument that sqlite is the wrong tool for the job.

I don't agree with that argument, sqlite is totally the right tool for the job, it provides consistency, reliability, an api you can query anything upon, transactions, indexing, tools... And fits into files.

You currently can't trust systemd log storage at all, even on my own laptop it manages to have some corruption... Querying is very poor and inefficient, indexing is unreliable... And that's exactly what I expect, building a database is hard.

Re: Systemd, ten years later: a historical and technical retrospective

#358

Post by esarbe » Mon, May 04, 2020, 2:36 PM UTC

josteink wrote: post #245

kelnos wrote: post #208

Earlier quoted context omitted.

I think this subthread is talking about the complexity of a system's implementation, not that of its user interface.

As a user, systemd wins for me hands down, because it is simple to use . That it masks complexity away from me is a feature, not a bug. This is also why distros is implementing it almost everywhere: It makes their job easier. Now if you are measuring the complexity of the system's (full) implementation , you can't really compare systemd to to SysV-init. You need to compare a systemd-based system to a SysV-init based…

Downvoted for truth, I guess?

Re: Systemd, ten years later: a historical and technical retrospective

#359

Post by growse » Mon, May 04, 2020, 2:47 PM UTC

realusername wrote: post #357

adwn wrote: post #325

Earlier quoted context omitted.

> Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already. That's great, but you've completely ignored theamk's argument that sqlite is the wrong tool for the job.

I don't agree with that argument, sqlite is totally the right tool for the job, it provides consistency, reliability, an api you can query anything upon, transactions, indexing, tools... And fits into files. You currently can't trust systemd log storage at all, even on my own laptop it manages to have some corruption... Querying is very poor and inefficient, indexing is unreliable... And that's exactly what I expect,…

SQLite doesn't work reliably on NFS, which rules it out for any PXE-booted system with an NFS root.

Re: Systemd, ten years later: a historical and technical retrospective

#360

Post by btrask » Mon, May 04, 2020, 2:47 PM UTC

vezzy-fnord wrote: post #316

majewsky wrote: post #285

Earlier quoted context omitted.

Honest question: Which relevant technology is ever discussed dispassionately?

If we can't ever perfectly adhere to an ideal, then I guess we ought to go full on with the connivery and deceit, then. Regardless, I did have at least some expectation that people would actually focus on the original post and not brawl in the comment section over tangents that often aren't even part of it. Oh, well. And hey, if other people down the road read this and it makes something click for them, I'll be happy…

Thank you for the article! It's too bad that your conclusion, that systemd doesn't/shouldn't matter, wasn't able to be grasped by the community.