coredump.conf has Storage=none but files are present in /var/lib/systemd/coredump #2804
Comments
|
Any chance you could provide: ? I think something killed your |
|
Sure: And |
What does Could you attach the output of: ? |
|
Sure I can... just one question about the set-log-level ... how can I tell what log level I am currently using? |
|
|
Thanks! Looking in |
|
Works fine. And my last question:) and ? |
|
Here are the last few lines (I have been debugging an unrelated issue so many reboots today): And |
|
Bingo!:) So, your |
How would one verify that?
I do have: |
source: https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c
I mean, there is no rule in the systemd.conf |
|
Can you help me to summarize these findings from a high level? *My system has not SIGTERM handler and it should. Thanks! |
Sure. You can run this script as a workaround: Low level:
You can reproduce that |
|
..so is my report valid against systemd? If not, what is to blame for the bug? Thanks! |
|
Well, there are three problems:
|
|
Yeah, these are temporary files that systemd-coredump needs while processing the coredumps. Of course, if the coredump service is aborted during the operation we better shouldn't leave those files around. This is hence a bug to fix in our coredumping code. One option would be to use O_TMPFILE if possible (would need a fallback though I figure since older kernels don't have this on all file systems...) or to catch SIGTERM and delete the temporary files... I much prefer the O_TMPFILE option I must say. (also, maybe kernels lacking O_TMPFILE support for the relevant file systems are already older than what we officially support) |
poettering
added
coredump
bug 🐛
|
It got introduced in 3.11 if I'm not mistaken. I think it would be wise to just document and say that the latest systemd release only "supports" the current latest mainline, stable and longterm ( which currently are 4.6.x,4.5.x,4.4.x ) kernels at that systemd version releases time. If you are running latest systemd on other, older kernels then you are on your own ( it might work or not ) and stop worrying which kernel release downstream is using or sticking to. |
|
@johannbg we have such a document, it's called README. It currently requires 3.12. Note though that when O_TMPFILE was added to the kernel it wasn't implemented in all file systems right-away, IIRC. |
|
@poettering no shit sherlock now read again what I proposed not what the README currently says... |
|
From the open(2) manpage: So at least fsfs and reiser do not have that support yet... |
I've checked
So I vote for
|
|
@evverx yes, of course :) |
|
another option is to simply use O_TMPFILE, and when it is not available fall back to the current behaviour. After all, the files are cleaned up eventually, through normal tmpfiles aging, and the offending file systems are pretty exotic these days, or not in the upstream kernel... Hence, if we are robust on modern kernels/file systems, and still work reasonably well on everything else, then I think we are good. |
Don't leave temporary files if the coredump service is aborted during the operation Yeah, these are temporary files that systemd-coredump needs while processing the coredumps. Of course, if the coredump service is aborted during the operation we better shouldn't leave those files around. This is hence a bug to fix in our coredumping code. See systemd#2804 (comment) Another option is to simply use O_TMPFILE, and when it is not available fall back to the current behaviour. After all, the files are cleaned up eventually, through normal tmpfiles aging, and the offending file systems are pretty exotic these days, or not in the upstream kernel. See systemd#2804 (comment)
|
Makes sense. Please have a look #3065 |
Don't leave temporary files if the coredump service is aborted during the operation Yeah, these are temporary files that systemd-coredump needs while processing the coredumps. Of course, if the coredump service is aborted during the operation we better shouldn't leave those files around. This is hence a bug to fix in our coredumping code. See #2804 (comment) Another option is to simply use O_TMPFILE, and when it is not available fall back to the current behaviour. After all, the files are cleaned up eventually, through normal tmpfiles aging, and the offending file systems are pretty exotic these days, or not in the upstream kernel. See #2804 (comment)
|
OK, #3065 got merged now, closing this one now. This should settle things on pretty much all mainstream file systems on current kernels. If you have an exotic fs, or an older kernel, then we will still create these temporary files that might survive if the coredumping process is aborted, but given that the tmpfiles aging logic will get rid of them eventually I think we are good. |
|
Why is systemd-coredump writing anything at all to disk, if (Sorry to post on an old closed bug, but it sounds very strange and a waste of resources.) |
Submission type
systemd version the issue has been seen with
Used distribution
Description of bug
I have
/etc/systemd/coredump.confconfigured not to store coredump files (Storage=none) but I have dot files under the default external storage directory:The text was updated successfully, but these errors were encountered: