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

Systemd Linger

etbe.coker.com.au

Post reply on HN
Print view View original

71–80 of 96 posts

Re: Systemd Linger

#71

Post by preg_match »

rnhmjoj wrote: post #58
iririririr wrote: post #43

Earlier quoted context omitted.

that's wrong in the sense it won't be useful for anything unless you have a dozen of those small things setup in the very specific way the author envisioned you set them up. you seem to be repeating all the marketing, while mentioning in other comments you never understood any init system. i don't think you're the authority to be adding so many comments here.

Yes, systemd not being a monolith is a myth. You can forward logs to rsyslog or something, but you really can't disable systemd-journald. Technically you don't need to run systemd-boot, you can use grub or something else, but then bootctl and systemd kexec stop working. You don't need to run dbus, but if you don't several systemd features break, and it's not even documented what needs it. The list goes on and on. Als…

Systemd is literally not a monolith because it's not one big piece of software. It's a collection of software. For example, systemd-boot has basically nothing to do with systemd-init.

Yes, some software is more tightly coupled than others, naturally. systemd-init and systemd-journald work tightly together because logging is a core requirement of any init system.

Re: Systemd Linger

#72

Post by preg_match »

dosisking wrote: post #37
Hendrikto wrote: post #3

Earlier quoted context omitted.

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

Well, in my experience, systemd has much worse documentation, is very inconsistent (or you could say it is constistantly brain-dead), and extremely unreliable and unpredictable, since it often hangs when shutting down and rebooting.

In my experience hangs usually happen from no time limits on units or excessively long time limits. I fried a NIC a while back and network-manager-wait-online has no time limit. Usually this isn't a problem, but the NIC was fried in a very unique way where it would continuously try to connect and then downgrade connections.

The bright side is this is all logged, trivially grep-able, and easy to fix.

Re: Systemd Linger

#73

Post by preg_match »

graemep wrote: post #50
Someone wrote: post #17

Earlier quoted context omitted.

> This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out. Even if the change is a genuine improvement?

This is not a genuine improvement: > One of the features of systemd that is most controversial is the option to kill user processes when the user logs out. That initially killed screen/tmux/nohup processes too. Killing processes that the user clearly did not want killed is a regression. Reading the rest of article it seems that its fixed but made things a lot more complicated than "unless you deliberately start thing…

I don't think it's a regression at all. It's been standard advice for decades that logout-login wipes user processes for updates, therefore you don't need to restart.

I'd argue the opposite is true: linger is surprising, and I turn it off.

Re: Systemd Linger

#75

Post by cwillu »

jauntywundrkind wrote: post #62
lucideer wrote: 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.

We can argue about which has better docs, but, to me, systems offers a uniformity of practices and a consistency of service offerings that was never the case before. Ever company used to have to make its own decisions about what logging solution to use. Each one had its own configuration paradigms! Every single daemon had some kind of bespoke /etc/init.d/ script that had its own rules and practices, having either for…

Days since my last exposure to “I'm sorry, you're absolutely right, that's wrong”: 1

Re: Systemd Linger

#76

Post by po1nt »

preg_match wrote: post #70
po1nt wrote: post #56

Earlier quoted context omitted.

Just the PID 1 manager is multiple times larger in LoC than any alternative. There is no metric in which systemd is more lightweight that I could find.

I'm not sure this is true in practice, if we're counting init scripts themselves. Which we should, because init scripts are code and they often re-implement standard systemd features. Usually in wonky, broken ways.

I think that even if we count init scripts which are way different level of complexity than C LoC, the Systemd would still be larger. Especially if we count just the scripts that are deployed.

Re: Systemd Linger

#77

Post by otabdeveloper4 »

BirAdam wrote: post #9
lucideer wrote: 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.

> An init script is easy

Oh boy. Lmao.

Re: Systemd Linger

#78

Post by jauntywundrkind »

M95D wrote: post #66
jauntywundrkind wrote: post #62

Earlier quoted context omitted.

We can argue about which has better docs, but, to me, systems offers a uniformity of practices and a consistency of service offerings that was never the case before. Ever company used to have to make its own decisions about what logging solution to use. Each one had its own configuration paradigms! Every single daemon had some kind of bespoke /etc/init.d/ script that had its own rules and practices, having either for…

> Ever company used to have to make its own decisions about what logging solution to use. Each one had its own configuration paradigms! Every single daemon had some kind of bespoke /etc/init.d/ script that had its own rules and practices, having either forked off some other skeleton or having been made on it's own at some point. > And then companies wanted to do the right thing and apply some capabilities restriction…

> IMHO, any competent sysadmin, when is installing the system, would edit all those templates into the exact shape the system and the user needs

That, IMHO, is the other 90% of the problem (to riff on the ninety-ninety rule).

Every competent sysadmin has their own particular style & preferences & opinions about what the exact shape should be. And will go rewrite the world, according to some particular set of tastes, that they usually won't write down or document or socialize.

So not only do you have to figure out all the special sauce in how the service you just walked in to is managed, you have to wade through a complete re-architecting that some sysop made on their own judgement 5 years ago that people have patched and hacked since.

You can keep adapting to these scenarios. But to me, the normativity, the incredibly great toolkit of options it comes with: yes it's sizable, but it's one thing that I have to learn, that is usually a direct representation of something the kernel gives me, that will then be familiar and portable and useful wherever I go. This feels so much more civilized than what came before.

Re: Systemd Linger

#79

Post by egorfine »

Hendrikto wrote: post #3
graemep wrote: 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.

This has never been my experience for the whole duration of the systemd existence.

Re: Systemd Linger

#80

Post by egorfine »

Someone wrote: post #17
graemep wrote: 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.

> This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out. Even if the change is a genuine improvement?

Yes. Improvement or not, a thing not working the way one expects means one has to do more work to figure something out. And in case of pid1, this is never a time spent productively.

I'm all for improvements and I love updates of software, but what systemd usually does is ideology and destruction in the name of "new". Like, we have had cron perfectly working for _decades_ until one man told us we were all wrong on that.

Post reply on HN