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

[Oleksii Shevchuk]

> 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.

I thought about that. With cores there is no way to do transparent
piping with postproc. All tools mmap cores, so in real world they will 
be dumped anyway..

We dump core before preprocessing to tmpfs, btw.

> Maybe it would make sense to just use the process owner
> by default? Why does preprocessing happen before dropping creds?

For security reasons. It will be better if user will not have access to
own cores by default (situation is the same with journal backend in
upstream now).

> Why does preprocessing happen before dropping creds

Processing done in separate process with dropped creds

> 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.

Yeah, I'll add some, if idea with temporary files will be accepted in
general.

> 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.  

Cores rotation mechainsm or just avoiding to write new cores?

> 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?

At the moment cores dumped and processed at tmpfs with nobody, then
copied from user creds to journal and with systemd-journal creds to fs.