<div dir="ltr"><div dir="ltr">Op vr 21 jun 2024 om 11:12 schreef Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> On my Linux (Ubuntu 20) there's a file which controls the core dump<br>
>> file name.<br>
>><br>
>> cat /proc/sys/kernel/core_pattern<br>
>> |/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E<br>
>><br>
>> Is it possible for you to include pid in core file name?<br>
>><br>
> <br>
> I think it already does. Almalinux uses systemd-coredump for this, and from<br>
> what I can find, the number before the timestamp is the PID.<br>
<br>
Which part of the file name is the timestamp?<br>
<br>
core.pgpool.208.d678e2ac33af434981c93683b6c42020.102976.1718650919000000<br></blockquote><div><br></div><div>The last part is the timestamp (1718650919000000 in this case). This is the best source I could find about the filename used by systemd-coredump (the source code never lies) <a href="https://github.com/systemd/systemd/blob/main/src/coredump/coredump.c#L317">https://github.com/systemd/systemd/blob/main/src/coredump/coredump.c#L317</a></div><div>That would make 102976 the PID. I don't know about the value 208 and the large hexvalue in the middle.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I don't think there is a way to<br>
> get the PID from inside the container in the name of the dump. If we get<br>
> another crash with multiple segmentation faults, I'll use the timestamps to<br>
> get the first, so you can be pretty sure which PID it was the coredump<br>
> belongs to.<br>
<br>
What about adding a global variable to pgpool which holds the PID of<br>
the pgpool child process?<br></blockquote><div><br></div><div>That would work, but using the order to match the dumps with the PIDs isn't that hard either. Also, the relative ordering of the PIDs is the same for the coredumps and what's reported in the logs. In fact, often (if not always), the offset is the same for all processes. For example, for the log from 14136, the PID in the filename is 5117 higher than the PID in the log. So the coredump attached to the mail, with PID 5129, was for PID 12. This also matches with the timestamp from the coredump (1718739212000000 = 21:33:32 CEST) and the crash in the log: 2024-06-18 21:33:33: pid 1: WARNING:  child process with pid: 12 was terminated by segmentation fault.</div><div> </div><div>Best regards,</div><div>Emond</div></div></div>