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

Avoiding Complexity with Systemd

mgdm.net

Post reply on HN
Print view View original

291–300 of 357 posts

Re: Avoiding Complexity with Systemd

#291

Post by josephcsible »

yawaramin wrote: post #264
tyingq wrote: post #44

My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation. Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I…

Wow, are people seriously still fussing about this? Systemd made the call to use a more secure default, they should be applauded for it. People who want the insecure way to be the default should take it up with their distro.

How is killing processes when the user "logs out" at all good for security? If the processes were malicious or vulnerable, they could have done their damage or been exploited while the user was still logged in.

Re: Avoiding Complexity with Systemd

#292

Post by josephcsible »

kaba0 wrote: post #154
iso1210 wrote: post #118

Earlier quoted context omitted.

Ouch, what on earth does "log out" even mean? What a terrible way to run any computer other than maybe a single user laptop.

Not sure if sarcastic, but the systemd default makes sense. Why should random processes linger in a background, with an ill defined “not answering a signal” hack? There is no distinction between a frozen process and tmux. They can easily register a user service and continue running there.

Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? That's a well defined, long established, normal way of doing things on UNIX and Linux systems. Also, that really isn't a good way of detecting frozen processes, since in your world, the only answers you'd ever get are "it's frozen" or "it wasn't frozen and now it's dead".

> They can easily register a user service and continue running there.

So systemd came in and broke the 50-year-old way of doing things, and now the programs that got broken should all have to add systemd-specific code to work again?

Re: Avoiding Complexity with Systemd

#293

Post by mcspiff »

WesolyKubeczek wrote: post #289
InvertedRhodium wrote: post #279

Earlier quoted context omitted.

There is still no way to filter application output at collection time, which can functionally make journald useless if you have an application that is too chatty, and will likely never be given that (AFAICT) there is hefty ideological opposition from the systems developers¹. ¹ https://github.com/systemd/systemd/issues/6432

Isn't this something that, to a degree, might be mitigated by rate limiting journald has? IMO Lennart is right in that collection should be optimized to a point where it is (almost) never the bottleneck. I, personally, would put a filtering program between the chatty application and journald.

I generally agree, but will say that’s not always easy if it’s something system level that’s being induced to be too chatty —- you’re stuck replacing the upstream unit’s Exec, which frankly kind of sucks. I’m also trusting the filter to be as reliable, which may or may not be true.

Rate limiting works, but it’s a pretty blunt instrument and can lead to losing your actually valuable entries vs capturing garbage.

Re: Avoiding Complexity with Systemd

#294

Post by mcspiff »

gmmeyer wrote: post #288
mcspiff wrote: post #263

Earlier quoted context omitted.

I’m a big fan of systemd, but we’ve definitely run into actual bugs in it. Especially the early RHEL7 days (7.0-7.3). Some were fixed upstream, some we’ve worked around, etc.

To be clear it definitely used to be more buggy, but I haven't encountered a genuine bug in a long time

Might depend on your environment too, I generally find the newer you can get for systemd the better off you are (which is really quite high praise!). Unfortunately the life cycle for some of our environments is quite long for things like RHEL7 -> RHEL8.

Re: Avoiding Complexity with Systemd

#295

Post by kaba0 »

josephcsible wrote: post #292
kaba0 wrote: post #154

Earlier quoted context omitted.

Not sure if sarcastic, but the systemd default makes sense. Why should random processes linger in a background, with an ill defined “not answering a signal” hack? There is no distinction between a frozen process and tmux. They can easily register a user service and continue running there.

Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? That's a well defined, long established, normal way of doing things on UNIX and Linux systems. Also, that really isn't a good way of detecting frozen processes, since in your world, the only answers you'd ever get are "it's frozen" or "it wasn't frozen and now it's dead". > They can easily register a user…

> Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack?

Yes. Just because it is 50-years-old doesn’t make it suddenly a valid approach. There are 4 states here - process running with usual semantics for closing, process running that would like to linger in the background, and the frozen version of this two. How should a service manager/resource handle — that is very much in-scope for systemd differentiate between a frozen process that should very much be cleaned up in the no-linger case, and any process wanting to linger? And there are well-established ways to determine whether a process is frozen — pinging it expecting a specific answer.

Systemd differentiates between no-linger/linger by introducing user services - one should only write a trivial alias/wrapper script for tmux and can continue to use it to their liking. Also, it has a compile time flag, as well as a runtime config one - it is up to the distro or the user to revert back to the old way.

Re: Avoiding Complexity with Systemd

#296

Post by tyingq »

kaba0 wrote: post #295
josephcsible wrote: post #292

Earlier quoted context omitted.

Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? That's a well defined, long established, normal way of doing things on UNIX and Linux systems. Also, that really isn't a good way of detecting frozen processes, since in your world, the only answers you'd ever get are "it's frozen" or "it wasn't frozen and now it's dead". > They can easily register a user…

> Are you seriously claiming that processes ignoring or handling signals rather than dying is an ill defined hack? Yes. Just because it is 50-years-old doesn’t make it suddenly a valid approach. There are 4 states here - process running with usual semantics for closing, process running that would like to linger in the background, and the frozen version of this two. How should a service manager/resource handle — that…

Is setsid() also a hack?

Re: Avoiding Complexity with Systemd

#297

Post by tyingq »

yawaramin wrote: post #264
tyingq wrote: post #44

My frustration with systemd is that it creeps out over time into other functionality, and that it's difficult to find the right documentation. Like when logind was changed to kill background processes when you log out, by making KillUserProcesses=yes the default. Some Linux distros left that as is, others overrode it in /etc/systemd/logind.conf. So, figuring out what was happening, and how to fix it, was confusing. I…

Wow, are people seriously still fussing about this? Systemd made the call to use a more secure default, they should be applauded for it. People who want the insecure way to be the default should take it up with their distro.

Killing processes that explicitly called setsid() seems wrong to me, yes. It works for every other Unix like system.

And it leaves enough info (process is it's own separate session group) for logind to know it should leave it alone.

Re: Avoiding Complexity with Systemd

#298

Post by TwoNineFive »

boublepop wrote: post #94
birdyrooster wrote: post #62

Earlier quoted context omitted.

Why are we talking like this? We’ve been using systemd for over 5 years. It’s weird. Time loops.

It took 10 years before the “python2 will never die”-crowd finally accepted they where not going to win at that python3 was here to stay. People spend a couple of years getting used to a stack in their early carrier and then spend decades arguing that it should never change.

The problem with your analogy is that while a lot of people did move from python to python 3, a lot also stopped using python all together because the python2/3 split demonstrated that the python devs were willing to throw everyone's work out the window for fun. There was no technical reason why backwards comparability wasn't possible. Multiple good solutions were put forward. They were all rejected for silly reasons.

A lot of that "python2 will never die" crowd left python all together, and they are better off for it because they won't have to deal with the next time python decides to throw everyone's work out the window.

Re: Avoiding Complexity with Systemd

#299

Post by egberts1 »

viraptor wrote: post #97
egberts1 wrote: post #60

Earlier quoted context omitted.

I’ve since moved away from systemd for all my Linux boxes, work and home. We still cannot block systemd from making a network socket connection so security model is shot right there by the virtue of systemd running as a root process. In the old days of systemd, no network sockets were made. Systemd has become a veritable octopus. Now, I use openrc and am evaluating S6.

Selinux can block systemd from making network sockets. What do you mean by "security model" in this case? What model is that?

Systemd is already in root mode. Just need to do malicious buffer overruns … somewhere, somehow … at root level … someday.

And it’s codebase is too ginormously huge.

Re: Avoiding Complexity with Systemd

#300

Post by egberts1 »

lloydatkinson wrote: post #122
viraptor wrote: post #97

Earlier quoted context omitted.

Selinux can block systemd from making network sockets. What do you mean by "security model" in this case? What model is that?

But the solution is for it to not try make the socket rather than needing another system to correct bad behaviour of the first system?

There ye go. Make system process small as efficient, not to mention easily auditable.
Post reply on HN