[systemd-devel] [PATCH 3/6] Optionally save core dumps as plain files

[Oleksii Shevchuk]

> Hmm, if we do this, then I'd suggest not to place this in the journal
> directory. This should be independent of it. Note that the journal logic
> currently watches the entire per-machine dir for changes and we thus
> should really drop stuff there that doesn't belong there..

Saving in journal subdirs leave possibility of remote mounting logging
directory and automatic processing. If there is real issue with that, 
dumps can go to /var/log/coredump/MACHINE-ID/ probably

> > +                r = sd_id128_randomize(&coreid);
> > +                if (r)
> > +                        goto journal;

> Do we really want a new random ID in this?

Random Id is the simplest case. Probably we can have several cores from several
instances in same time. PID+Time can be used instead, probably, but
random id looks better for me. Any issues with that? 

> Also, message IDs are *not* supposed to be "just counted up". Instead
> generate a new one with "journalctl --new-id128". However, in this case
> we really should just use the same ID for all cases, and just depending
> on the configuration have a different set of keys in it, i.e. either the
> actual coredump, or the coredump path + hash, or even both. Depending on
> the configuration file...

Journals can be copied to external host without configuration
files. I.e. depending on the configuration file is not an option. On the
other hand, software can search either for COREDUMP filed or the
COREDUMP_FILE..