Cores names in /tmp

[travankor]

I don't know if this is an issue per se, but I noticed that the name of core files will show up in /tmp as empty files and stay there indefinitely.

I did not have time to investigate this, unfortunately.

[Cogitri]

Thanks for the issue!

When exactly does this occur? During normal operation or when you execute a subcommand?

[travankor]

This appears to occur when a corefile is collected and under certain additional conditions that I do not fully understand yet.

I think this happens when corecollector can not collect another crashing program at the same time, but I don't understand this entirely.

The empty file is owned by the current user and the file is in the same timestamp format as in /var/lib/corecollector.

I'm not sure how to debug corecollector during runtime.

[Cogitri]

Ah okay, I'll look into that, thanks for the additional information :)

I'm not sure how to debug corecollector during runtime.

You could set a logPath in /etc/corecollector/corecollector.conf, corecollector will dump a trace log into that if you set enableDebug to true.

[travankor]

You could set a logPath in /etc/corecollector/corecollector.conf, corecollector will dump a trace log into that if you set enableDebug to true.

I tried this, but there is no output in the log file. The file is owned by root and it is empty. I deleted the file and restarted to double check this behavior.

[Cogitri]

Sorry that it took so long for me to reply!

I tried this, but there is no output in the log file. The file is owned by root and it is empty. I deleted the file and restarted to double check this behavior.

Oh huh, apparently it only writes to that file (with debugging info) if enableDebug is false. Thanks for checking! :)
It should work for now if you set enableDebug to false (and corecollector logs to syslog).

I don't really know how a corefile would end up in /tmp, since corecollector writes the files directly from stdin, but I'll look into it.

I'm not sure how to debug corecollector during runtime.

As unsatisfiying as it is, the only ways to debug are:

• Make something SIGSEGV (or similar) so a coredump is collected and check what happened
• Manually invoke /usr/libexec/corecollector/corehelper with root permissions and the right parameters and any file to it via cat.

[Cogitri]

Oh huh, apparently it only writes to that file (with debugging info) if enableDebug is false

Ah no, the logic about enabling debugging was the wrong way around: If debugging was enabled it logged only warnings, if it was disabled it went into debug mode.

[travankor]

Sorry that it took so long for me to reply!

Sorry for the delay, too :)

I don't really know how a corefile would end up in /tmp, since corecollector writes the files directly from stdin, but I'll look into it.

The corefile doesn't end up in /tmp, but an emtpy file owned by the current user shows up there, e.g sway-11-23426-1000-1000-20200418T2007282a2e2721-e229-50e5-a8b0-2817fbb34de7

Here's the log

[Cogitri]

The corefile doesn't end up in /tmp, but an emtpy file owned by the current user shows up there, e.g sway-11-23426-1000-1000-20200418T2007282a2e2721-e229-50e5-a8b0-2817fbb34de7

Hm, weird, I can't reproduce this 🤔 . The only time corecollector accesses a temporary directory is when a core is compressed and it generates a backtrace for a core/goes into debug mode via gdb or dumps the core. And for the former two subcommands it should clean up after itself.

To clarify: This happens during normal operation when corecollector collects cores and not after invoking some subcommand?

Here's the log

Hm, that seems to be for dinit and not for sway though. Did a file for dinit show up as well?

[travankor]

To clarify: This happens during normal operation when corecollector collects cores and not after invoking some subcommand?

This happens after multiple programs get a crash signal (happens with sway a lot for example). Not everything that crashes gets collected, but this happens without corecollector, too. (examplekernel.core_pattern points to some directory)

Hm, that seems to be for dinit and not for sway though. Did a file for dinit show up as well?

No, it seems like some core files are not generated. I wonder if this problem is related to corecollector, the kernel's corefile collection, or something weird with sway?

BTW this doesn't happen with systemd-coredump, so I will have to investigate this more.

[Cogitri]

No, it seems like some core files are not generated. I wonder if this problem is related to corecollector, the kernel's corefile collection, or something weird with sway?

I think this is on corecollector, it'd surprise me if another application used the exact same naming scheme as corecollector does

[st3r4g]

I can reproduce this too.

The only time corecollector accesses a temporary directory is when a core is compressed and it generates a backtrace for a core/goes into debug mode via gdb or dumps the core. And for the former two subcommands it should clean up after itself.

Indeed, for me this happens on corectl debug <id> and corectl backtrace <id>. These commands leave an empty file in /tmp, which has the same name as the core being analyzed. So it looks like corecollector is not cleaning up properly?