We use Continua CI to run FinalBuilder8 projects. The FinalBuilder stage uses default setting for the log file location so logs are created under …\AppData\local\temp on the C: drive (which is not our data disk where the actual project file is stored).
Suddenly today these temporary files was filling up the C: drive and this has never been a problem before. This might have been caused by unusually big log files.
So the question is if there is some cleanup build into Continua (or FinalBuilder8) or I have to setup some cleanup myself?
FinalBuilder 8 is responsible for cleaning up its own temporary log files. We’ve just tested that and it is working here. Which build version of FinalBuilder 8 are you using?
Maybe the FBCmd process is not shutting down correctly? This could be due to a hanging child process. Can you check the build logs in the Continua CI for any sign of process termination?
Note that Continua CI does have a feature for cleaning up the build workspace - see Cleanup - Continua CI - VSoft Technologies Documentation Wiki. This does not, however, include build artefacts from tools such as FinalBuilder which are located outside of the workspace.
We are using FinalBuilder 8 version 2943.
I watched the “temp” folder yesterday while builds where running and logs where nicely cleaned up.
However, this morning there was a FinalBuilder (32bit) process hanging using more than 1930MB of memory, using a lot of CPU and having a log file in “temp” using 16.5 GB.
We have recently made new build configurations so I will try to investigate what triggers this behaviur.
At this very moment I am seeing something strange: One FinalBuilder (32bit) process running which complies with number of running Continua builds, but there are five (5) temporary log files!
Each of these in the size range 3 to 5 MB.
Ok, apparently this happens when some builds are manually stopped. Which again tells me that some sort of cleaning is needed of the “temp” folder.
The 3-5 MB files should be cleaned over time, and are not dangerous for the stability of the server.
We’re currently investigating ways for Continua CI to shutdown FinalBuilder cleanly to ensure that its cleanup process always gets run. We hope to work out something for the next version.
Meanwhile, if your FinalBuilder projects are always running in the build workspace, you can change the Log File Location to ‘working folder’. The easiest way to do this is by changing the default behaviour. Create a new agent property with the namespace ‘FinalBuilder.Options’ and name ‘UseTempLog’ and sets the value to ‘False’. This can be done for each agent on the Agents page in the Administration section.
Hi Dave
I think my original question about agent workspace cleanup is answered, but I still have questions about very big FinalBuilder 8 log files (more than 10 GB).
Do you want these questions to be a different thread on the forum (only related to FinalBuilder 8)?
I managed to see some of a 20 GB temporary log file by copying the project file to one with the temporary name and opening this project in the IDE.
I can see that my problem happens because one thread in an “Async Group” fails. When this happens I set a “AsyncGroupFailure” Boolean that should allow all other threads in the group to exit.
Apparently one group thread keeps running and logging forever.
Sadly I can not see what happens in the thread that keeps running because the IDE crashes if I try. Is there some other tool that I can use to view big log files?
The log files are an embedded database, if the IDE is crashing then that would suggest the log file is corrupted.
If you are able to, send us your project file (to support@finalbuilder.com) and we’ll take a look and see if we can spot an issue with it… if we don’t see an issue then it might be worth us recreating the same scenario to test if it’s a bug or not.
I was lucky and caught the situation when the log file was only 1.5 GB and was able to read this log file.
It turned out I had missed to make one while loop check my “AsyncGroupFailure” Boolean and thus one thread in the group never exited after a fatal error in another group thread.
This while loop then produced big log files. The thread with the fatal error is communicating with a VMM (Hyper-V) that in rare situations returns an error for a given command.
It would be great if there was a much more simple way to make an “Async Group” exit all threads when one thread has a fatal error and do not produce the result that another group thread is waiting for!