Linux test suite errors out due to failure to rename tmp file

[mrjerryjohns]

Problem

• In the PR validation for Fix all detectable thread races in chip-tool #7478, the Linux test suite was consistently failing with the following error:

[1623440422.218746][9357] CHIP:DL: writing settings to file (/tmp/chip_factory.ini.tmp)
[1623440422.218809][9356] CHIP:DL: writing settings to file (/tmp/chip_factory.ini.tmp)
[1623440422.218851][9357] CHIP:DL: renamed tmp file to file (/tmp/chip_factory.ini)
[1623440422.219006][9356] CHIP:DL: failed to rename (/tmp/chip_factory.ini.tmp), No such file or directory (2)
[1623440422.219041][9356] CHIP:DL: Configuration Manager initialization failed: CHIP Error 4175 (0x0000104F): Write to file failed
[1623440422.219055][9356] CHIP:-: Failed to run Linux Lighting App: CHIP Error 4175 (0x0000104F): Write to file failed 

Link to test failure: here.

[mrjerryjohns]

Since I haven't been able to repro this locally, my working theory so far is that both the all-clusters-app and chip-tool are racing with each other when writing to the same config file.

If you see the log lines above, you'll note this behavior:

1. Process PID Reduce PBUF_POOL size for k32w #9357 writes to the factory ini tmp file

[9357] CHIP:DL: writing settings to file (/tmp/chip_factory.ini.tmp)

2. Process PID (#6668): Some exchange has leak, shutting down ExchangeManager will cause a asse... #9356 writes to the same factory tmp file as well:

[9356] CHIP:DL: writing settings to file (/tmp/chip_factory.ini.tmp)

3. Process PID Reduce PBUF_POOL size for k32w #9357 then renames the tmp file to real name, deleting the tmp file in the process:

[9357] CHIP:DL: renamed tmp file to file (/tmp/chip_factory.ini)

4. Process PID (#6668): Some exchange has leak, shutting down ExchangeManager will cause a asse... #9356 tries to do the same, but the tmp file is no longer there:

[9356] CHIP:DL: failed to rename (/tmp/chip_factory.ini.tmp), No such file or directory (2)

It's likely #7478 makes this situation worse due to some timing changes, but fundamentally, the root cause here is that both applications are writing to the same config files.

Solution: Each application represents a logically distinct 'device', and as such, each of their configurations should be stored in separate files. This can be achieved through a command-line override to specify a particular prefix.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This stale issue has been automatically closed. Thank you for your contributions.