> 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@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 <[email protected]> > > > > 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@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 > > [email protected] > > https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
