Good Morning Everyone.
On Friday my customer uploaded Cygwin for analysis. I think it was a zip file.
The job ran from 11:23am until I deleted it at around 8am on Sunday. I had to
delete it because it caused Fossology scheduler to keep restarting. And that
was causing the load average on the
Did your disk fill up?
Take a look at the log file to see if you can identify what was being processed
when the scheduler died.
Mary
From: fossology-boun...@fossology.org [mailto:fossology-boun...@fossology.org]
On Behalf Of Westphal, Raymond W
Sent: Monday, May 23, 2011 6:32 AM
To:
Hi Ray,
I just grabbed the source from the cygwin cvs, tared and uploaded it. On the
system I used it took 7 minutes.
http://repo.fossology.org/simpleIndex.php?mod=nomoslicenseshow=detailupload=148item=50608165
We have seen the scheduler problem you describe before. I think, as long as
you
Good Morning Bob/Good Morning Mary.
Here is the info. from the log just prior to where the scheduler started its
cycle of not responding and then restarting.
2011-05-20 13:51:46 scheduler[8691] : Child[1] 'agent=unpack host=localhost '
state=FREEING(2) @ Fri May 20 13:51:46 2011
2011-05-20
Hi Ray,
Thanks for telling us about the missing RHEL5 packages. They're there now :)
When I've seen this type of behavior log file messaging, it usually means the
unpack was not responding to the scheduler because it was having trouble
unpacking a particular file OR the db was having
Hi Mary.
I just download the RHEL5 rpm! Hooray!
Yes the autovacuum has been configured and appears to be working.
Here is an interesting and often repeated section from the postgresql-Sat.log
.
LOG: could not send data to client: Broken pipe
LOG: unexpected EOF on client connection
Hello Bob,
I learned from the user that the zip file he analyzes is built based upon
options he chooses from a Cygwin menu. He believes it contains both source and
binary files. So it is very different from the file you analyzed. It is 450MB!
I'm going to try the upgrade to Fossology 1.4.0 and
7 matches
Mail list logo
