Comment 42 for bug 1277589
Revision history for this message
| Diego Sarmentero (diegosarmentero) wrote Re: "FileNotFoundError: /var/lib/system-image/blacklist.tar.xz" | #42 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
I was just talking with Manuel, about this problem that seems to appears when concurrent requests are made to the System Image updates service for checkForUpdates.
Let me explain how System Settings works:
- When System Settings gets started, a process is called to determine if the Entry for System Updates needs to be shown in the main page of System Settings (The large button with the number of updates):
https:/
- If that process says that System Updates needs to be shown, the entry component is loaded in the UI, and the checkForUpdates call is made again to check how many updates needs to be shown in that component (the number at the right in the UI). For this situation, there is no conflict between the previous step and this one, because this second check is only triggered if the first one already finished and it says there was an update available.
- Then, if the System Updates button, or the System Updates entry in the main page of the System Settings UI is pressed, the Page for System Updates is loaded (which is another different binary and process from the previous two ones, that's because System Settings works using plugins for everything), so checkForUpdates needs to be triggered again for this situation to be able to populate the UI and show the different components in the UI according to the updates available.
https:/
- The last situation is when automatic updates is activated, this seems to be another process (I've not worked with that code), that triggers another checkForUpdates when System Settings is opened in order to decide if it needs to start upgrading the system.
So, if concurrent calls to checkForUpdates is the problem:
- The fourth situation is crashing with any of the two first situations.
- The Third situation could crash with any of the two first situations as well if the System Updates button is pressed fast, before the previous checks ends.
The Entry and PageComponent for System Updates plugins are in fact filtering the results to make sure that we show the results only once in case concurrent calls are made to checkForUpdates, but the problem here seems to be a raise condition between processes when the files that the System Image service needs to check if there is in fact an update available are being downloaded lots of times and overwritting between each other.
When this was tested using the system-image-dbus mock server to reproduce all the different scenarios here:
https:/
the only problem about concurrent calls was that a component could receive multiple results of a system update, and that was the fix that was made to filter that, but this specific problem didn't show up because probably the mock server is not downloading stuff to determine if there is an update.
Could it be possible for the System Image service to know if a current check for update is already in progress and avoid triggering that again??
In that way, any concurrent service trying to call that won't fail, and each of them will receive the notification because the response travels in the same dbus signals for each one.