Well, nonetheless, whatever the issue I tried the further hack as noted by Bob below. Didn’t change anything.
I installed 2.6.2, which went mostly well, but ran me out of space again. As it won’t be a huge loss to lose what we’ve got I was considering just rebuilding the server fresh, but then it occurred to me that maybe just deleting all the other uploads, then clearing out any leftover files from the repository directory (on the assumption those would be from the failed upload) might be the quicker solution. But, are there other things in the database that would need cleaning up as well? Does this make sense to try? Thanks. From: Shi, Yao-Bin (Larry, GBU-HPSW, Cloud and OS) [mailto:yao-bin....@hp.com] Sent: Tuesday, January 06, 2015 9:53 PM To: Gobeille, Robert; Woodvine, Brett Cc: fossology@lists.fossology.org Subject: RE: [FOSSology] Deleting a crashed upload It is a different issue with (http://www.fossology.org/issues/5763) – configuration issue, It looks like this issue is because adj2net is not finished, http://www.fossology.org/issues/6165 will fix this type of issue( when wgent_agent/ununpack/adj2nest fails). -Larry From: fossology [mailto:fossology-boun...@lists.fossology.org] On Behalf Of Gobeille, Robert Sent: Wednesday, January 07, 2015 3:17 AM To: Woodvine, Brett Cc: fossology@lists.fossology.org<mailto:fossology@lists.fossology.org> Subject: Re: [FOSSology] Deleting a crashed upload FWIW, the issue to clean this mess is http://www.fossology.org/issues/6165 There was an issue (http://www.fossology.org/issues/5763) to fix the problem where a failed ununpack would return success. It was closed as fixed, but apparently it is not fixed. I suspect that even though the ununpack_ars table entry was set to success, that if you look at the job scheduler it will show the ununpack failed. Because the job failed, adj2nest was never run (this creates a tree representation of the upload files). And because that didn’t run, the upload record upload_mode field was never updated to show that the upload was successful. This is why you can’t see the upload when you browse in the UI. If you want to continue this hack, find that ununpack_ars record and jot down the value for the upload_fk field. Then modify the upload table record where upload_pk = the upload_fk value. Set the upload_mode to 104 (it’s a bit field and this will set the upload to having succeeded. And no, I don’t know if there are other gotcha’s. This is a seat of the pants hack. Bob On Jan 6, 2015, at 11:59 AM, Woodvine, Brett <bwoodv...@sandw.com<mailto:bwoodv...@sandw.com>> wrote: Interestingly, once I got in there, there are no rows in that table with ars_success=FALSE. There is one row with the same date as the problem upload, but in the UI there are no uploads showing for that data to delete. From: Gobeille, Robert [mailto:bob.gobei...@hp.com] Sent: Tuesday, January 06, 2015 12:46 PM To: Woodvine, Brett Cc: Ma, Dong (Vincent, Open Source Program Office); fossology@lists.fossology.org<mailto:fossology@lists.fossology.org> Subject: Re: [FOSSology] Deleting a crashed upload Hi Brett, Unfortunately, the option you need (-Z remove orphaned files from the repository) hasn’t been added into the Maintenance section yet. Sorry about that. If you want to try and hack this you can go into the ununpack_ars table and find the failed unpack (ars_success = FALSE). Set it to true and then see if you can Organize > Uploads > Delete uploaded file. Bob Gobeille On Jan 6, 2015, at 8:56 AM, Woodvine, Brett <bwoodv...@sandw.com<mailto:bwoodv...@sandw.com>> wrote: Thanks Vincent - sorry for delay, been out through the holidays here. I’ve tried everything under the maintenance agent with no luck. From: Ma, Dong (Vincent, Open Source Program Office) [mailto:dong...@hp.com] Sent: Tuesday, December 23, 2014 8:21 PM To: Woodvine, Brett; 'fossology@lists.fossology.org<mailto:fossology@lists.fossology.org>' Subject: RE: Deleting a crashed upload There is one function you can try first is under Admin-Maintenance to queue the maintenance agent to clean up error data. Thanks, Vincent From: fossology [mailto:fossology-boun...@lists.fossology.org] On Behalf Of Woodvine, Brett Sent: 2014年12月24日 3:24 To: 'fossology@lists.fossology.org<mailto:fossology@lists.fossology.org>' Subject: [FOSSology] Deleting a crashed upload Hey folks. One of my users managed to try uploading something that was taking up so much space he filled my server, thus stopping everything including the upload. I managed to free enough space to get Fossology running again, but as the upload never finished, I can’t find it to delete it. I started to dig around and delete some files manually, but I’m thinking there has to be a better way to clean up this mess. Any suggestions? Besides just starting over fresh (which I’m tempted to do)! Thanks. This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.
_______________________________________________ fossology mailing list fossology@lists.fossology.org http://lists.fossology.org/mailman/listinfo/fossology
