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? _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
