The same cooker log file name is reused for several builds, but only one file with that name exists, which could mean that cooker logs are being overwritten.
webhob-poky/master:aa7bec2e9dffd6901ebe3accf748ce458d1481a3
Hi Alex, Can you please tell me where can I find the patch for this issue? Thanks!
*** Bug 5502 has been marked as a duplicate of this bug. ***
This is caused by the same build name being used for all builds within a BitBake server session, as reported by bug 5502. I am marking the latter as a duplicate of this one.
This is the same problem as the resetting of server variables. marking dependency.
In order to have a different cooker log, the cooker should reset between builds. We have decided that the cooker should reset only if the client (like knotty) wants it, so not always. Since there is not a solution for this issue, I will close this bug.
I am sorry, but I am going to reopen this. We need to make sure Toaster does not display inaccurate information. Right now Toaster is telling me that the log for build x is in a certain file, when in fact that file probably contains the log for build y. To fix the problem, RP has suggested that Toaster should "reset the server" or "issue a command to tell the server to start a new log" Another alternative might be to store logs in the Toaster database and display their content within Toaster. In any case, we need to sort this out in 1.7.
This bug conflicts with 5603. This can go two ways: First option, I propose to implement a "reset server between builds" option in featureset. If the option in the feature set is set, the cooker is reset after each build. The memory resident server will start by default with the feature off, but when connection Toaster will request that the feature is turned on. Second option, we do not resolve 5603. 5603 seems like a dangerous bug to be anyway, because: * it will overwrite artifacts from previous builds * it will not pick up changes in configuration/metadata * it will have configuration options set at a reset time wrong, e.g. time and date dependent values Please weight in on the solution to be implemented.
This is set to 'needinfo' because it is a tricky problem to solve and we'll probably need some of RPs time to come up with the right solution (not because we are ignoring it).
/me needs to provide info...
Issue still present on 1.9 M1 rc1: 18e902b2dc17746af453869bcc1fba4dbae7c94f
To sumamrise where this is at, we've now merged: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=25702f3a2f78d13bab6bcca7e9dd331200ebdb09 which means that each build does see different DATE/TIME values and a unique BUILDNAME. This happens during the BuildStarted event. That resolves part of the problem here. Paul and I double checked the logging code and there never is log data loss, it is logged to BB_CONSOLELOG and new data is simply appeneded to the file. That log file really is the console log though, its not a "build log" or image build log. So the remaining question is whether toaster should be looking at the console log for the build (where it may not be clear where in the file the logs are valid from) or whether toaster should be using its own record of LogRecord events to display the logs to the user? I'm reassigning to Brian, on behalf of the toaster team to figure that out and take any further actions needed.
(In reply to comment #12) > > So the remaining question is whether toaster should be looking at the > console log for the build (where it may not be clear where in the file the > logs are valid from) or whether toaster should be using its own record of > LogRecord events to display the logs to the user? I am not sure I am understanding this fully, but it sounds as if what we have is a single file where the build logs are being appended, one after the other. If this is the case, this is probably not useful to Toaster users. What they need is a log file per build. That is their fundamental work unit, so a log with information for multiple builds is a nuisance, since they have to do the extra step of identifying which bit of the file corresponds to the build they are interested in. In short, we need a build log.
I did some work to fix cooker log downloads: we get a dated log for each build, which is what we link to from Toaster (it's what you get if you download the cooker.log file for a build). The path to this log file is read from BB_CONSOLELOG, at the point when the log file path is set for the current build (the variable's value changes as builds start, if I remember correctly). I suggest we get Paul and RP to confirm that this is the case, and ask QA to add some tests to ensure that the behaviour is correct in Toaster. (Our own tests of the fix were manual and not automated, due to the overhead of testing bitbake/toaster interactions.)
I've checked what's currently happening with those logs files, and this what I found: In management mode, everything is peachy. You get a different log file per build you run from Toaster, and when you click the 'download log' button, you download the correct log file. In interactive mode, a separate log file for each builds seems to be created in my tmp/log/cooker directory. But when I click the 'download log' button in Toaster, I always get the same log file (the one for the first build). Am I going crazy, or is there something broken?
It's likely that something is broken. Because the command line builds aren't triggered by Toaster, we may not catch the event containing the correct log file path. When I fixed the cooker log download, I only worked on fixing it for Toaster-triggered builds, rather than command line builds; I (probably incorrectly) assumed they would use the same mechanism to get the log file path. I think we need an issue to fix this for command line builds, if that's possible. We also still need Paul or RP to clarify exactly where log files go when command line builds are triggered, and when and how the path for the log file is set in this situation.
As explained in this comment https://bugzilla.yoctoproject.org/show_bug.cgi?id=5187#c15 Building from command line with master:7b86c771c80d0759c2ca0e57c46c4c966f89c49e created separate logs for my builds. I've opened bug 8373 to track the download log problem in analysis mode.
Verified on master: fc45deac89ef63ca1c44e763c38ced7dfd72cbe1