Bug 13868 - Python cache files get lost in packages
Summary: Python cache files get lost in packages
Status: NEW
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 2.6.4
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 6.99
Assignee: Unassigned
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2020-04-14 12:34 UTC by kweihmann
Modified: 2026-03-11 16:17 UTC (History)
7 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments
Log master (1.40 MB, text/x-log)
2020-04-14 12:34 UTC, kweihmann
no flags Details
log master 2 (1.40 MB, text/x-log)
2020-04-14 12:34 UTC, kweihmann
no flags Details
log thud (1.37 MB, text/x-log)
2020-04-14 12:35 UTC, kweihmann
no flags Details
log thud 2 (1.22 MB, text/x-log)
2020-04-14 12:35 UTC, kweihmann
no flags Details
log warrior (1.21 MB, text/x-log)
2020-04-14 12:35 UTC, kweihmann
no flags Details
log warrior 2 (1.52 MB, text/x-log)
2020-04-14 12:35 UTC, kweihmann
no flags Details
log zeus (1.37 MB, text/x-log)
2020-04-14 12:36 UTC, kweihmann
no flags Details
log zeus 2 (1.27 MB, text/x-log)
2020-04-14 12:36 UTC, kweihmann
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description kweihmann 2020-04-14 12:34:08 UTC
Created attachment 4659 [details]
Log master

Under certain (unknown) conditions cache files from python3 or python3-site-packages get lost while populating or stating, leading to stack traces like
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
     0001:
 *** 0002:extend_recipe_sysroot(d)
     0003:
File: '/build/poky/meta/classes/staging.bbclass', lineno: 551, function: extend_recipe_sysroot
     0547:                    dest = newmanifest[l]
     0548:                    if l.endswith("/"):
     0549:                        staging_copydir(l, targetdir, dest, seendirs)
     0550:                        continue
 *** 0551:                    staging_copyfile(l, targetdir, dest, postinsts, seendirs)
     0552:
     0553:    bb.note("Installed into sysroot: %s" % str(msg_adding))
     0554:    bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
     0555:
File: '/build/poky/meta/classes/staging.bbclass', lineno: 152, function: staging_copyfile
     0148:        os.symlink(linkto, dest)
     0149:        #bb.warn(c)
     0150:    else:
     0151:        try:
 *** 0152:            os.link(c, dest)
     0153:        except OSError as err:
     0154:            if err.errno == errno.EXDEV:
     0155:                bb.utils.copyfile(c, dest)
     0156:            else:
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc' -> '/build/poky/build/tmp/work/qemux86_64-mine-linux/core-image-minimal-mine/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc'

This affects only packages with python cache files and seems to be most likely to happen on very low-spec-systems with a lot of python-native packages to be injected into a workspace.

Very often this happens in a Github Actions VM using a Ubuntu 18.04 based container, but happens occasionally even on more powerful systems.

Specs of the mostly used systems
2-core CPU
7 GB of RAM memory
14 GB of SSD disk space
Ubuntu 18.04 based docker container running on Ubuntu 18.04

The actual missing cache file is pretty random (see the different attachments for more info) and this issue can be reproduced on all branches since thud (TBH branches before I didn't test).

Current workaround for me is to delete all cache files from every package before do_package (for python3-native also after preprocess of do_package), which fixes the symptoms but doesn't really cure the underlying issue
Comment 1 kweihmann 2020-04-14 12:34:47 UTC
Created attachment 4660 [details]
log master 2
Comment 2 kweihmann 2020-04-14 12:35:01 UTC
Created attachment 4661 [details]
log thud
Comment 3 kweihmann 2020-04-14 12:35:19 UTC
Created attachment 4662 [details]
log thud 2
Comment 4 kweihmann 2020-04-14 12:35:34 UTC
Created attachment 4663 [details]
log warrior
Comment 5 kweihmann 2020-04-14 12:35:56 UTC
Created attachment 4664 [details]
log warrior 2
Comment 6 kweihmann 2020-04-14 12:36:10 UTC
Created attachment 4665 [details]
log zeus
Comment 7 kweihmann 2020-04-14 12:36:26 UTC
Created attachment 4666 [details]
log zeus 2
Comment 8 Ross Burton 2020-06-04 08:03:37 UTC
That's not a failure during the build, but a failure of preparing the new sysroot.

The implication is that /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc doesn't exist, which is part of the python3-msgcheck-native sysroot. Can you see if that file definitely exists in the build?
Comment 9 kweihmann 2020-06-04 09:39:25 UTC
Yes it's normally there - if that error is occurring it isn't - so the shown error is rightfully complaining about it.
Behavior isn't really deterministic in this case.

I even had the case where is file was initially was created according to logs, but it didn't manifest into a file in the fs - unfortunately I didn't save a log for this one.
Comment 10 Randy MacLeod 2023-07-26 21:22:02 UTC
Bulk move of 64 bugs to 4.3 M3 after a quick review.
If a bug is actually fixed, please add a commit link and resolve it.
-- Randy for YP bug team.
Comment 11 Trevor Gamblin 2023-09-14 16:35:43 UTC
Moved to M4.
Comment 12 Randy MacLeod 2023-10-30 15:29:14 UTC
Bulk move to 5.0 M1. -- Randy
Comment 13 Randy MacLeod 2023-12-21 23:28:34 UTC
Bulk move of 52 5.0-M1 bugs to M2.
Comment 14 Randy MacLeod 2024-01-25 14:28:42 UTC
Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3.
Comment 15 Randy MacLeod 2024-02-22 19:53:21 UTC
Bulk move of bugs from 5.0-M3 to 5.99.
The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024.

If you disagree, please move back to a 5.[012...]-M* milestone.
Comment 16 Randy MacLeod 2026-03-11 15:41:12 UTC
Bump to 6.99.
Is this still happening?
Comment 17 Ross Burton 2026-03-11 16:16:05 UTC
FWIW I've never seen this.
Comment 18 Trevor Gamblin 2026-03-11 16:17:34 UTC
For the record, I've never seen this either.