Re: F26 System Wide Change: Enable coredumpctl by default

2016-12-05 Thread jfilak
" -- Původní zpráva -- Od: Zbigniew Jędrzejewski-Szmek Komu: Development discussions related to Fedora Datum: 5. 12. 2016 21:57:12 Předmět: Re: F26 System Wide Change: Enable coredumpctl by default "On Mon, Dec 05, 2016 at 02:36:13PM -0500, DJ Delorie wrote: >  > Jan Kurik write

Re: F26 System Wide Change: Enable coredumpctl by default

2016-12-05 Thread jfilak
-- Původní zpráva -- Od: DJ Delorie Komu: Development discussions related to Fedora Datum: 5. 12. 2016 20:37:43 Předmět: Re: F26 System Wide Change: Enable coredumpctl by default " Jan Kurik writes: > Note that coredumpctl is intended as a developer tool, As a developer, I re

Re: F26 System Wide Change: Enable coredumpctl by default

2016-12-05 Thread jfilak
If you remove ABRT and set kernel.core_pattern to 'core', then if you don't configure systemd to use RLIMIT_CORE=0, every crashing process will create  a new core dump file in its CWD: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ message/HQ4JFTYLPT5GRW6AD4M2MWG

Re: F26 System Wide Change: Enable coredumpctl by default

2016-12-06 Thread jfilak
-- Původní zpráva -- Od: Lennart Poettering Komu: Development discussions related to Fedora Datum: 6. 12. 2016 11:11:48 Předmět: Re: F26 System Wide Change: Enable coredumpctl by default "On Tue, 06.12.16 10:16, Miroslav Suchý (msu...@redhat.com) wrote: > Dne 6.12.2016 v 09:52

Re: F26 System Wide Change: Golang 1.8

2016-12-12 Thread jfilak
Jakub, can we enable coredumping for Go programs by default - i.e. set GOTRACEBACK= crash? Currently, Go terminate  a process that panic and prints out an error message on stderr. This approach does not provide much room for automatic Go panic detection. Regards, Jakub ABRT

Re: F26 System Wide Change: Golang 1.8

2016-12-13 Thread jfilak
Oh drat, I was hoping for a build time configuration option: https://github.com/golang/go/issues/18304 Anyway, the env variable could be exported in the /etc/profile file which is owned by the setup package. However, I don't think it is a good idea to place it there. I would rather export i

Re: F26 System Wide Change: Golang 1.8

2016-12-13 Thread jfilak
I agree with Zbyzsek on this. What about to carry a tiny down-stream patch until this issue is fixed: https://github.com/golang/go/issues/18304 (https://github.com/golang/go/issues/18304) Jakub -- Původní zpráva -- Od: Zbigniew Jędrzejewski-Szmek Komu: Developm

Re: Creating cores in f25

2016-12-19 Thread jfilak
Hi Steve, Please have a look at this email: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ message/HQ4JFTYLPT5GRW6AD4M2MWGMRAPE7ITN/ systemd developers has decided to change the default RLIMIT_CORE (ulimit -c) from "0" to unlimited, therefore ABRT must stop

Re: Creating cores in f25

2016-12-19 Thread jfilak
-- Původní zpráva -- Od: Lennart Poettering Komu: Development discussions related to Fedora Datum: 19. 12. 2016 13:51:09 Předmět: Re: Creating cores in f25 "On Mon, 19.12.16 00:07, Tom Hughes (t...@compton.nu) wrote: > On 18/12/16 23:08, Matthew Miller wrote: > > On Sun, Dec 1

Re: Interpreting FAF reports

2017-01-02 Thread jfilak
Hi Sérgio, It depends on what is your goal. Do you want to fix the crash? You can log in to FAF and check if there is a contact email or a comment. If there is not additional information, you can just wait until some opens a Bugzilla bug report. Do you want to get rid of the notifica

Re: Interpreting FAF reports

2017-01-02 Thread jfilak
Isn't this related to no free disk space? I've seen some strange mmap related crashes when a process mmaped a sparse file and disk ran out of free space. Anyway, please do let me know what additional information would help you to resolve the issue. Please bare in mind that FAF report must

Re: F26 System Wide Change: Golang 1.8

2017-01-06 Thread jfilak
Brilliant! I was thinking about creating a proof of concept a posting it as a change myself. However, I'm really busy with other projects, so I might miss F26. Brad's suggestion made me happy, that's why I close the issue. Though, I would not name the flag 'abrt' but 'tracebackcrash' or so

Re: [ABRT] Intent to put abrt-hook-ccpp to rest

2019-09-04 Thread jfilak
If you no longer plan to add the feature for generating backtraces without writing core files to disk, then abrt-hook-ccpp is pretty much useless - IMHO. -- Původní e-mail -- Od: Ernestas Kulik Komu: devel@lists.fedoraproject.org Datum: 4. 9. 2019 10:06:05 Předmět: [ABRT] Inte

Re: vanishing abrt logs

2019-04-08 Thread jfilak
Hi Kevin, I was under the impression that the problem with many emails from Bugzilla has already been fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1660157 (https://bugzilla.redhat.com/show_bug.cgi?id=1660157) https://github.com/abrt/libreport/commit/569bf0e3fed698e93b8e098bf6a0bb2f773 a

Re: vanishing abrt logs

2019-04-08 Thread jfilak
Hi Zbyszek, If you want more files attached to ABRT Bugzilla reports, please add them to systemd-coredump first :) https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c#L1074 (https://github.com/systemd/systemd/blob/master/src/coredump/coredump.c#L1074) so ABRT folks can s

Re: vanishing abrt logs

2019-04-08 Thread jfilak
I agree, but the file /proc/meminfo is not present, right? And yes, the abrt thing just reads the data from journal and stores them on filesystem to be able to upload them to Bugzilla. Regarding the missing logs, the journal log lines should be extracted by this thing: https://github.com/ab

Re: vanishing abrt logs

2019-04-10 Thread jfilak
> I think abrt should figure out if the crashing binary is part of Would it be an option to create your own configuration for libreport? It is much simpler and robust to deliver a config tailored for your packages than trying to generalize the task and define a global policy Example: