21–30 of 52 posts
Quite disappointing someone would enable that kernel option without fully considering the ramifications :/. Do some distributions use systemd-coredump by default? I not just learned about systemd-coredump and I'm wondering if it could be actually useful for develoment purposes; apport doesn't seem to be.
Earlier quoted context omitted.
You can turn the situation around: Pick some non-systemd OS, stick to it, and avoid software that does not run on it. You will end up with the old and boring tech, but it will be robust and run more reliable in the long term. I've been running Alpine Linux in production for 4 years now.
Unfortunately systemd & glibc (or even macOS) are usually the more pragmatic choice. I'd love to have the freedom to ignore them, but even outside of work, there is software (like games) that I want to run that doesn't play nice with anything more sane.
Quite disappointing someone would enable that kernel option without fully considering the ramifications :/. Do some distributions use systemd-coredump by default? I not just learned about systemd-coredump and I'm wondering if it could be actually useful for develoment purposes; apport doesn't seem to be.
systemd-coredump is honestly incredibly useful. Any time an application randomly crashes in the background, you can easily pop it in a debugger to look through the backtrace without having to re-run it. Very handy for when the crashes are not easily reproducible, or you didn't expect something to fail and are not sure how to make it fail again.
Several setups of ours rely on that fact, and since we're developing software that is supposed to work on Linux and {Free,Open,Net}BSD, we were happy to be able to reuse a bunch of crash-capture logic.
systemd kneecapped us out of the blue, it took us some time to figure out where the coredumps were going. Now we disable systemd-coredump on all systems. Which works, except when something reenables it or we add a new platform and someone forgets to disable it. Sigh.
Yes, we can deal with it, by disabling it. But crash captures went from being reliable to "did systemd-coredump creep back in?" - a definite regression.
The normal way I use machines these days is that anyone with login access has some ability to become root. But anyone who is hosting shellboxes (including "bastion" hosts in ISO27001 environments): this is pretty serious.
I'll bet you don't. The natural extension of that logic is that you don't bother with UID separation for running processes (since you don't believe it provides any protection), so for convenience all your software runs as root and all your ssh logins are directly to root, etc... No one does that, and I'll bet anything you don't either. In fact the Unix uid/gid does provide real security value in practice. It is not a…
> I'll bet you don't
I'll... bet they do? You realize that description most trivially matches "I give people sudo access", right?
So they say they do something and you promptly say that you don't think they do that, because "nobody" does a more extreme version of the same idea that they never suggested? That's a classic straw man.
Earlier quoted context omitted.
systemd-coredump is honestly incredibly useful. Any time an application randomly crashes in the background, you can easily pop it in a debugger to look through the backtrace without having to re-run it. Very handy for when the crashes are not easily reproducible, or you didn't expect something to fail and are not sure how to make it fail again.
It's also incredibly annoying, because it changes longstanding cross-platform common behavior regarding this exact functionality. "A coredump is written to the crashing process's current working directory, named 'core' or 'core. '" - that used to be true on Linux and all the BSDs. Several setups of ours rely on that fact, and since we're developing software that is supposed to work on Linux and {Free,Open,Net}BSD, we…
Have you tried masking it? (https://www.freedesktop.org/software/systemd/man/systemctl.h...)
Earlier quoted context omitted.
I'll bet you don't. The natural extension of that logic is that you don't bother with UID separation for running processes (since you don't believe it provides any protection), so for convenience all your software runs as root and all your ssh logins are directly to root, etc... No one does that, and I'll bet anything you don't either. In fact the Unix uid/gid does provide real security value in practice. It is not a…
>> The normal way I use machines these days is that anyone with login access has some ability to become root. > I'll bet you don't I'll... bet they do? You realize that description most trivially matches "I give people sudo access", right? So they say they do something and you promptly say that you don't think they do that, because "nobody" does a more extreme version of the same idea that they never suggested? That'…
Earlier quoted context omitted.
>> The normal way I use machines these days is that anyone with login access has some ability to become root. > I'll bet you don't I'll... bet they do? You realize that description most trivially matches "I give people sudo access", right? So they say they do something and you promptly say that you don't think they do that, because "nobody" does a more extreme version of the same idea that they never suggested? That'…
That seems like a maximally uncharitable way of interpreting what I thought was a pretty uncontroversial point. The point was that when deploying software for use, best practice says "don't run it as root", and not "assume all software has root access". Do you really disagree? Because the grandparent poster definitely seems to, and I think that's pretty clearly wrong.
Earlier quoted context omitted.
systemd-coredump is honestly incredibly useful. Any time an application randomly crashes in the background, you can easily pop it in a debugger to look through the backtrace without having to re-run it. Very handy for when the crashes are not easily reproducible, or you didn't expect something to fail and are not sure how to make it fail again.
It's also incredibly annoying, because it changes longstanding cross-platform common behavior regarding this exact functionality. "A coredump is written to the crashing process's current working directory, named 'core' or 'core. '" - that used to be true on Linux and all the BSDs. Several setups of ours rely on that fact, and since we're developing software that is supposed to work on Linux and {Free,Open,Net}BSD, we…
Earlier quoted context omitted.
systemd-coredump is honestly incredibly useful. Any time an application randomly crashes in the background, you can easily pop it in a debugger to look through the backtrace without having to re-run it. Very handy for when the crashes are not easily reproducible, or you didn't expect something to fail and are not sure how to make it fail again.
It's also incredibly annoying, because it changes longstanding cross-platform common behavior regarding this exact functionality. "A coredump is written to the crashing process's current working directory, named 'core' or 'core. '" - that used to be true on Linux and all the BSDs. Several setups of ours rely on that fact, and since we're developing software that is supposed to work on Linux and {Free,Open,Net}BSD, we…
At least in Debian and Ubuntu systemd-coredump is a separate package (and wasn't installed by default for me atleast), so I expect you can just remove it and it doesn't get automatically enabled in any way.