The directory we got problems with is the "../archives" directory. Apparently it happened during a server move when the permissions weren't transferred correctly. I'll start looking into this again when I fixed some more pressing problems ...
Bernd James Wanless wrote, On 21.04.2009 10:04 Uhr: > [pls bear in mind I don't know how 'standard' my setup is, but I tried > this on my dummy project, with similar results for the old (but fairly > recent) server_stable, compared to the developmental changeset version > 17851. Also, pls bear in mind I have not used the -gzip flag with > db_purge before...] > Anyway, > > current server_stable: > db_purge -min_age_days 7: > 209wu/464res archived, files in ../archives are of sizes, > 966307,8708,310859,3863 ie all present > db_purge -min_age_days 7 -gzip: > 209wu/464res archived, files in ../archives are of sizes, 98304,0,0,0 > ie exhibiting the bug under consideration, presumably > > changeset 17851: > db_purge -min_age_days 7: > 209wu/464res archived, files in ../archives are of sizes, > 966307,8708,310859,3863 ie all present > db_purge -min_age_days 7 -gzip: > 209wu/464res archived, files in ../archives are of sizes, 98304,0,0,0 > ie _still_ showing same bug present, apparently?? > > What exactly is the directory that needs write access that Bernd > referred to - I can try changing permissions on that if appropriate? > Also, in (all?) other respects, changeset 17851 checked out fine (at > least I didn't have any probelms w/ the normal routine of upgrade), > though I haven't done extensive testing, since this bug appears to be > the main issue for now... > J > > On 21 Apr 2009, at 04:27, David Anderson wrote: > >> I checked in a fix to trunk. >> Can someone please test this (including the unwriteable-dir case) >> before I check it in to server_stable? >> -- David >> >> Bernd Machenschalk wrote: >>> Hi! >>> >>> If the current db_purge program is set to gzip the archives and >>> encounters an error writing them (in our case the directory wasn't >>> writable), it just writes the error in the log and continues to >>> "archive" the results into nirvana: >>> >>> 2009-04-19 08:46:26.6223 [debug ] Archived result [122476313] to a >>> file >>> 2009-04-19 08:46:26.7304 [debug ] Purged result [122476313] from >>> database >>> 2009-04-19 08:46:26.7304 [debug ] Archived workunit [49157937] to >>> a file >>> 2009-04-19 08:46:26.8304 [debug ] Purged workunit [49157937] from >>> database >>> 2009-04-19 08:46:26.8305 [normal ] Closed archive file >>> ../archives/wu_archive_1240126442.xml.gz containing records of 1000 >>> workunits >>> 2009-04-19 08:46:26.8305 [normal ] Closed archive file >>> ../archives/result_archive_1240126442.xml.gz containing records of 1000 >>> workunits >>> 2009-04-19 08:46:26.8305 [normal ] Closed archive file >>> ../archives/result_index_1240126442.xml.gz containing records of 1000 >>> workunits >>> 2009-04-19 08:46:26.8306 [normal ] Closed archive file >>> ../archives/wu_index_1240126442.xml.gz containing records of 1000 >>> workunits >>> 2009-04-19 08:46:26.8306 [normal ] Closed archive files with 1000 >>> workunits >>> 2009-04-19 08:46:26.8310 [normal ] Archived 1000 workunits and 4846 >>> results >>> 2009-04-19 08:46:29.9680 [normal ] Opening archive >>> ../archives/wu_archive_1240130789.xml.gz >>> 2009-04-19 08:46:29.9687 [normal ] Opening archive >>> ../archives/result_archive_1240130789.xml.gz >>> 2009-04-19 08:46:29.9693 [normal ] Opening archive >>> ../archives/result_index_1240130789.xml.gz >>> sh: ../archives/wu_archive_1240130789.xml.gz: Permission denied >>> 2009-04-19 08:46:29.9723 [normal ] Opening archive >>> ../archives/wu_index_1240130789.xml.gz >>> sh: ../archives/result_archive_1240130789.xml.gz: Permission denied >>> sh: ../archives/result_index_1240130789.xml.gz: Permission denied >>> sh: ../archives/wu_index_1240130789.xml.gz: Permission denied >>> 2009-04-19 08:46:29.9875 [debug ] Archived result [119291362] to a >>> file >>> 2009-04-19 08:46:30.2184 [debug ] Purged result [119291362] from >>> database >>> 2009-04-19 08:46:30.2185 [debug ] Archived result [119291363] to a >>> file >>> 2009-04-19 08:46:30.3623 [debug ] Purged result [119291363] from >>> database >>> 2009-04-19 08:46:30.3626 [debug ] Archived result [120931871] to a >>> file >>> 2009-04-19 08:46:30.4623 [debug ] Purged result [120931871] from >>> database >>> 2009-04-19 08:46:30.4625 [debug ] Archived result [122480720] to a >>> file >>> >>> I think this is a bug, IMHO it should exit on such an error and stop >>> purging the DB. >>> >>> However, I think here the error happens asynchronously, i.e. not on >>> opening the pipe, as the command (gzip) itself apparently succeeds. >>> >>> The return values of the fprintf()s in archive_wu() shoud definitely be >>> checked (and maybe there are some more places I haven't caught at first >>> glance). >>> >>> If I am right, this fix should also go into the server_stable branch. >>> >>> Best, >>> Bernd >>> >>> _______________________________________________ >>> boinc_dev mailing list >>> [email protected] >>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>> To unsubscribe, visit the above URL and >>> (near bottom of page) enter your email address. >> >> _______________________________________________ >> boinc_dev mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
