Bug 622773

Summary:	[RFE] please add D-Bus functions systemd's "systemctl status" tool can query to find crashes
Product:	[Fedora] Fedora	Reporter:	Lennart Poettering <lpoetter>
Component:	abrt	Assignee:	Jiri Moskovcak <jmoskovc>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	a9016009, adam, ahecox, anton, bnocera, dfediuck, dvlasenk, iprikryl, jmoskovc, kklic, mishu, mnowak, mtoman, npajkovs, rgs, tobutaz+rh+bugs
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-30 00:56:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	744774

Description Lennart Poettering 2010-08-10 11:52:20 UTC

Currently, "systemctl status" shows whether a daemon crashed and will show the exit signal, time and pid. It would be really cool if we could show the abrt crash dump next to it if one is available. For that a very simple D-Bus API extension would be cool:

1) one that allows us to ask abrtd if there's a dump around for a specific PID at a specific time.

2) one that allows us to ask abrtd if there's a dump around for a specific systemd cgroup name inside a specific time range.

I presume #1 should be pretty straigh-forward. For #2 abrtd would have to record the cgroup data from /proc/$PID/cgroup. For systemd only the group in the "name=systemd" hierarchy will matter but for other purposes the other groups might matter too.

If we have these calls we could show two things in "systemctl status":

- When the daemon exited abnormaly we can refer to the abrtd crashdump for it

- When anything the daemon spawned indirectly (e.g. cgi script of apache) crashed we can show the abrtd crashdump next to the service information.

All I'd need is some APIs like this maybe:

   string FindCrashByPID(u32 pid, u64 timestamp)

Which would return the crash id for a crash of the specified PID that was captured at the specified timestamp (which I'd just pass as usecs, for simplicity's sake). Since the timestamps abrtd takes and systemd takes will differ abrt should probably search in a range -5s .. +5s of the specified value.

   string[] FindCrashByCGroup(string group, u64 timestamp_from, u64 timestamp_to)

Which would return a list of crash ids for the specified cgroup name in the specified time range. the cgroup name should probably be in a syntax like the following: "name=systemd:/systemd-1/apache.service", which is how systemd cgroups normally show up.

Comment 1 Denys Vlasenko 2010-08-18 02:35:30 UTC

We do not save PID and cgroup of the crashed process.(In reply to comment #0)
> Currently, "systemctl status" shows whether a daemon crashed and will show the
> exit signal, time and pid. It would be really cool if we could show the abrt
> crash dump next to it if one is available.

Why is this useful?

Comment 2 Lennart Poettering 2010-08-23 07:38:36 UTC

(In reply to comment #1)
> We do not save PID and cgroup of the crashed process.(In reply to comment #0)

Yes, I am aware, thus this enhancement request.

> > Currently, "systemctl status" shows whether a daemon crashed and will show the
> > exit signal, time and pid. It would be really cool if we could show the abrt
> > crash dump next to it if one is available.
> 
> Why is this useful?

Because if people see with "systemctl status" that a service failed and died with SIGSEG they want to know why exactly, and get access to the backtrace, and maybe even file a bug?

I am sorry, isn't it the obvious next step when you see a service that crashed to figure out why exactly it crashed?

Comment 3 Jiri Moskovcak 2011-04-12 16:21:21 UTC

Hi Lennart,
we're working on a socket based API, which will understand http and use urls to query the abrt database. The responses should be in XML. Is this acceptable for you or do you still insist on dbus based solution? If so, can you please describe why? (Well, I see one possible reason that you don't have to parse XML and care about data (un)marshalling)

Comment 4 Lennart Poettering 2011-04-14 15:53:41 UTC

Really, does it have to be XML of all things? I just want to make a single function call, and dbus is prefectly the right tool for that. It's an IPC, and works and is used by everybody and his dog and installed everywhere. I am not sure I want to add an HTTP client and XML parser to systemd though. In fact I am pretty sure I don't. (Also, HTTP on TCP? Or on AF_UNIX?)

It's just a matter of simplicity for me. To do one function call adding a HTTP and XML dependency to systemd sounds a bit too much for me.

Let's turn this around? Why HTTP/XML of all things?

Comment 5 Jiri Moskovcak 2011-04-14 16:08:55 UTC

(In reply to comment #4)
> Really, does it have to be XML of all things? I just want to make a single
> function call, and dbus is prefectly the right tool for that. It's an IPC, and
> works and is used by everybody and his dog and installed everywhere. I am not
> sure I want to add an HTTP client and XML parser to systemd though. In fact I
> am pretty sure I don't. (Also, HTTP on TCP? Or on AF_UNIX?)

- it will work even over AF_UNIX, but it is meant to be used even over the internet

> 
> It's just a matter of simplicity for me. To do one function call adding a HTTP
> and XML dependency to systemd sounds a bit too much for me.

- ok, understood, so we'll provide a dbus api.

> Let's turn this around? Why HTTP/XML of all things?

- it's supposed to be used by other tools which can handle HTTP/XML already, I didn't really expected you would like it for systemd ;)

Comment 6 Denys Vlasenko 2011-06-15 12:59:21 UTC

We won't do this. We are going to stop using dbus altogether in the daemon.

Comment 7 Jiri Moskovcak 2011-06-15 13:32:00 UTC

We will provide this functionality, but not as a part of the daemon.

Comment 8 Lennart Poettering 2011-06-15 16:52:28 UTC

(In reply to comment #6)
> We won't do this. We are going to stop using dbus altogether in the daemon.

Why?

Comment 9 Jiri Moskovcak 2011-11-29 08:24:52 UTC

There is a new executable in abrt git which provides the dbus api for querying the problem database. It's called abrt-dbus, it is started by dbus autostart. So far it can be used to query list of problems:

$ dbus-send --system --type=method_call --print-reply
--dest=com.redhat.abrt /com/redhat/abrt
com.redhat.abrt.GetListOfProblems
method return sender=:1.49 -> dest=:1.50 reply_serial=2
   array [
      string "/var/spool/abrt/ccpp-2011-11-11-19:18:11-25603"
   ]

Other commands are to be added later (after we discuss which
commands we might want to implement).

Comment 10 Fedora Admin XMLRPC Client 2011-12-19 17:42:44 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 11 Fedora Admin XMLRPC Client 2011-12-19 17:45:49 UTC

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Jiri Moskovcak 2012-05-31 09:07:49 UTC

abrt dbus api now provides a function:

"    <method name='FindProblemByElementInTimeRange'>"
"      <arg type='s' name='element' direction='in'/>"
"      <arg type='s' name='value' direction='in'/>"
"      <arg type='x' name='timestamp_from' direction='in'/>"
"      <arg type='x' name='timestamp_to' direction='in'/>"
"      <arg type='b' name='all_users' direction='in'/>"
"      <arg type='as' name='response' direction='out'/>"
"    </method>"

so to search a problem by a pid you have to call it like this:

problems = FindProblemByElementInTimeRange("pid", "12345", 123456, 123457, false);

Comment 13 Jiri Moskovcak 2012-05-31 09:08:11 UTC

commit 0287cdc38962145fe5817655222b1140a24224d0
Author: Jakub Filak <jfilak>
Date:   Wed May 30 11:56:47 2012 +0200

    rhbz#622773 : abrt-dbus new high-level problem query functions
    
    Signed-off-by: Jakub Filak <jfilak>

Comment 14 Fedora Update System 2012-08-03 10:26:29 UTC

abrt-2.0.11-1.fc17,libreport-2.0.11-1.fc17,btparser-0.18-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.0.11-1.fc17,libreport-2.0.11-1.fc17,btparser-0.18-2.fc17

Comment 15 Fedora Update System 2012-08-05 21:33:35 UTC

Package abrt-2.0.11-1.fc17, btparser-0.18-2.fc17, libreport-2.0.12-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.11-1.fc17 btparser-0.18-2.fc17 libreport-2.0.12-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11529/abrt-2.0.11-1.fc17,libreport-2.0.12-1.fc17,btparser-0.18-2.fc17
then log in and leave karma (feedback).

Comment 16 Fedora Update System 2012-08-09 23:08:50 UTC

Package libreport-2.0.12-2.fc17, abrt-2.0.11-1.fc17, btparser-0.18-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreport-2.0.12-2.fc17 abrt-2.0.11-1.fc17 btparser-0.18-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11529/abrt-2.0.11-1.fc17,libreport-2.0.12-2.fc17,btparser-0.18-2.fc17
then log in and leave karma (feedback).

Comment 17 Fedora Update System 2012-08-23 23:27:20 UTC

Package abrt-2.0.12-1.fc17, libreport-2.0.13-1.fc17, btparser-0.18-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.12-1.fc17 libreport-2.0.13-1.fc17 btparser-0.18-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-11529/abrt-2.0.12-1.fc17,libreport-2.0.13-1.fc17,btparser-0.18-2.fc17
then log in and leave karma (feedback).

Comment 18 Fedora Update System 2012-08-30 00:56:08 UTC

abrt-2.0.12-1.fc17, libreport-2.0.13-2.fc17, btparser-0.18-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.