uuid1 generates identical UUIDs after a fork, even though it returns SafeUUID.safe

[guillaumematheron]

Bug report

Minimal reproductible example:

import os
from uuid import uuid1

print(uuid1(), flush=True)
os.fork()
u = uuid1()
print(u, u.is_safe)

Expected output: Either all UUIDs are different, or u.is_safe is not safe

Actual output:

774c65f2-03e1-11ee-a9b2-134f3c9f0156
774c65f3-03e1-11ee-a9b2-134f3c9f0156 SafeUUID.safe
774c65f3-03e1-11ee-a9b2-134f3c9f0156 SafeUUID.safe

If the initial call to uuid1() is omitted, or if using spawn instead of fork, then the bug is not triggered.

By following the code, the underlying function called seems to be uuid_generate_time_safe. I was not able to reproduce the bug outside of python by calling the C method directly, so I assume python sets a global state the first time uuid1() is called, and this state is copied when the fork occurs.

This issue was originally discovered in clickhouse-connect then discussed in the context of multiprocessing.

Documentation issue

This may require a separate issue, but the documentation of uuid1() states:

uuid.uuid1(node=None, clock_seq=None)

Generate a UUID from a host ID, sequence number, and the current time. If node is not given, getnode() is used to obtain the hardware address. If clock_seq is given, it is used as the sequence number; otherwise a random 14-bit sequence number is chosen.

This seems to be false on my platform since only a counter seems to be incremented between two calls to uuid1().

Environment

• Python 3.10.6
• Ubuntu 22.04 LTS 5.15.0-58-generic x86_64

[cfrademan]

I have shared this report to more accurately define what could be the cause.

#118241

[lyc8503]

I can reproduce this behavior on the latest python version(Python 3.13.0a6+ (heads/main:9789440de3, May 2 2024, 23:01:27) [GCC 11.4.0] on linux).

The problem is that the uuid module uses global _last_timestamp, which is a variable that is shared between two processes at fork time. According to the documentation, A safe UUID is one which is generated using synchronization methods that ensure no two processes can obtain the same UUID, so I think this behavior should be a bug in the uuid library implementation.

I'm drafting a PR that fixes this by using the register_at_fork method to clear this global variable at fork time.

[lyc8503]

I debugged the code and found that my analysis above was incorrect, and in fact the return value of safely_generated only comes from uuid_generate_time_safe provided by uuid.h in the C module _uuid. Nevertheless, according to the documentation of UUID_GENERATE(3), we should not get duplicate safe uuid either.

[lyc8503]

I wrote the following code to test the behavior of uuid.h, and it seems that this problem with python comes from upstream use uuid/uuid.h.

#include <uuid/uuid.h>
#include <unistd.h>
#include <stdio.h>

int main()
{
    uuid_t uuid;
    printf("before fork: %d ", uuid_generate_time_safe(uuid));
    for (int i = 0; i < 16; i++)
        printf("%02x", uuid[i]);
    printf("\n");

    int ret = fork();
    printf("after fork: %d %d\n", ret, uuid_generate_time_safe(uuid));
    for (int i = 0; i < 16; i++)
        printf("%02x", uuid[i]);
    printf("\n");

    return 0;
}

edit: I opened an issue to ask in the upstream repo: util-linux/util-linux#3009

[erlend-aasland]

Unable to reproduce on Ubuntu 22.04 using Python 3.10, nor can I reproduce on macOS with Python 3.8 through 3.13.

[lyc8503]

Unable to reproduce on Ubuntu 22.04 using Python 3.10, nor can I reproduce on macOS with Python 3.8 through 3.13.

Based on the discussion in util-linux/util-linux#3009, you may need to enable uuidd to reproduce the problem. I happen to have uuidd enabled in my test environment.

[lyc8503]

This issue has already been resolved in the upstream repository, and theoretically, we just have to wait for the upstream changes to propagate. I'm not sure we need to do more on the python side though?

[erlend-aasland]

Thanks. Sounds like we can close this.