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.
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?
(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?
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)
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?
(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 ;)
We won't do this. We are going to stop using dbus altogether in the daemon.
We will provide this functionality, but not as a part of the daemon.
(In reply to comment #6) > We won't do this. We are going to stop using dbus altogether in the daemon. Why?
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).
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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);
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>
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
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).
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).
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).
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.