Live data from Hacker News

Systemd Linger

etbe.coker.com.au

21–30 of 96 posts

Re: Systemd Linger

#21
I never had a problem with systemd init despite its quirky habits like just giving up if a mount is bad in fstab, and I rather like systemd-networkd over the other four or five ways of managing the network. Systemd-timesyncd isn’t bad either.

But this, systemd-logind worrying about stuck processes in userspace is exactly the kind of scope creep that ends up justifying a lot of the hand wringing a decade ago. This thing bit me when it came out in a couple different ways and I am unapologetic in my dislike for it. So much so that it has caused me to drift away from Linux where I can. Even though it is a simple fix, I’ve become fatigued with userspace chaos.

Time to re-evaluate what the bazaar has become. Systemd is a common complaint, but it isn’t the only contributor to the fatigue.

Re: Systemd Linger

#22
post #2

This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.

It's one of those systemd features that are annoying and in the way when you're trying to accomplish a specific task but deal well with shitware. To be fair to systemd, these features can't usually be implemented without writing new rules for what you have to do to accomplish the legitimate tasks.

Re: Systemd Linger

#23
post #2

This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.

In my experience, systemd is much better documented, way more consistent, and way more reliable than what came before.

So, I disagree about your statement here, but let's for a moment assume it were correct - so let's not evaluate THAT particular statement, thus.

You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts?

Shell scripts in general are crap. I don't understand why linux systems use them. When I transitioned to linux a long time ago, I wrote - and still write - pretty much all logic in ruby and .yml files. Literally my whole system is described via .yml files, ruby then just auto-expands all of this into what is meaningful. I also compile from source and manage the system via ruby as-is, so I don't even need systemd, nor shell scripts. But this is just one comment here and if you refer to shell scripts then I agree with you - shell scripts have always been horrible. I fail to see why we should like systemd merely because shell scripts are so awful. That makes no sense. I neither use systemd nor shell scripts (ok ok I bail ... I am currently using manjaro which uses systemd; I disabled most of the services, but the primary reason I was assimilated into systemd is mostly because the non-systemd linux distributions, kind of gave up for the most part or come with their own set of problems - slackware, void and so forth. And yeah, I was using and testing them for ages too, slackware I used for many, many years. It is still a great distribution but it is not really active anymore. No new .iso releases in years, sorry, that is dead. Even if Patrick still updates packages.)

The other part is ... IF you referred to an alternative init system, then THAT comparison is flawed too, because sysvinit is mostly just an init system. Systemd is some giant thing that does 100000 things. So the comparison is, and ALWAYS has been, unfair. Not the same things are compared here.

Re: Systemd Linger

#24
post #8
post #5

Earlier quoted context omitted.

I guess it depends on your source of info but I've found what came before was pretty comprehensively & accessibly documented, at least as well as systemd, which - while well documented - suffers from sprawl & overwhelm of the docs. There's just SO MUCH to grok in comparison.

Absolutely not the case. Even relatively simple real world uses involved collections of shell scripts to carefully mount or initialize services in just the right order and would often fail with weird and infrequent timing glitches. With systemd that all becomes explicit, so of course it is awkwardly verbose. That is the whole point and a huge upgrade.

I never used shell scripts for that. Ruby worked much better and easier. No glitches either.

I also fail to see how verbosity is a "huge upgrade".

Re: Systemd Linger

#25
post #16
post #13

Earlier quoted context omitted.

You can detach from screen/tmux, leave it running in the background, and log back in later to the same screen/tmux like you left it. Except systemd can kill it when you log out, so you come back to nothing.

Ah ok. Seems like the log out metaphor is kind of broken then? It seems to me if you want persistence between logouts, the processes should belong to a different group/user. (I'm spitballing hypotheticalshere, not saying anyone/thing in particular is wrong)

Think about user services in a multi-user setup

Do you want user-level services, or a multi-tenant system-level service? - Who can tweak the service configuration? - How do you ensure there's no data leaks between users? - What about misbehaviour? Quotas, crashes

I think lingering is great here

Re: Systemd Linger

#27
post #2

This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.

> Things not working the way I expect means I have to do more work to figure something out.

You must love SELinux

Re: Systemd Linger

#29

Earlier quoted context omitted.

In my experience, systemd is much better documented, way more consistent, and way more reliable than what came before.

So, I disagree about your statement here, but let's for a moment assume it were correct - so let's not evaluate THAT particular statement, thus. You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts? Shell scripts in general are crap. I don't understand why linux systems use them. When I transitioned to linux a long time ago, I wrote - and still write…

Systemd is not 1 giant thing that does 100000 things - it is a collection or 10000 services doing 10000 things, integrating amongst themselves where practical. You need not use networkd, logind, resolved or any other one piece of the system you dislike.

Re: Systemd Linger

#30
post #9
post #5

Earlier quoted context omitted.

I guess it depends on your source of info but I've found what came before was pretty comprehensively & accessibly documented, at least as well as systemd, which - while well documented - suffers from sprawl & overwhelm of the docs. There's just SO MUCH to grok in comparison.

I never found systemd difficult, but I do find prior solutions to be simpler. An init script is easy, and the order is also easy. If people are accustomed to UNIX systems, the sysvinit is better. For people who never experienced those systems, systemd is their friend. No need to use UNIX tools when Systemd ships with batteries included.

Yeah, init scripts are simple, but things get tricky outside of the happy path. Think of service upgrades/restarts. Once you care about dependencies, then you are back to a graph like systemd's.
Post reply on HN