[Spacewalk-list] SW 1.9 abrt crash upload fails

Fri Mar 8 17:09:24 UTC 2013

Hello,
For the duplicate dir, the problem is that, when a duplicate dir is
found... no data is uploaded.
To test sosreport file upload, I've modified the configuration and reran my
test using my simple loop.
I get these logs:
Mar  8 15:47:29  abrtd: Directory 'ccpp-2013-03-08-15:47:29-20599' creation
detected
Mar  8 15:47:29  abrt[20607]: Saved core dump of pid 20599 (/bin/bash) to
/var/spool/abrt/ccpp-2013-03-08-15:47:29-20599 (413696 bytes)
Mar  8 15:47:38  abrtd: Sending an email...
Mar  8 15:47:38  abrtd: Email was sent to: root at localhost
Mar  8 15:47:38 abrtd: New problem directory
/var/spool/abrt/ccpp-2013-03-08-15:47:29-20599, processing
Mar  8 17:05:23 abrt[21793]: Saved core dump of pid 21781 (/bin/bash) to
/var/spool/abrt/ccpp-2013-03-08-17:05:23-21781 (413696 bytes)
Mar  8 17:05:23  abrtd: Directory 'ccpp-2013-03-08-17:05:23-21781' creation
detected
Mar  8 17:05:32  abrtd: Sending an email...
Mar  8 17:05:32  abrtd: Email was sent to: root at localhost
Mar  8 17:05:32  abrtd: Duplicate: UUID
Mar  8 17:05:32  abrtd: DUP_OF_DIR:
/var/spool/abrt/ccpp-2013-03-08-15:47:29-20599
Mar  8 17:05:32  abrtd: Corrupted or bad directory
'/var/spool/abrt/ccpp-2013-03-08-17:05:23-21781', deleting

The problem is that on my spacewalk server, I only have the first data
uploaded, and the crash count is not updated.

Is this the expected behavior?

Pierre

2013/3/8 Pierre Casenove <pcasenove at gmail.com>

> Thanks a lot for the information. Having this functionnality is great!
>
> Pierre
>
>
> 2013/3/8 Milan Zazrivec <mzazrivec at redhat.com>
>
>> > Thanks a lot, it works now... but I noticed 2 points:
>> > 1) I've launched another test to validate the path. Here is the logs I
>> had:
>> > Mar  8 15:46:44 abrtd: Directory 'ccpp-2013-03-08-15:46:44-20301'
>> creation
>> > detected
>> > Mar  8 15:46:44  abrt[20327]: Saved core dump of pid 20301 (/bin/bash)
>> to
>> > /var/spool/abrt/ccpp-2013-03-08-15:46:44-20301 (413696 bytes)
>> > Mar  8 15:46:56  abrtd: Sending an email...
>> > Mar  8 15:46:56  abrtd: Email was sent to: root at localhost
>> > Mar  8 15:46:56  abrtd: Duplicate: UUID
>> > Mar  8 15:46:56 abrtd: DUP_OF_DIR:
>> > /var/spool/abrt/ccpp-2013-03-07-15:29:42-3952
>> > Mar  8 15:46:56 abrtd: Corrupted or bad directory
>> > '/var/spool/abrt/ccpp-2013-03-08-15:46:44-20301', deleting
>>
>> Yes, when abrtd detects a duplicate crash, it deletes its crash directory
>> and
>> increases the 'count' in the original directory (the one that this crash
>> is
>> a duplicate of).
>>
>> > The folder "/var/spool/abrt/ccpp-2013-03-07-15:29:42-3952" is the one
>> that
>> > were created when spacewalk-abrt crashed.
>> > When I've generated a new crash today with your patch, spacewalk-abrt
>> > couldn't upload the data and deleted this folder.
>>
>> abrtd won't execute spacewalk-abrt --report $DUMP_DIR when it detects
>> duplicates (i.e. it won't re-upload the whole stuff for duplicates).
>> Instead
>> it launches spacewalk-abrt --update-count $DUMP_DIR which just increases
>> the count number.
>>
>> > I've deleted folder "/var/spool/abrt/ccpp-2013-03-07-15:29:42-3952" and
>> > regenerated a crash... everything was working
>> >
>> > 2) sosreport.tar.xz has not been uploaded to my spacewalk server. The
>> file
>> > size limit is set to 2048 and the file is 1.3MB.
>>
>> This is correct. 2048 is a size limit in bytes (as stated on the org
>> config
>> web page).
>>
>> -MZ
>>
>> > 2013/3/8 Milan Zazrivec <mzazrivec at redhat.com>
>> >
>> > > > Hello list,
>> > > > I've upgraded my spacewalk server to version 1.9 (rhel 5 pgsql).
>> > > > I've updated spacewalk client binairies on a test client, and
>> installed
>> > > > spacewalk-abrt package.
>> > > > I've rebooted both the server and the client.
>> > > >
>> > > > To test abrt crash upload functionnality, i've launched the
>> following
>> > > > compex script in background:
>> > > > #!/bin/bash
>> > > >
>> > > > while :
>> > > > do
>> > > >
>> > > >    sleep 1
>> > > >
>> > > > done
>> > > >
>> > > > Than, I killed it using kill -SIGSEGV 3952
>> > > >
>> > > > As expected, abrt detected the crash... but then spacewalk crashed!
>> > > > Mar  7 15:29:42  abrt[3967]: Saved core dump of pid 3952
>> (/bin/bash) to
>> > > > /var/spool/abrt/ccpp-2013-03-07-15:29:42-3952 (413696 bytes)
>> > > > Mar  7 15:29:42  abrtd: Directory 'ccpp-2013-03-07-15:29:42-3952'
>> > >
>> > > creation
>> > >
>> > > > detected
>> > > > Mar  7 15:29:50  abrtd: Sending an email...
>> > > > Mar  7 15:29:50  abrtd: Email was sent to: root at localhost
>> > > > Mar  7 15:29:51 abrtd: New problem directory
>> > > > /var/spool/abrt/ccpp-2013-03-07-15:29:42-3952, processing
>> > > > Mar  7 15:29:51  abrtd: An error has occurred:
>> > > > Mar  7 15:29:51  abrtd: Error communicating with server. The message
>> > > > was: Mar  7 15:29:51  abrtd: While running 'abrt.create_crash':
>> caught
>> > > > Mar  7 15:29:51 tu-spa-d13 abrtd: exceptions.TypeError : expected a
>> > > > character buffer object
>> > > > Mar  7 15:29:51 tu-spa-d13 abrtd:
>> > > > Mar  7 15:29:51 tu-spa-d13 abrtd: See /var/log/up2date for more
>> > >
>> > > information
>> > >
>> > > > In up2date log, I have:
>> > > > <class 'up2date_client.up2dateErrors.CommunicationError'>: Error
>> > > > communicating with server. The message was:
>> > > > While running 'abrt.create_crash': caught
>> > > > exceptions.TypeError : expected a character buffer object
>> > > >
>> > > >
>> > > > I've checked httpd error log, I found this:
>> > > > [Thu Mar 07 15:29:51 2013] [error] Exception Handler Information
>> > > > [Thu Mar 07 15:29:51 2013] [error] Traceback (most recent call
>> last):
>> > > > [Thu Mar 07 15:29:51 2013] [error]   File
>> > > >
>> "/usr/lib/python2.4/site-packages/spacewalk/server/apacheRequest.py",
>> > >
>> > > line
>> > >
>> > > > 122, in call_function
>> > > > [Thu Mar 07 15:29:51 2013] [error]     response = apply(func,
>> params)
>> > > > [Thu Mar 07 15:29:51 2013] [error]   File
>> > > > "/usr/share/rhn/server/handlers/xmlrpc/abrt.py", line 170, in
>> > >
>> > > create_crash
>> > >
>> > > > [Thu Mar 07 15:29:51 2013] [error]     server_crash_dir =
>> > > > get_crash_path(str(server_org_id), str(self.server_id),
>> > > > crash_data['crash']) [Thu Mar 07 15:29:51 2013] [error]   File
>> > > > "/usr/lib/python2.4/site-packages/spacewalk/server/rhnLib.py", line
>> > > > 218,
>> > >
>> > > in
>> > >
>> > > > get_crash_path
>> > > > [Thu Mar 07 15:29:51 2013] [error]     if _is_secure_path(path):
>> > > > [Thu Mar 07 15:29:51 2013] [error]   File
>> > > > "/usr/lib/python2.4/site-packages/spacewalk/server/rhnLib.py", line
>> > > > 211,
>> > >
>> > > in
>> > >
>> > > > _is_secure_path
>> > > > [Thu Mar 07 15:29:51 2013] [error]     return not
>> path.startswith(('/',
>> > > > '../'))
>> > > > [Thu Mar 07 15:29:51 2013] [error] TypeError: expected a character
>> > > > buffer object
>> > > >
>> > > >
>> > > > What am I doing wrong?
>> > >
>> > > Heya -- you're not doing anything wrong. This is a valid bug in
>> > > spacewalk-backend which will show on a RHEL-5 Spacewalk (server) only.
>> > >
>> > > This is the fix you need on your server:
>> > >
>> > >
>> > >
>> http://git.fedorahosted.org/cgit/spacewalk.git/commit/?h=SPACEWALK-1.9&id
>> > > =1d43a4da660df4ba4c8b4c85339bfbda65c0d049
>> > >
>> > > These are spacewalk-backend packages for Spacewalk 1.9 containing
>> > > the fix above:
>> > >
>> > > http://koji.spacewalkproject.org/koji/buildinfo?buildID=30602
>> > >
>> > > I'll try to get these packages to Spacewalk 1.9 repo in a near future.
>> > >
>> > > Thank you for your report.
>> > > -Milan Zázrivec
>> > >
>> > > _______________________________________________
>> > > Spacewalk-list mailing list
>> > > Spacewalk-list at redhat.com
>> > > https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130308/eac50582/attachment.htm>