[systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files

[Colin Walters]

On Tue, 2013-05-14 at 19:09 +0300, Oleksii Shevchuk wrote:
> Introduce configuration file: /etc/systemd/coredump.conf with
> configurable core dumps backend storages (journal/file/both/none),
> per storage size limits and preprocessing.

Who would want "both" and why?  Oh, though maybe you answer this here:

>    PreprocessFile=gzip -9 <%i>%o

Ideally for this case it'd be a pipe; that way we avoid writing a
potentially large file to disk only to write a smaller version again.

>    PreprocessJournal=gdb -nw --batch --quiet --silent --ex 'thread \
>    apply all bt' --core %i %e > %o

I can see this being quite cool.  Would require having both gdb and
debug symbols on the target system, but a lot of systems have that.

Though maybe instead of this, we allow people to write systemd units
that match core files.

> 4. Copying "optimizations" removed for now. Now core always stored
>    to temporary folder, then optionaly preprocessed to temporary
>    files, then temporary files copied to storage.

Ok; we can add this later.

+                          <listitem><para>If unspecified <literal>systemd-coredump</literal> will drop privileges to nobody user
+                          to store core to temporary folder and process it. When value is unset, <literal>systemd-coredump</literal>
+                          will drop privileges to process owner uid/gid. 

Does the systemd config system really have a distinction between
"unspecified" and "unset"?  It looks to me we're always using
"nobody".  

But "git grep nobody" says that nothing else in systemd is using the
"nobody" user.  Maybe it would make sense to just use the process owner
by default?   Why does preprocessing happen before dropping creds?

+        memcpy(m, memory, memory_size);
+        munmap(m, memory_size);
+        close(fd);

Should check for errors here, and log if they fail.

+                if (system(preprocess_journal))
+                        unlink(journal_tmp_filename);

In general you have a lack of error logging...it'd be nice to at least
log if the preprocess command fails (or coredumps!), because the kernel
won't coredump anything with an rlimit of 1 which systemd-coredump and
any process it spawns will have.


Anyways, in the big picture there's one feature we should probably have
before landing this, which is some sort of free-space detection like
journald has.  At the moment if this patch lands a repeatedly crashing
process could just fill up the disk quickly.  

At least if the system administrator has set up quotas, we should
probably ensure the files are charged against the dumping user's quota.
At the moment we're charging them to "nobody", right?