Description of problem: maketemp in /usr/share/rhn/config_common/file_utils.py_orig has timing issues. It constructs tempfiles in a way where it can only have one tempfile per second. It tries ten times. Fast systems can do this more often and can't create a tempfile. This happens on fast systems with use of installation profiles (via rhnreg_ks) on RHEL 5 and RHEL 4. Version-Release number of selected component (if applicable): Should be independeng of Red Hat Network (RHN) Satellite version, but will check How reproducible: Always. Steps to Reproduce: 1. Try to deploy more than ten config files on a very fast client machine such that that those ten are run in the same second. Actual results: Unable to create tempfile(s) Expected results: Successful tempfile creation and config file deployment regardless of how many files user tries to deploy on a fast machine Additional info: Customer's using workaround to increase tempfile creation iterations from 10 to 59 in the code.
Proposed patch from support is attached - file_utils.py.patch. It uses tempfile.mkstemp for temp file creation. If we don't clean up temp files, maybe alternatively consider tempfile.NamedTemporaryFile - however that will delete the file as soon as its closed - or will need to clean it up after use.
Created attachment 381901 [details] file_utils.py.patch
Patch applied with preserving pid as a part of the temp filename. spacewalk.git: 9a8e2ce1a02b731e915815235520cceae08db1ac
satellite.git SATELLITE-5.3: f49230a4cc587470509151a837fb61efd1e5de1d
From the research and testing I did it turned out that the reason why the bug appeared is the fact that not all systems provide time with a better precision than 1 second. This has direct impact to the time.time() function that was in use. In this case the temporary file name format is like /tmp/test_temp-20468-1283174059. In case the system provides time with a better precision than 1 second the temporary file name is like "/tmp/test_temp-20463-1283174058.92823195" and the problem does not appear. In order the issue to be avoided in the fix is used tempfile.mkstemp function that creates temp files in format that does not depend on system time. Example: /tmp/test_temp-30533-Ybpw51 /tmp/test_temp-30533-YWJojh /tmp/test_temp-30533-zxIW0W /tmp/test_temp-30533-ZyXptw I tested all the functionality of the RHN Manager,Client and Action Control features after the fix was applied (v.5.9.5-6) and I have not found any impact.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Due to incorrect timing, a temporary file creation may have failed, and thus prevent the configuration file from being deployed. This error has been fixed, and temporary files are now always created as expected.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -Due to incorrect timing, a temporary file creation may have failed, and thus prevent the configuration file from being deployed. This error has been fixed, and temporary files are now always created as expected.+Due to incorrect timing, a temporary file creation may have failed, preventing the configuration file from being deployed. This error has been fixed, and temporary files are now always created as expected.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0761.html