Thanks very much for your reply [I'll hold off w/ my research for the moment then... (I've been trying a few more things, but kindof run out of ideas anyway for now - I'll say again, pls - it's quite possible I'm doing something stupid/non-standard)] J
On 21 Apr 2009, at 10:04, Bernd Machenschalk wrote: > 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.
