[Spacewalk-list] SW 1.9 abrt crash upload fails

Pierre Casenove pcasenove at gmail.com
Fri Mar 8 18:20:27 UTC 2013 

Hello,
No, abrt stays at 1...
tu-spa-d13 ~ $ abrt-cli list
@0
Directory:      /var/spool/abrt/ccpp-2013-03-08-15:47:29-20599
count:          1
executable:     /bin/bash
package:        bash-4.1.2-14.el6
time:           Fri 08 Mar 2013 03:47:29 PM UTC
uid:            0

I must be missing something about abrt.

The client has been fully upgraded to RHEL 6.4.

Pierre


2013/3/8 Milan Zazrivec <mzazrivec at redhat.com>

> > 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?
>
> No, this is not expected.
>
> Does abrt correctly update content of the 'count' file in the crash
> directory?
> (since this is the number that spacewalk-abrt --update-count will report
> to the server).
>
> -MZ
>
> > 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&i
> > >> d
> > >>
> > >> > > =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
>
> _______________________________________________
> 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/7b74aaab/attachment.htm>

More information about the Spacewalk-list mailing list