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 dropp
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 the
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
2014-06-23 10:28 GMT+02:00 Frederic Crozat :
> 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
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 th
2014-06-20 20:02 GMT+02:00 Lennart Poettering :
> 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 can also place th
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 p
On Wed, May 22, 2013 at 9:22 AM, Tollef Fog Heen 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 gpg/last
]] 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
> wi
> > 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 dat
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
> 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-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 t
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 c
14 matches
Mail list logo
