On Tue, 24.06.14 15:21, Lennart Poettering (lenn...@poettering.net) wrote:
On Mon, 23.06.14 14:29, Dave Reisner (d...@falconindy.com) wrote:
Anyway, I hope this makes sense.
With these changes coredumpctl actually is now really useful and just
works. I have thus dropped the
On Mon, 23.06.14 14:29, Dave Reisner (d...@falconindy.com) wrote:
Anyway, I hope this makes sense.
With these changes coredumpctl actually is now really useful and just
works. I have thus dropped the systemd- prefix. We should probably
start advertising it more.
Are there plans to
Le vendredi 20 juin 2014 à 20:02 +0200, Lennart Poettering a écrit :
2) I change the paths to store this in. I drop the coredumps in
/var/lib/systemd/coredump/ now. While the journal logs appear to be
something worth sharing across the network as logs; I am not
convinced that the
2014-06-23 10:28 GMT+02:00 Frederic Crozat fcro...@suse.com:
Le vendredi 20 juin 2014 à 20:02 +0200, Lennart Poettering a écrit :
2) I change the paths to store this in. I drop the coredumps in
/var/lib/systemd/coredump/ now. While the journal logs appear to be
something worth sharing
On Fri, Jun 20, 2014 at 08:02:54PM +0200, Lennart Poettering wrote:
On Tue, 14.05.13 19:09, Oleksii Shevchuk (alx...@gmail.com) wrote:
Heya!
Sorry for resurrecting this thread from last year. I never found the
time to merge this, but I finally had a closer look and then sat down
and tried
On Tue, 14.05.13 19:09, Oleksii Shevchuk (alx...@gmail.com) wrote:
Heya!
Sorry for resurrecting this thread from last year. I never found the
time to merge this, but I finally had a closer look and then sat down
and tried to isolate out of it what I liked and what I didn't. I
commited different
2014-06-20 20:02 GMT+02:00 Lennart Poettering lenn...@poettering.net:
So here's what is implemented in git now:
a) There's a configuration file /etc/systemd/coredump.conf with some of
the options you proposed.
b) We will now store coredumps outside of the journal by default, but
you
]] Oleksii Shevchuk
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?
When apps like gpg/lastpass/whatelse-with-passwords crashes, then user
probably
will not be very
On Wed, May 22, 2013 at 9:22 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Oleksii Shevchuk
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?
When apps like
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
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..
On Tue, 2013-05-21 at 17:05 +0300, Oleksii Shevchuk wrote:
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?
Yeah, I'll add some, if idea with temporary files will be accepted in
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?
When apps like gpg/lastpass/whatelse-with-passwords crashes, then user probably
will not be very happy to have all that data
Introduce configuration file: /etc/systemd/coredump.conf with
configurable core dumps backend storages (journal/file/both/none),
per storage size limits and preprocessing.
Default filestorage choosed as /run/log/coredump or /var/log/coredump
with next reason:
1. These files produced with systemd
14 matches
Mail list logo
