systemd-coredump in distros

systemd-coredump in distros

[Andreas Arnez]

It seems common for new distros to install systemd-coredump by default
and disable core files in the current working directory.  For instance,
see the announcement "Enable systemd-coredump by default" for Fedora 26
(https://fedoraproject.org/wiki/Changes/coredumpctl).

Is there a recommended/preferred way to deal with this in a typical
development use case?  I stumbled upon some issues with systemd-coredump
and don't know if I misunderstood something:

* In my tests, after invoking a command that dumps core, it could happen
  that "coredumpctl" failed immediately afterwards and succeeded a
  second later -- maybe due to asynchronous processing?

* There does not seem to be a way for a user to remove core dumps from
  the journal.  Thus a developer's experiment may pile up dumps in the
  journal, occupying lots of space and making the dumps more difficult
  to find.

* I've seen dumps (from GDB's bigcore.exp) being truncated by
  coredumpctl down to four Gigabytes, although no such limit was set in
  /etc/systemd/coredump.conf.  Note that I haven't investigated where
  the truncation happens.

Considering these issues I wonder whether there's a way for a user to
tell systemd-coredump something like: "Core dumps from this process
should be treated traditionally and written to its current working
directory".  Is that possible?  If not, should it be?

--
Andreas

Re: systemd-coredump in distros

[Jan Kratochvil]

On Thu, 21 Sep 2017 20:14:48 +0200, Andreas Arnez wrote:
> Is there a recommended/preferred way to deal with this in a typical
> development use case?

For Fedoras one must override /usr/lib/sysctl.d/50-coredump.conf :
# echo kernel.core_pattern=core >/etc/sysctl.d/thefix.conf

There are so many changes to a stock Fedora distro one has to make after its
installation I find such detail not much important.  Someone should finally
build a derived distro for developers.  Or someone probably already did.


Jan

Re: systemd-coredump in distros

[R0b0t1]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

Hello friends!

On Thursday, September 21, 2017, Jan Kratochvil <jan.kratochvil@redhat.com>
wrote:
> On Thu, 21 Sep 2017 20:14:48 +0200, Andreas Arnez wrote:
>> Is there a recommended/preferred way to deal with this in a typical
>> development use case?
>
> For Fedoras one must override /usr/lib/sysctl.d/50-coredump.conf :
> # echo kernel.core_pattern=core >/etc/sysctl.d/thefix.conf
>
> There are so many changes to a stock Fedora distro one has to make after
its
> installation I find such detail not much important.  Someone should
finally
> build a derived distro for developers.  Or someone probably already did.
>

If it is not unwelcome, I would like to suggest Gentoo. Gentoo is a rolling
release distribution but older versions of critical packages are typically
available.

Gentoo has many non-developer users, but the nature of rolling release
distributions and Gentoo's package manager, Portage, lend themselves well
to software development. Personally I found myself needing newer and newer
packages until eventually my choice distibutions did not have them.
Maintaining those packages myself in e.g. $HOME/.local soon proved to be
intractible. I also found myself frequently undoing distribution provided
configuration.

Gentoo comes with no default configuration. A preboot environment is
available to configure a newly imstalled system. During the initial setup a
"desktop" profile can be selected which will produce a system similar to
what most users would expect from the associated desktop environment
(Plasma, GNOME, MATE, etc.).

Portage compiles software to be installed from source. Optional features
are typically disabled by default unless explicitly enabled. It is possible
and very easy to use Portage and related utilities to maintain alternate
root filesystems, including cross compilation environments or toolchains
with alternate C libraries.

Cheers,
    R0b0t1

Spurious re-attach error with extended-remote target

[Dmitry Antipov]

It seems that an attempt to re-attach to an existing PID fails after
an (unsuccessful) attempt to attach to a non-existing one. Example:

$ gdbserver --attach tcp:8888 $(pidof test)
Attached; pid = 5128
Listening on port 8888
Remote debugging from host 127.0.0.1
Detaching from process 5128
gdbserver: Cannot attach to process 12345: No such process (3)
Listening on port 8888
Attached; pid = 5128           ;; gdbserver says it's OK, but...

$ ./gdb/gdb -q
(gdb) set sysroot /
(gdb) target extended-remote :8888
Remote debugging using :8888
Reading symbols from /tmp/test...done.
Reading symbols from /lib64/libstdc++.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/libm.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols found)...done.
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
0x00007f8fb3fae83d in pthread_join () from /lib64/libpthread.so.0
(gdb) detach
Detaching from program: /tmp/test, process 5128
(gdb) attach 12345                                 ;; no process with specified PID
Attaching to program: /tmp/test, process 12345
Attaching to process 12345 failed
(gdb) attach 5128
Attaching to program: /tmp/test, process 5128      ;;; hmm...
Unknown remote qXfer reply: T0006:0000000000000000;07:c00f7d81ff7f0000;10:3de8fab38f7f0000;thread:1408;core:3;      ;;; problem?
(gdb)

(current HEAD at 57a024f4650d7562e963efb6b00c4a4cd74185c4, configured with
'--with-python=no --with-guile=no --disable-nls --disable-binutils --disable-ld
--disable-gold --disable-gas --disable-sim --disable-gprof').

Dmitry