[PATCH v3 1/2] cooker: use BB_HASHSERVE_DB_DIR for hash server database location

[PATCH v3 1/2] cooker: use BB_HASHSERVE_DB_DIR for hash server database location

[Alexander Kanavin]

From: Alexander Kanavin <alex@linutronix.de>

If unset, the existing behavior is preseved.

The use case is sharing the database in bitbake-setup's driven builds
without having to set up/start/stop a common single server shared
between them (this is added to bitbake-setup in the next commit).

Also create the specified directory if it doesn't yet exist.

Add a check that the directory is not on a NFS path, and error out then,
guiding the user to set up a standalone hash equivalency server.

Note: the check runs 'stat' executable with a format string parameter,
ensuring it prints only the filesystem type and nothing else.
Python's standard library does not have a statfs() wrapper,
and using ctypes to call into it would've required delicate,
crash-prone data type definitions, full of magic numbers.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../bitbake-user-manual-ref-variables.rst     | 23 +++++++++++++++++++
 lib/bb/cooker.py                              | 11 ++++++++-
 lib/bb/utils.py                               |  8 +++++++
 3 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst b/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
index af911f306..4b3b10d46 100644
--- a/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
+++ b/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
@@ -475,6 +475,29 @@ overview of their function and contents.
       equivalences that correspond to Share State caches that are
       only available on specific clients.
 
+   :term:`BB_HASHSERVE_DB_DIR`
+      When :term:`BB_HASHSERVE` is set to ``auto``, bitbake will use
+      a private location inside a particular build directory for the sqlite
+      database file that holds hash equivalency data.
+
+      This variable allows using a different path, which can be shared
+      between multiple build directories and bitbake instances
+      that operate on them. This enables using a common ``${SSTATE_DIR}``
+      together with common hash equivalency data for local builds, without having to
+      separately manage a hash equivalency server.
+
+      .. note::
+
+         This variable cannot be set to a NFS mount and bitbake will error out then.
+         The reason is that NFS implementations can have file locking issues, which
+         can cause data loss and corruption when there are multiple writers operating
+         on a file at the same time as explained in https://sqlite.org/faq.html#q5
+
+         If you'd like to share hash equivalency data between multiple computers, you
+         need to set up a hash equivalency server separately and point :term:`BB_HASHSERVE`
+         to it. See https://docs.yoctoproject.org/dev-manual/hashequivserver.html for
+         additional information.
+
    :term:`BB_HASHSERVE_UPSTREAM`
       Specifies an upstream Hash Equivalence server.
 
diff --git a/lib/bb/cooker.py b/lib/bb/cooker.py
index fa7747d64..4b6ba3196 100644
--- a/lib/bb/cooker.py
+++ b/lib/bb/cooker.py
@@ -328,7 +328,16 @@ class BBCooker:
         if self.data.getVar("BB_HASHSERVE") == "auto":
             # Create a new hash server bound to a unix domain socket
             if not self.hashserv:
-                dbfile = (self.data.getVar("PERSISTENT_DIR") or self.data.getVar("CACHE")) + "/hashserv.db"
+                bb_hashserve_db_dir = self.data.getVar("BB_HASHSERVE_DB_DIR")
+                if bb_hashserve_db_dir and utils.is_path_on_nfs(bb_hashserve_db_dir):
+                    bb.fatal("""Hash equivalency database location (set via BB_HASHSERVE_DB_DIR to {})
+cannot be on a NFS mount due to potential NFS locking issues between sqlite clients, per https://sqlite.org/faq.html#q5
+
+If you need to share the database between several computers, set up a permanently running hash equivalency server
+according to https://docs.yoctoproject.org/dev-manual/hashequivserver.html""".format(bb_hashserve_db_dir))
+                dbdir = bb_hashserve_db_dir or self.data.getVar("PERSISTENT_DIR") or self.data.getVar("CACHE")
+                os.makedirs(dbdir, exist_ok=True)
+                dbfile = dbdir + "/hashserv.db"
                 upstream = self.data.getVar("BB_HASHSERVE_UPSTREAM") or None
                 if upstream:
                     try:
diff --git a/lib/bb/utils.py b/lib/bb/utils.py
index 366836bfc..974611bc7 100644
--- a/lib/bb/utils.py
+++ b/lib/bb/utils.py
@@ -2264,3 +2264,11 @@ def lock_timeout_nocheck(lock):
         if l:
             lock.release()
         sigmask(signal.SIG_SETMASK, s)
+
+def is_path_on_nfs(path):
+    """
+    Returns True if ``path`` argument is on a NFS mount.
+    """
+    import bb.process
+    fstype = bb.process.run("stat -f -c %T {}".format(path))[0].strip()
+    return fstype == "nfs"
-- 
2.47.3

[PATCH v3 2/2] bitbake-setup: share sstate by default between builds

[Alexander Kanavin]

From: Alexander Kanavin <alex@linutronix.de>

Nowadays sharing sstate must also include sharing the hash equivalency
information and thus, managing a hash equivalency server. There are
two ways to do it:

- starting/stopping the server outside the bitbake invocations, and
guaranteeing that it's available when bitbake is invoked.

- using bitbake's built-in start/stop code which launches a server
before a build starts and stops it when a build is finished; essentially
this is a private server, using a database private to a build directory
(by default).

I couldn't come up with a good way to do the first option in bitbake-setup:
it needs to be invisible to users, they should not have to run special commands
and they should not wonder why there is a mysterious background process.
It's not impossible to auto-start a shared server, but that will quickly
run into synchronization issues: if one server is being started, another
should not be started at the same time. If one server is shutting down
(e.g. after an inactivity timeout), another starting server should wait
until it frees the socket, and block all bitbake invocations on that.
Memory resident bitbake does this in lib/bb/server/process.py with a lot of
complexity, and I don't think it should be added to the hash server as well.

On the other hand, hash equivalency database is sqlite-driven, and sqlite
documentation reassures that sharing it between different simultaneous
processes is okay: nothing will get lost or corrupted: https://sqlite.org/faq.html#q5

I've confirmed this by running simultaneous builds that way: nothing
unusual happened, and sstate was shared as it's supposed to.

There's a new setting that turns off this behavior for situations
where the server and sstate are managed externally.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
v2: use ?= (weak assignments) for sstate variables to make it easier
to override them in particular builds, set hashserve db location
from value of SSTATE_DIR, rather than as direct value.

v3: use {{ }} to avoid brace-based format string expansion in python
and include literal braces instead.
---
 bin/bitbake-setup                             | 28 ++++++++++++++++++-
 .../bitbake-user-manual-environment-setup.rst | 19 +++++++++++++
 2 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/bin/bitbake-setup b/bin/bitbake-setup
index 7f6ea550c..f45cc8885 100755
--- a/bin/bitbake-setup
+++ b/bin/bitbake-setup
@@ -838,6 +838,31 @@ def create_siteconf(top_dir, non_interactive, settings):
 
         os.makedirs(top_dir, exist_ok=True)
         with open(siteconfpath, 'w') as siteconffile:
+            sstate_settings = textwrap.dedent(
+                """
+                #
+                # Where to place shared-state files
+                #
+                # BitBake has the capability to accelerate builds based on previously built output.
+                # This is done using "shared state" files which can be thought of as cache objects
+                # and this option determines where those files are placed.
+                #
+                # You can wipe out TMPDIR leaving this directory intact and the build would regenerate
+                # from these files if no changes were made to the configuration. If changes were made
+                # to the configuration, only shared state files where the state was still valid would
+                # be used (done using checksums).
+                SSTATE_DIR ?= "{sstate_dir}"
+                #
+                # Hash Equivalence database location
+                #
+                # Hash equivalence improves reuse of sstate by detecting when a given sstate
+                # artifact can be reused as equivalent, even if the current task hash doesn't
+                # match the one that generated the artifact. This variable controls where the
+                # Hash Equivalence database ("hashserv.db") is stored and can be shared between
+                # concurrent builds.
+                BB_HASHSERVE_DB_DIR ?= "${{SSTATE_DIR}}"
+                """.format(sstate_dir=os.path.join(top_dir, ".sstate-cache"))
+            )
             siteconffile.write(
                 textwrap.dedent(
                     """\
@@ -855,7 +880,7 @@ def create_siteconf(top_dir, non_interactive, settings):
                     """.format(
                         dl_dir=settings["default"]["dl-dir"],
                     )
-                )
+                ) + (sstate_settings if settings["default"]["common-sstate"] == 'yes' else "")
             )
 
 
@@ -1061,6 +1086,7 @@ def main():
                          'top-dir-name':'bitbake-builds',
                          'registry':default_registry,
                          'use-full-setup-dir-name':'no',
+                         'common-sstate':'yes',
                          }
 
         global_settings = load_settings(global_settings_path(args))
diff --git a/doc/bitbake-user-manual/bitbake-user-manual-environment-setup.rst b/doc/bitbake-user-manual/bitbake-user-manual-environment-setup.rst
index 3b6a73fd8..b7212f1af 100644
--- a/doc/bitbake-user-manual/bitbake-user-manual-environment-setup.rst
+++ b/doc/bitbake-user-manual/bitbake-user-manual-environment-setup.rst
@@ -517,6 +517,7 @@ A valid settings file would for example be:
    registry = /path/to/bitbake/default-registry
    dl-dir = /path/to/bitbake-setup-downloads
    use-full-setup-dir-name = yes
+   common-sstate = yes
 
 Settings and their values can be listed and modified with the ``bitbake-setup
 settings`` command. See the :ref:`ref-bbsetup-command-settings` section for
@@ -621,6 +622,24 @@ will override the suggestions for the :term:`Setup` directory name made by
 will make the directory names longer, but fully specific: they will contain
 all selections made during initialization.
 
+.. _ref-bbsetup-setting-common-sstate:
+
+``common-sstate``
+-----------------
+
+When this setting is set to ``yes`` (which is also the default), bitbake-setup will
+set up a common sstate directory and common hash equivalency database for all the
+:term:`setups <Setup>` in a :term:`Top Directory`. This is very beneficial for speeding
+up builds as build artefacts will be reused whenever possible between them.
+
+Set this to ``no`` for advanced use cases, such as placing the sstate directory on a NFS
+mount and maintaining a separate hash equivalency server, so that sstate and hash equivalency
+data can be shared between several computers. For such use cases the sstate settings need
+to be added to a build configuration separately.
+
+See https://docs.yoctoproject.org/dev-manual/hashequivserver.html for how to share sstate
+on the network.
+
 .. _ref-bbsetup-section-config-reference:
 
 Generic Configuration Files Reference
-- 
2.47.3

Re: [bitbake-devel] [PATCH v3 2/2] bitbake-setup: share sstate by default between builds

[Antonin Godard]

On Thu Jan 29, 2026 at 1:04 PM CET, Alexander Kanavin via lists.openembedded.org wrote:
[...]
> +            sstate_settings = textwrap.dedent(
> +                """
> +                #
> +                # Where to place shared-state files
> +                #
> +                # BitBake has the capability to accelerate builds based on previously built output.
> +                # This is done using "shared state" files which can be thought of as cache objects
> +                # and this option determines where those files are placed.
> +                #
> +                # You can wipe out TMPDIR leaving this directory intact and the build would regenerate
> +                # from these files if no changes were made to the configuration. If changes were made
> +                # to the configuration, only shared state files where the state was still valid would
> +                # be used (done using checksums).
> +                SSTATE_DIR ?= "{sstate_dir}"

Nitpicky I know , but we should add a line return here, as DL_DIR above is
already separated from SSTATE_DIR by a line return.

> +                #
> +                # Hash Equivalence database location
> +                #
> +                # Hash equivalence improves reuse of sstate by detecting when a given sstate
> +                # artifact can be reused as equivalent, even if the current task hash doesn't
> +                # match the one that generated the artifact. This variable controls where the
> +                # Hash Equivalence database ("hashserv.db") is stored and can be shared between
> +                # concurrent builds.
> +                BB_HASHSERVE_DB_DIR ?= "${{SSTATE_DIR}}"
> +                """.format(sstate_dir=os.path.join(top_dir, ".sstate-cache"))
> +            )

Antonin

Re: [bitbake-devel] [PATCH v3 2/2] bitbake-setup: share sstate by default between builds

[Alexander Kanavin]

On Thu, 5 Feb 2026 at 12:08, Antonin Godard <antonin.godard@bootlin.com> wrote:
> > +                SSTATE_DIR ?= "{sstate_dir}"
>
> Nitpicky I know , but we should add a line return here, as DL_DIR above is
> already separated from SSTATE_DIR by a line return.

You could also argue that the two sstate settings are in a group, and
should be visually 'together'.

Alex

Re: [bitbake-devel] [PATCH v3 2/2] bitbake-setup: share sstate by default between builds

[Antonin Godard]

On Thu Feb 5, 2026 at 12:12 PM CET, Alexander Kanavin wrote:
> On Thu, 5 Feb 2026 at 12:08, Antonin Godard <antonin.godard@bootlin.com> wrote:
>> > +                SSTATE_DIR ?= "{sstate_dir}"
>>
>> Nitpicky I know , but we should add a line return here, as DL_DIR above is
>> already separated from SSTATE_DIR by a line return.
>
> You could also argue that the two sstate settings are in a group, and
> should be visually 'together'.

I didn't think it that way, up to you. It's just the way things were organized
prior, in the template files.

Antonin

Re: [bitbake-devel] [PATCH v3 2/2] bitbake-setup: share sstate by default between builds

[Mathieu Dubois-Briand]

On Thu Jan 29, 2026 at 1:04 PM CET, Alexander Kanavin via lists.openembedded.org wrote:
> From: Alexander Kanavin <alex@linutronix.de>
>
> Nowadays sharing sstate must also include sharing the hash equivalency
> information and thus, managing a hash equivalency server. There are
> two ways to do it:
>
> - starting/stopping the server outside the bitbake invocations, and
> guaranteeing that it's available when bitbake is invoked.
>
> - using bitbake's built-in start/stop code which launches a server
> before a build starts and stops it when a build is finished; essentially
> this is a private server, using a database private to a build directory
> (by default).
>
> I couldn't come up with a good way to do the first option in bitbake-setup:
> it needs to be invisible to users, they should not have to run special commands
> and they should not wonder why there is a mysterious background process.
> It's not impossible to auto-start a shared server, but that will quickly
> run into synchronization issues: if one server is being started, another
> should not be started at the same time. If one server is shutting down
> (e.g. after an inactivity timeout), another starting server should wait
> until it frees the socket, and block all bitbake invocations on that.
> Memory resident bitbake does this in lib/bb/server/process.py with a lot of
> complexity, and I don't think it should be added to the hash server as well.
>
> On the other hand, hash equivalency database is sqlite-driven, and sqlite
> documentation reassures that sharing it between different simultaneous
> processes is okay: nothing will get lost or corrupted: https://sqlite.org/faq.html#q5
>
> I've confirmed this by running simultaneous builds that way: nothing
> unusual happened, and sstate was shared as it's supposed to.
>
> There's a new setting that turns off this behavior for situations
> where the server and sstate are managed externally.
>
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---

Hi Alex,

I noted some performance regression on the autobuilder with this patch.
I did not had time to fully investigate the underlying reasons so far,
but I'm fairly convinced they were introduced by this change.

This is visible at least on selftest builds, rising from 1-3 hours to
something like 5-8 hours.

A build with my branch on the commit just before: https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3158
A build with my branch on this commit: https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3161

Some tests appear to be way longer to run, typically:

2026-02-05 11:26:19,583 - oe-selftest - INFO - buildoptions.ArchiverTest.test_arch_work_dir_and_export_source (subunit.RemotedTestCase)
2026-02-05 11:26:19,583 - oe-selftest - INFO -  ... ok
2026-02-05 11:26:19,583 - oe-selftest - INFO - 11: 1/34 11/664 (36.33s) (0 failed) (buildoptions.ArchiverTest.test_arch_work_dir_and_export_source)

2026-02-05 15:48:59,247 - oe-selftest - INFO - buildoptions.ArchiverTest.test_arch_work_dir_and_export_source (subunit.RemotedTestCase)
2026-02-05 15:48:59,247 - oe-selftest - INFO -  ... ok
2026-02-05 15:48:59,247 - oe-selftest - INFO - 11: 1/34 59/664 (1568.37s) (0 failed) (buildoptions.ArchiverTest.test_arch_work_dir_and_export_source)

Maybe the configuration is clashing with the configuration we have on
the autobuilder, or maybe this is just something else in my branch.

I will try to get a better view of the situation, but I wanted to first
note this before the patch get merged.

Thanks,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [bitbake-devel] [PATCH v3 2/2] bitbake-setup: share sstate by default between builds

[Alexander Kanavin]

On Mon, 9 Feb 2026 at 14:09, Mathieu Dubois-Briand
<mathieu.dubois-briand@bootlin.com> wrote:
> I noted some performance regression on the autobuilder with this patch.
> I did not had time to fully investigate the underlying reasons so far,
> but I'm fairly convinced they were introduced by this change.
>
> This is visible at least on selftest builds, rising from 1-3 hours to
> something like 5-8 hours.
>
> A build with my branch on the commit just before: https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3158
> A build with my branch on this commit: https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3161
>
> Some tests appear to be way longer to run, typically:
>
> 2026-02-05 11:26:19,583 - oe-selftest - INFO - buildoptions.ArchiverTest.test_arch_work_dir_and_export_source (subunit.RemotedTestCase)
> 2026-02-05 11:26:19,583 - oe-selftest - INFO -  ... ok
> 2026-02-05 11:26:19,583 - oe-selftest - INFO - 11: 1/34 11/664 (36.33s) (0 failed) (buildoptions.ArchiverTest.test_arch_work_dir_and_export_source)
>
> 2026-02-05 15:48:59,247 - oe-selftest - INFO - buildoptions.ArchiverTest.test_arch_work_dir_and_export_source (subunit.RemotedTestCase)
> 2026-02-05 15:48:59,247 - oe-selftest - INFO -  ... ok
> 2026-02-05 15:48:59,247 - oe-selftest - INFO - 11: 1/34 59/664 (1568.37s) (0 failed) (buildoptions.ArchiverTest.test_arch_work_dir_and_export_source)
>
> Maybe the configuration is clashing with the configuration we have on
> the autobuilder, or maybe this is just something else in my branch.

Thanks Mathieu, we're aware of this, and the patch is used as a
'canary' to find where SSTATE_DIR isn't set entirely correctly.
Particularly, config.json is using ?=, and I believe it should be a
hard assignment with =

https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n38

Alex

Re: [bitbake-devel] [PATCH v3 2/2] bitbake-setup: share sstate by default between builds

[Richard Purdie]

On Mon, 2026-02-09 at 14:55 +0100, Alexander Kanavin wrote:
> On Mon, 9 Feb 2026 at 14:09, Mathieu Dubois-Briand
> <mathieu.dubois-briand@bootlin.com> wrote:
> > I noted some performance regression on the autobuilder with this patch.
> > I did not had time to fully investigate the underlying reasons so far,
> > but I'm fairly convinced they were introduced by this change.
> > 
> > This is visible at least on selftest builds, rising from 1-3 hours to
> > something like 5-8 hours.
> > 
> > A build with my branch on the commit just before: https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3158
> > A build with my branch on this commit: https://autobuilder.yoctoproject.org/valkyrie/#/builders/35/builds/3161
> > 
> > Some tests appear to be way longer to run, typically:
> > 
> > 2026-02-05 11:26:19,583 - oe-selftest - INFO - buildoptions.ArchiverTest.test_arch_work_dir_and_export_source (subunit.RemotedTestCase)
> > 2026-02-05 11:26:19,583 - oe-selftest - INFO -  ... ok
> > 2026-02-05 11:26:19,583 - oe-selftest - INFO - 11: 1/34 11/664 (36.33s) (0 failed) (buildoptions.ArchiverTest.test_arch_work_dir_and_export_source)
> > 
> > 2026-02-05 15:48:59,247 - oe-selftest - INFO - buildoptions.ArchiverTest.test_arch_work_dir_and_export_source (subunit.RemotedTestCase)
> > 2026-02-05 15:48:59,247 - oe-selftest - INFO -  ... ok
> > 2026-02-05 15:48:59,247 - oe-selftest - INFO - 11: 1/34 59/664 (1568.37s) (0 failed) (buildoptions.ArchiverTest.test_arch_work_dir_and_export_source)
> > 
> > Maybe the configuration is clashing with the configuration we have on
> > the autobuilder, or maybe this is just something else in my branch.
> 
> Thanks Mathieu, we're aware of this, and the patch is used as a
> 'canary' to find where SSTATE_DIR isn't set entirely correctly.
> Particularly, config.json is using ?=, and I believe it should be a
> hard assignment with =
> 
> https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json#n38

I did try that:

https://git.yoctoproject.org/yocto-autobuilder-helper/commit/?h=master-next

however it still lead to eSDK failures:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/29/builds/3177

which makes me wonder if we're still missing some detail about how we
think this works vs. the reality. :/

Cheers,

Richard

Re: [bitbake-devel] [PATCH v3 1/2] cooker: use BB_HASHSERVE_DB_DIR for hash server database location

[Jose Quaresma]

[-- Attachment #1: Type: text/plain, Size: 6187 bytes --]

Alexander Kanavin via lists.openembedded.org <alex.kanavin=
gmail.com@lists.openembedded.org> escreveu (quinta, 29/01/2026 à(s) 12:04):

> From: Alexander Kanavin <alex@linutronix.de>
>
> If unset, the existing behavior is preseved.
>
> The use case is sharing the database in bitbake-setup's driven builds
> without having to set up/start/stop a common single server shared
> between them (this is added to bitbake-setup in the next commit).
>
> Also create the specified directory if it doesn't yet exist.
>
> Add a check that the directory is not on a NFS path, and error out then,
> guiding the user to set up a standalone hash equivalency server.
>
> Note: the check runs 'stat' executable with a format string parameter,
> ensuring it prints only the filesystem type and nothing else.
> Python's standard library does not have a statfs() wrapper,
> and using ctypes to call into it would've required delicate,
> crash-prone data type definitions, full of magic numbers.
>
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  .../bitbake-user-manual-ref-variables.rst     | 23 +++++++++++++++++++
>  lib/bb/cooker.py                              | 11 ++++++++-
>  lib/bb/utils.py                               |  8 +++++++
>  3 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
> b/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
> index af911f306..4b3b10d46 100644
> --- a/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
> +++ b/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
> @@ -475,6 +475,29 @@ overview of their function and contents.
>        equivalences that correspond to Share State caches that are
>        only available on specific clients.
>
> +   :term:`BB_HASHSERVE_DB_DIR`
> +      When :term:`BB_HASHSERVE` is set to ``auto``, bitbake will use
> +      a private location inside a particular build directory for the
> sqlite
> +      database file that holds hash equivalency data.
> +
> +      This variable allows using a different path, which can be shared
> +      between multiple build directories and bitbake instances
> +      that operate on them. This enables using a common ``${SSTATE_DIR}``
> +      together with common hash equivalency data for local builds,
> without having to
> +      separately manage a hash equivalency server.
> +
> +      .. note::
> +
> +         This variable cannot be set to a NFS mount and bitbake will
> error out then.
> +         The reason is that NFS implementations can have file locking
> issues, which
> +         can cause data loss and corruption when there are multiple
> writers operating
> +         on a file at the same time as explained in
> https://sqlite.org/faq.html#q5
> +
> +         If you'd like to share hash equivalency data between multiple
> computers, you
> +         need to set up a hash equivalency server separately and point
> :term:`BB_HASHSERVE`
> +         to it. See
> https://docs.yoctoproject.org/dev-manual/hashequivserver.html for
> +         additional information.
> +
>     :term:`BB_HASHSERVE_UPSTREAM`
>        Specifies an upstream Hash Equivalence server.
>
> diff --git a/lib/bb/cooker.py b/lib/bb/cooker.py
> index fa7747d64..4b6ba3196 100644
> --- a/lib/bb/cooker.py
> +++ b/lib/bb/cooker.py
> @@ -328,7 +328,16 @@ class BBCooker:
>          if self.data.getVar("BB_HASHSERVE") == "auto":
>              # Create a new hash server bound to a unix domain socket
>              if not self.hashserv:
> -                dbfile = (self.data.getVar("PERSISTENT_DIR") or
> self.data.getVar("CACHE")) + "/hashserv.db"
> +                bb_hashserve_db_dir =
> self.data.getVar("BB_HASHSERVE_DB_DIR")
> +                if bb_hashserve_db_dir and
> utils.is_path_on_nfs(bb_hashserve_db_dir):
>

There is little issue on this, we should check if the bb_hashserve_db_dir
exists on the file system first before checking the is_path_on_nfs.
Because is the user provide a path that does not exist and will be created
bellow in os.makedirs it fails with:

stat: cannot read file system information for '/path/to/my/hashserve': No
such file or directory

Jose

+                    bb.fatal("""Hash equivalency database location (set
> via BB_HASHSERVE_DB_DIR to {})
> +cannot be on a NFS mount due to potential NFS locking issues between
> sqlite clients, per https://sqlite.org/faq.html#q5
> +
> +If you need to share the database between several computers, set up a
> permanently running hash equivalency server
> +according to
> https://docs.yoctoproject.org/dev-manual/hashequivserver.html
> """.format(bb_hashserve_db_dir))
> +                dbdir = bb_hashserve_db_dir or
> self.data.getVar("PERSISTENT_DIR") or self.data.getVar("CACHE")
> +                os.makedirs(dbdir, exist_ok=True)
> +                dbfile = dbdir + "/hashserv.db"
>                  upstream = self.data.getVar("BB_HASHSERVE_UPSTREAM") or
> None
>                  if upstream:
>                      try:
> diff --git a/lib/bb/utils.py b/lib/bb/utils.py
> index 366836bfc..974611bc7 100644
> --- a/lib/bb/utils.py
> +++ b/lib/bb/utils.py
> @@ -2264,3 +2264,11 @@ def lock_timeout_nocheck(lock):
>          if l:
>              lock.release()
>          sigmask(signal.SIG_SETMASK, s)
> +
> +def is_path_on_nfs(path):
> +    """
> +    Returns True if ``path`` argument is on a NFS mount.
> +    """
> +    import bb.process
> +    fstype = bb.process.run("stat -f -c %T {}".format(path))[0].strip()
> +    return fstype == "nfs"
> --
> 2.47.3
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#18933):
> https://lists.openembedded.org/g/bitbake-devel/message/18933
> Mute This Topic: https://lists.openembedded.org/mt/117524701/5052612
> Group Owner: bitbake-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [
> quaresma.jose@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
Best regards,

José Quaresma

[-- Attachment #2: Type: text/html, Size: 8538 bytes --]

Re: [bitbake-devel] [PATCH v3 1/2] cooker: use BB_HASHSERVE_DB_DIR for hash server database location

[Alexander Kanavin]

On Tue, 10 Feb 2026 at 16:36, Jose Quaresma <quaresma.jose@gmail.com> wrote:
>> +                bb_hashserve_db_dir = self.data.getVar("BB_HASHSERVE_DB_DIR")
>> +                if bb_hashserve_db_dir and utils.is_path_on_nfs(bb_hashserve_db_dir):
>
>
> There is little issue on this, we should check if the bb_hashserve_db_dir exists on the file system first before checking the is_path_on_nfs.
> Because is the user provide a path that does not exist and will be created bellow in os.makedirs it fails with:
>
> stat: cannot read file system information for '/path/to/my/hashserve': No such file or directory

The patch has merged to master, can you make a followup please?

Alex

Re: [bitbake-devel] [PATCH v3 1/2] cooker: use BB_HASHSERVE_DB_DIR for hash server database location

[Jose Quaresma]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

Alexander Kanavin <alex.kanavin@gmail.com> escreveu (quarta, 11/02/2026
à(s) 11:39):

> On Tue, 10 Feb 2026 at 16:36, Jose Quaresma <quaresma.jose@gmail.com>
> wrote:
> >> +                bb_hashserve_db_dir =
> self.data.getVar("BB_HASHSERVE_DB_DIR")
> >> +                if bb_hashserve_db_dir and
> utils.is_path_on_nfs(bb_hashserve_db_dir):
> >
> >
> > There is little issue on this, we should check if the
> bb_hashserve_db_dir exists on the file system first before checking the
> is_path_on_nfs.
> > Because is the user provide a path that does not exist and will be
> created bellow in os.makedirs it fails with:
> >
> > stat: cannot read file system information for '/path/to/my/hashserve':
> No such file or directory
>
> The patch has merged to master, can you make a followup please?
>
> Alex
>

Sure, I am still doing some tests and will propose a fix today or tomorrow.

-- 
Best regards,

José Quaresma

[-- Attachment #2: Type: text/html, Size: 1584 bytes --]