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

41–50 of 96 posts

Re: Systemd Linger

#41

Post by 7bit »

po1nt wrote: post #6
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.

Maybe, but the scale of systemd features is humongous. It better be well documented. You don't need a user manual for hammer, you do need one for hydraulic press.

The scale is humongous? Syszemd is not one big thing. It's a collection of small things, each meticoulsouy documented and you can pick and choose.

If you still think there is only one Systemd, maybe learn about the tool instead of just talking others after their mouth.

Re: Systemd Linger

#42

Post by iririririr »

dietr1ch wrote: post #30
BirAdam wrote: post #9

Earlier quoted context omitted.

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.

talking "outside happy path" in defense of systemd is wild. because that's it's Achilles heel.

systemd is awfully documented (volume is not quality), things are still changing and haven't even caught up in functionality with any init hack.

the only saving grace of systemd is that it almost makes it easier to use namespace and other sandbox (but only because those are newer and init systems also didn't have their solutions up yet)

systemd only purpose is to mimic windows administration in linux. sorry of anyone who fails to see this

Re: Systemd Linger

#43

Post by iririririr »

7bit wrote: post #41
po1nt wrote: post #6

Earlier quoted context omitted.

Maybe, but the scale of systemd features is humongous. It better be well documented. You don't need a user manual for hammer, you do need one for hydraulic press.

The scale is humongous? Syszemd is not one big thing. It's a collection of small things, each meticoulsouy documented and you can pick and choose. If you still think there is only one Systemd, maybe learn about the tool instead of just talking others after their mouth.

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.

Re: Systemd Linger

#44

Post by qweqwe14 »

dosisking wrote: post #34
qweqwe14 wrote: post #10

Earlier quoted context omitted.

"The way you expect" is probably inconsistent and, upon closer inspection, completely broken. There is a reason why systemd became the default and other niche init systems have faded into obscurity. Sure, it may be more complex than your pile of shell scripts, but that's because it does the same things better, and has a lot more functionality that you will need at some point, and good luck replicating that by hacking…

> There is a reason why systemd became the default and other niche init systems have faded into obscurity. Yes, it is part of the Embrace, Extend, Extinguish strategy

No, it is part of the "I just want stuff to work" strategy

Re: Systemd Linger

#45

Post by yjftsjthsd-h »

walrus01 wrote: post #15

Default Debian Trixie out of the box configuration without changing any systemd config file allows gnu screen to work as it always has. There would have been great uproar and screeching if basic 'screen' detach and resume functionality had broken anywhere between Debian v11, v12 and v13, and it has not. I'm assuming this is same for tmux but hasn't tested it. Is there some major distro out there that has the config f…

> Is there some major distro out there that has the config flag set the opposite of this by default?

It bit me on pop os (the Ubuntu derivative)

Re: Systemd Linger

#46

Post by yjftsjthsd-h »

eptcyka wrote: post #29
shevy-java wrote: post #23

Earlier quoted context omitted.

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.

My least favorite part is journald. When you find a way to rip that out, let me know.

Also logind is so hard to avoid that even other systems have ported it: https://wiki.alpinelinux.org/wiki/Elogind

Re: Systemd Linger

#47

Post by benj111 »

dietr1ch wrote: post #25
benj111 wrote: post #16

Earlier quoted context omitted.

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

Off the top of my head. Have a group that doesn't die on logout. So you can have an email Daemon that responds with out of office. And you tmux session can keep running?

I'm not necessarily talking about the Unix concept of a group. It seems to me you want some granularity between 'kill all processes' and 'keep all processes'

Re: Systemd Linger

#48

Post by yjftsjthsd-h »

shevy-java wrote: post #23
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.

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…

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

dinit is a good service manager that doesn't feel obligated to reinvent the kitchen sink

Re: Systemd Linger

#49

Post by yjftsjthsd-h »

ChocolateGod wrote: post #4
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.

The fault lies in the distribution for it's default configuration, not systemd. The article even mentions that distros ship with it turned off

The fault lies in the upstream defaulting the option on, so that distros have to

Re: Systemd Linger

#50

Post by graemep »

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?

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 things so that they keep running when you logout they will be killed when you logout". Am I wrong?

Post reply on HN