RFC: ABRT integration

[Jakub Filak]

Avocado developers,


I came across an Avocado trello card requesting integration with
systemd-coredumpctl. As a developer working on Automatic Bug Reporting Tool
(ABRT) I got interested in it. I contacted Lukas Doktor with a question of
what purpose the integration should be and with an offer to engage ABRT too.
After short chat he asked me to send an RFC to this mailing list. So here
you are Lukas.


Let me first briefly introduce ABRT. Despite its name ABRT is more about
detecting software (and hardware) problems and the reporting is just a one
step in the whole processes of handling a problem. Currently ABRT is capable
of detecting core files, uncaught Python exceptions, uncaught Ruby
exceptions, uncaught Java exceptions, Kernel oopses (including those stored
in pstore), Kernel vmcores and Machine Check Exceptions. ABRT provides
several ways accessing detect problems which includes command line tools
(abrt), GUI tools (gnome-abrt), Python API, C API and D-Bus interface. If
interested, you can find more about ABRT at:
http://abrt.readthedocs.io/


I propose to enhance Avocado to become aware of ABRT and include detected
problems in test results. Here is my initial proof-of-concept commit:
https://github.com/jfilak/avocado/commit/e3258706bdfffb8ddddb2f1bc51328af...


Some technical details:
- the implementation will capture only problems of a current user
- a proper configuration of PolicyKit can allow any user to read all system
  problems
- there can be several simultaneous connections to ABRT D-Bus connection


Please have a look at my patch and let me know if ABRT integration is
something you are interested in.


Should you have any question, please contact me or any ABRT developer on
crash-catcher(a)lists.fedorahosted.org or on #abrt.




Kind regards,
Jakub

[Avocado-devel] RFC: ABRT integration

[Cleber Rosa]

On 11/11/2016 07:20 AM, Jakub Filak wrote:
>  Avocado developers,
>  
>  
>  I came across an Avocado trello card requesting integration with
>  systemd-coredumpctl. As a developer working on Automatic Bug Reporting Tool
>  (ABRT) I got interested in it. I contacted Lukas Doktor with a question of
>  what purpose the integration should be and with an offer to engage ABRT too.
>  After short chat he asked me to send an RFC to this mailing list. So here
>  you are Lukas.
>  
>   
Hi Jakub,

First of all, thanks for taking the time!

>  Let me first briefly introduce ABRT. Despite its name ABRT is more
> about
>  detecting software (and hardware) problems and the reporting is just a one
>  step in the whole processes of handling a problem. Currently ABRT is capable
>  of detecting core files, uncaught Python exceptions, uncaught Ruby
>  exceptions, uncaught Java exceptions, Kernel oopses (including those stored
>  in pstore), Kernel vmcores and Machine Check Exceptions. ABRT provides
>  several ways accessing detect problems which includes command line tools
>  (abrt), GUI tools (gnome-abrt), Python API, C API and D-Bus interface. If
>  interested, you can find more about ABRT at:
>  http://abrt.readthedocs.io/
>  
>  
>  I propose to enhance Avocado to become aware of ABRT and include detected
>  problems in test results. Here is my initial proof-of-concept commit:
>  https://github.com/jfilak/avocado/commit/e3258706bdfffb8ddddb2f1bc51328af...
>  
>   
Now, I have to repeat: thanks for taking the time to write this PoC.

>  Some technical details:
>  - the implementation will capture only problems of a current user 
This is not a big deal since our current implementation for catching
coredumps is pretty much limited to super users.

Still, let me get this straight: if a test exercises and crashes a
running daemon (running as a different user) ABRT won't be able to
capture the daemon's problems, right?

But, if the user is running the test as root, then ABRT will be able to
capture all the system's problems?

>  - a proper configuration of PolicyKit can allow any user to read all
> system
>    problems 
Right.  For our purposes, it's fine to ship an example policy as a
contrib file.

>  - there can be several simultaneous connections to ABRT D-Bus
> connection
>  
>   
If PolicyKit is configured to allow all system problems to be read, and
there are multiple connections to ABRT, will all of those receive all
problem notifications?  Or is it a single queue and whomever reads first
removes it from the queue?

>  Please have a look at my patch and let me know if ABRT integration
> is
>  something you are interested in.
>  
>   
I will indeed.

>  Should you have any question, please contact me or any ABRT developer
> on
>  crash-catcher(a)lists.fedorahosted.org or on #abrt.
>  
>   
Sure!

>  
>  
>  Kind regards,
>  Jakub
>   
Regards,

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]

[Avocado-devel] RFC: ABRT integration

[Jakub Filak]

Hi Cleber

On 11/11/2016 03:16 PM, Cleber Rosa wrote:
>  On 11/11/2016 07:20 AM, Jakub Filak wrote:
>  
> > Some technical details:
> > - the implementation will capture only problems of a current user
>  
>  This is not a big deal since our current implementation for catching
>  coredumps is pretty much limited to super users.
>  
>  Still, let me get this straight: if a test exercises and crashes a
>  running daemon (running as a different user) ABRT won't be able to
>  capture the daemon's problems, right?
>  
>  But, if the user is running the test as root, then ABRT will be able to
>  capture all the system's problems?
>   
ABRT will capture the daemon's problems, but the user (it not privileged)
won't have access to the problems (by default).

IOW, if the users is not root, the ProblemsWatcher will collect problems
that occurred in processes that were running with the users' UID.

The system's problems include problems of all users.

> > - a proper configuration of PolicyKit can allow any user to read
> all system
> >   problems
>  
>  Right.  For our purposes, it's fine to ship an example policy as a
>  contrib file. 
The configuration could look like the following:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.problems.getall" &&
        subject.active == true &&
        subject.local == true &&
        subject.isInGroup("avocado")) {
            return polkit.Result.YES;
    }
});

And should be saved in a file in the "/usr/share/polkit-1/rules.d" directory.

With this configuration the members of the avocado group will be able to get
their problems + system problems without the need to authorize themselves
via PolicyKit.


>  
> > - there can be several simultaneous connections to ABRT D-Bus connection
> >
> >
>  
>  If PolicyKit is configured to allow all system problems to be read, and
>  there are multiple connections to ABRT, will all of those receive all
>  problem notifications? Or is it a single queue and whomever reads first
>  removes it from the queue?
>   
ABRT problems are persistent until someone removes them. Thus all
connections to ABRT will see the same set of problems (unless intentionally
changed by another connection).



Jakub

[Avocado-devel] RFC: ABRT integration

[Lucas Meneghel Rodrigues]

On Fri, Nov 11, 2016 at 8:21 AM Jakub Filak <jfilak(a)redhat.com&gt; wrote:

>  Avocado developers,
>
>
>  I came across an Avocado trello card requesting integration with
>  systemd-coredumpctl. As a developer working on Automatic Bug Reporting Tool
>  (ABRT) I got interested in it. I contacted Lukas Doktor with a question of
>  what purpose the integration should be and with an offer to engage ABRT
>  too.
>  After short chat he asked me to send an RFC to this mailing list. So here
>  you are Lukas.
>
>  
Thank you very much for this POC. Having avocado and ABRT integrated will
help quite a lot in Fedora and RHEL.


>  Let me first briefly introduce ABRT. Despite its name ABRT is more
> about
>  detecting software (and hardware) problems and the reporting is just a one
>  step in the whole processes of handling a problem. Currently ABRT is
>  capable
>  of detecting core files, uncaught Python exceptions, uncaught Ruby
>  exceptions, uncaught Java exceptions, Kernel oopses (including those stored
>  in pstore), Kernel vmcores and Machine Check Exceptions. ABRT provides
>  several ways accessing detect problems which includes command line tools
>  (abrt), GUI tools (gnome-abrt), Python API, C API and D-Bus interface. If
>  interested, you can find more about ABRT at:
>  http://abrt.readthedocs.io/
>
>
>  I propose to enhance Avocado to become aware of ABRT and include detected
>  problems in test results. Here is my initial proof-of-concept commit:
>
>  https://github.com/jfilak/avocado/commit/e3258706bdfffb8ddddb2f1bc51328af...
>
>
>  Some technical details:
>  - the implementation will capture only problems of a current user
>  - a proper configuration of PolicyKit can allow any user to read all system
>    problems
>  - there can be several simultaneous connections to ABRT D-Bus connection
>
>
>  Please have a look at my patch and let me know if ABRT integration is
>  something you are interested in.
>  
We're interested in, you got me at the first sentence of your e-mail :)


>  Should you have any question, please contact me or any ABRT developer on
>  crash-catcher(a)lists.fedorahosted.org or on #abrt.
>
>
>
>
>  Kind regards,
>  Jakub
>
>