[eqvinox]

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

[pengaru]

It's not like it was ever a safe assumption to blindly dump core to a process' CWD. It was just a convenient option in a developer-centric UNIX mindset, in lieu of anything better.

Sometimes daemons run with a CWD changed somewhere rarely if ever written to at runtime, and presumed to primarily contain information intended for sharing. It's not hard to imagine a security-conscious daemon that's done both chroot() and chdir() into a path intended for publishing information out of, and not generally intended for the daemon to write into except by privileged users/publishers.

When that daemon spuriously dumps core into its CWD now you have potentially sensitive information sitting in the published tree, e.g. maybe the credentials of the privileged users are in that core file.

[Spivak]

I really don’t get why people are so quick to jump on “it changed so it’s bad.” systemd-coredump has to work in every possible case and is dealing with every unhappy path you can imagine. The kernel has a laundry list of situations where core files can’t be saved and systemd made the choice to set it up so some of the failure modes can’t happen.

If they just tried to write to cwd there would be a blogpost about “systemd loses coredumps if your app directory is read-only” which isn’t some theoretical problem, it’s containers.

There was no way to really win here.

[eqvinox]

> I really don’t get why people are so quick to jump on “it changed so it’s bad.”

That's not actually the issue here. Rather: "it changed so now it's inconsistent across platforms"

> There was no way to really win here.

There is:

- if you're changing a multi-platform standard, include the other platforms (e.g. create a coredumpctl tool for *BSD)

- do the changes slowly/incrementally in a backwards-compatible way (e.g. apply the new coredump locations first to read-only containers and service daemons running as systemd units)

[WastingMyTime89]

- It's not a multi-platform standard more a happy accident of history.

- The BSD are irrelevant. Why hamper Linux development to cater for users who don't exist?

[pjmlp]

Forgetting about Aix, HP-UX,....?

It isn't as if it worked the same everywhere anyway.

[jeltz]

That default unix way is very annoying. I want all my core dumps collected in one place so I can easily monitor for new core dumps and easily find them. I do not want to have too search for them. The tool does not have to be systemd-coredump but it is good enough for the job.

[_flux]

Well, the used-to-be-true logic also resulted in scripts to find where there were core files, to remove them :).

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.

[ciupicri]

> except when something reenables it

Have you tried masking it? (https://www.freedesktop.org/software/systemd/man/systemctl.h...)