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

51–60 of 96 posts

Re: Systemd Linger

#51

Post by graemep »

qweqwe14 wrote: post #10
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 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…

You are framing this as the only choice being between systemd and shell scripts.

Re: Systemd Linger

#52

Post by yjftsjthsd-h »

qweqwe14 wrote: post #10
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 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…

> "The way you expect" is probably inconsistent and, upon closer inspection, completely broken.

When I start a program, I want it to stay running. This is perfectly consistent and not broken.

Re: Systemd Linger

#53

Post by c-hendricks »

tux3 wrote: post #13
benj111 wrote: post #12

I'm presumably missing something here. Why does tmux et al not work? Remotely? Ie you're logged in locally and remotely to the same machine, log out locally which kills everything running remotely, but then why would you log in twice like that? And that being the case can systemd not just only close everything when your logins reach 0?

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.

What I don't get is why (on Arch) I have linger off yet have never had trouble with tmux/ zellij being killed.

Edit: ah, this post clears it up. Mentions linger has nothing to do with screen muxers, and also brings KillUserProcesses to peoples attention.

Damn systemd and its multiple levels of convenience.

Re: Systemd Linger

#54

Post by po1nt »

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

> hydraulic press What is there to know? It goes up and down, and don't stick your arm inside...

Until it breaks, reports error, leaks, makes weird sound, needs a maintenance or even if you want to move it. You need to know how heavy it is, where are mounting points, where is the center of gravity, what needs to be affixed etc. What is the power it draws for the pump, what is the peak power and how long is the peak, what is the power factor? Does it have a safety certification, what kind of training operator needs, are safety elements up to date to modern standard? What kind of fire extinguisher do you need? What is the toxicity of all the materials under normal and extreme conditions? What kind of peak force is applied to floor and how is it distributed?

Re: Systemd Linger

#55

Post by halJordan »

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.

I, for one, appreciate the honesty. I wish more systemd haters would admit this is why they dislike it. We could finally throw away the tired arguments that have been disproven in the past ten years

Re: Systemd Linger

#56

Post by po1nt »

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.

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.

Re: Systemd Linger

#57

Post by NekkoDroid »

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.

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

I dunno, "things not working the way I expect" is very subjective.

I personally think it makes more sense that processes do not outlive the parent from which they come (in this case processes spawned from a user shouldn't outlive that user) unless you explicitly go through something which outlive the parent (process manager in this case (e.g. running via systemd-run)).

Though I am also strongly of the opinion of just because something is a feature, does not mean it is good to keep around, e.g SUID/SGID (which has a similar "I get more than the parent" problem).

Though I guess different people can have different opinions/values on this.

Re: Systemd Linger

#58

Post by rnhmjoj »

iririririr wrote: post #43
7bit wrote: post #41

Earlier quoted context omitted.

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.

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.

Also, the fact that all components are in the same repository and need to be built together causes a lot of headaches with packaging due to dependency cycles (like, systemd -> cryptsetup -> lvm2 -> udev -> systemd).

Re: Systemd Linger

#59

Post by jamespo »

iririririr wrote: post #42
dietr1ch wrote: post #30

Earlier quoted context omitted.

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 solu…

How are hacky init scripts written in shellscript well documented? Can you point me to this documentation?

When are the init systems going to implement the basic security measures systemd has?

Re: Systemd Linger

#60

Post by jamespo »

shevy-java wrote: post #24
m0llusk wrote: post #8

Earlier quoted context omitted.

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

So your systems have a dependency on ruby to startup and anyone who maintains it has to know ruby?
Post reply on HN