koji

#3867 Noisy FileNotFoundError errors in hub logs
Closed: Fixed by tkopecek. Opened by mikem.

Closed: Fixed
Reopen Issue

These appear to be harmless, but they add noise and point to some behavior in GC_Importer that seems to be flawed.

It looks like every call to CG_Importer will result in a traceback during python gc. E.g.

Exception ignored in: <bound method _TemporaryFileCloser.__del__ of <tempfile._TemporaryFileCloser object at 0x7f5c9c812470>>
Traceback (most recent call last):
  File "/usr/lib64/python3.6/tempfile.py", line 452, in __del__
    self.close()
  File "/usr/lib64/python3.6/tempfile.py", line 448, in close
    unlink(self.name)
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/brew/work/tmpq6m5qoun'

This seems to be from this temporary file.

self.rpm_log_file = tempfile.NamedTemporaryFile(mode='w+', dir=koji.pathinfo.work())

which is later renamed if the import completes normally

self.rpm_log_file.write('CG import was SUCCESSFUL.\n')
safer_move(self.rpm_log_file.name, path)

When python tries to clean up the named temporary file it gets this error.

See also: #3257

Metadata Update from @mikem:
- Custom field Size adjusted to None

It doesn't look like there is a way to set the NamedTemporaryFile instance to not be deleted after it has been created (though we could just create it that way).

I'm not entirely sure that we really need to worry about deleting these files actually. In the normal case, we move them out of the way, and in the error case, it might be interesting to have the file around. However, if we do want to clean them up on error, we could either (1) do it ourselves (2) copy rather than move so that the tempfile deletion works.

If we do continue to use NameTemporaryFile, the I think we need to be careful to make sure the data is actually written to disk. Closing the file deletes it, so perhaps an explicit flush().

Also, the tempfile path could be chosen better. A prefix would make it much clearer what the file is for, and would have made debugging this easier.

If we do opt to leave the files in the error case, then we should probably use a directory under work/ rather than have the files directly under work.

Lastly, the scope of this log file is unclear. The variable is named rpm_log_file (very specific), but the final name is cg_import (very general). I think it does make sense to have a general cg import log. If so, we probably want to actually do that. That would mean renaming the variable and helper method, and logging more to it.

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.34

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.35 (was: 1.34)

PR #3905

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.34 (was: 1.35)

Metadata Update from @tkopecek:
- Issue tagged with: testing-ready

It looks like every call to CG_Importer will result in a traceback during python gc.

Ok, well not every call. self.rpm_log_file is only set if the cg import encounters an unmatched rpm, either as a buildroot component or an archive component.

Metadata Update from @mfilip:
- Issue tagged with: testing-done

Commit 5fcba0ba fixes this issue

Commit 2a549d44 relates to this ticket

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3867

Please continue any further discussion there.
Metadata
None

testing-done testing-ready

None
None
Low
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.