[pgpool-general: 9145] Re: Another segmentation fault

Emond Papegaaij emond.papegaaij at gmail.com
Fri Jun 21 17:10:12 JST 2024


Op vr 21 jun 2024 om 09:23 schreef Tatsuo Ishii <ishii at sraoss.co.jp>:

> > You are right that in 14136 several processes segfaulted. I'm not sure if
> > the coredump was for pid 15 (you might be able to find the correct pid
> > using the timestamp from the coredump), but I've noticed in the cases
> where
> > several processes segfault in just a few seconds, the crashes are almost
> > always the same. Therefore I didn't include the other coredumps, as they
> > will give you the same backtrace and variables.
>
> On my Linux (Ubuntu 20) there's a file which controls the core dump
> file name.
>
> cat /proc/sys/kernel/core_pattern
> |/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E
>
> Is it possible for you to include pid in core file name?
>

I think it already does. Almalinux uses systemd-coredump for this, and from
what I can find, the number before the timestamp is the PID. However, this
is the PID as seen by the kernel, not the PID as seen by the process
itself, as pgpool runs inside a docker container. This is why the main
pgpool process always reports PID 1 for us. I don't think there is a way to
get the PID from inside the container in the name of the dump. If we get
another crash with multiple segmentation faults, I'll use the timestamps to
get the first, so you can be pretty sure which PID it was the coredump
belongs to.

BTW, I have pushed fix_segfault2.patch and fix_main_node_id.patch.
>

Great to hear! I'm glad to be of help in fixing these issues. Thank you for
the great support!

Best regards,
Emond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20240621/2f48af70/attachment.htm>


More information about the pgpool-general mailing list