rasdaemon and abrt cooperation

Petr Holasek pholasek at redhat.com
Thu Sep 12 13:38:51 UTC 2013


On Tue, 18 Jun 2013, Denys Vlasenko wrote:
> On 06/05/2013 03:25 PM, Petr Holasek wrote:
> > Hi Denys,
> > 
> > I have some ideas about rasdaemon abrt hook
> > and also following questions.
> > 
> > Feel free to stop by or ping me, when you'll
> > be in office, I'll be there till ~6PM today
> > and afternoon tomorrow.
> 
> Currently we use Unix domain socket at
> /var/run/abrt/abrt.socket
> to support creation of problem data from crashing python
> applications.
> 
> The socket accepts the following HTTP requests:
> 
> DELETE <problem_dir> HTTP/1.1
> PUT / HTTP/1.1
> 
> DELETE request is straightforward, and anyway, you don't need it.
> 
> PUT request has the following form:
> 
> PUT / HTTP/1.1<CR><LF>
> headers<CR><LF>
> <CR><LF>
> name1=value1<NUL>name2=value2<NUL>...
> 
> It appears that we misunderstood HTTP protocol and we should
> have used POST instead of PUT. I am going to add POST alias
> which works the same as PUT, and remove PUT sometime in the future.
> For now, use PUT. The URI in PUT should be just /.
> 
> The headers following PUT line are currently ignored.
> 
> The body is NUL-delimited (not newline delimited!) set
> of name-value pairs which describe the problem.
> 
> You can use any names which make sense for your problem
> (for example, if someone is reporting an out-of-paper
> problem with a printer, sending "printer_name=FOO" would make sense).
> 
> Some names *have* to be in the problem:
> type=
> reason=
> 
> "type" describes what kind of the problem it is. Say, "Python"
> is used by python crashes. You need to invent your own identifier(s)
> for the problems you want to report. Say, "mem_error" for ECC/cache
> errors, "bus_error" for PCI errors?
> This field is used to differentiate abrt's response to a problem.
> We don't want ECC errors reported to Bugzilla, right? :)
> 
> "reason" is a short, one-line, human-readable description of the problem,
> suitable, for example, for showing in the list of problems. Examples
> we currently see or use:
> "<module>:ZeroDivisionError: integer division or modulo by zero"
> "Segmentation fault at address 0x7ff6bf09e010"
> "Process %s was killed by signal %s"
> 
> time=<unixtime in seconds> will be added automatically unless you supply it.
> 
> I looked thru the list of names we use and many don't make sense for you
> (say, "uid" makes no sense for ECC errors :), but the following ones
> may be useful:
> 
> architecture=<uname.machine>
> comment=<long, multi-line description of the problem (if "reason" isn't enough)>
> kernel=<kernel version>
> cmdline=<kernel cmdline>
> 
> As I said, if you have more data to report, create your own name=value pair
> to be saved.
> 
> Server will respond with
> 
> HTTP/1.1 <http_code> <CR><LF>
> <CR><LF>
> 
> http_code will be 201 ("Created") on success.
> 
> Do you think you can use this interface from rasdaemon?
> 

Hi Denys,

at first, apologize for my delay, me and Mauro changed our positions and
rasdaemon project was silent for a few months. Interface you have described
above seems fine for our purpose.

The only missing thing in current implementation is some analysis component
which will "absorb" all rasdaemon output and send only useful data further to
socket and $COREDUMPDIR. We haven't decided yet if it is will be part of
rasdaemon or hook. Some IBM guys were working on this analysis tool, so I am
going to check their progress and let you know.

I have one question to HTTP abrtd interface: how and when does abrtd create
new $COREDUMPDIR? Here http://jmoskovc.fedorapeople.org/abrtarch.html it is
described that problem directories are created by hook, but can be also
created by request to abrtd socket. So is it necessary to create it by hook
or are they created automatically by abrtd based on data received from HTTP
interface?

thanks!
Petr


More information about the Crash-catcher mailing list