urandom #2714

New issue

Closed

opened 2026-03-04 02:06:56 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 02:06:56 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/s3fs-fuse/s3fs-fuse/pull/2690
Author: @ggtakec
Created: 6/23/2025
Status: ❌ Closed

Base: master ← Head: fix/urandom

📝 Commits (1)

93c6408 Create random string with date without /dev/urandom

📊 Changes

2 files changed (+10 additions, -10 deletions)

View changed files

📝 test/integration-test-main.sh (+2 -2)
📝 test/test-utils.sh (+8 -8)

📄 Description

Relevant Issue (if applicable)

#2687

Details

In the function for adding suffixes to test file names, I changed it so that it does not use /dev/urandom, but uses a random string using seconds and microseconds from the date command.

Why was this necessary?

I did not understand the root cause of this.
However, it seems that the phenomenon is related to /dev/urandom used in the make_random_string test utility function for MacOS.

In order to proceed with the problem phenomenon #2687, I was investigating the test results of test_update_metadata_external_small(large)_object.
And I found an abnormal slowdown in processing speed that sometimes occurred on MacOS.
This was caused by processing being blocked in the following part.

TEST_FILE_EXT=$(make_random_string)

I tried many things such as changing the way the make_random_string function is called, but as long as /dev/urandom is used, this problem continues to occur.
In particular, when running Github Actions (CI) with dbglevel=dbg, the blocking is noticeable.
The block mentioned here means that the s3fs-fuse test script is blocked from running.

While this is blocked, s3fs-fuse periodically references the / and /test-XXXX directories.
(For example, s3fs_getattrs called by macos-fuse-t.)

About the solution

The fundamental solution to this problem is still unknown.
This is a very strange and difficult problem to understand.
But we need to avoid blocking work that was not essential to our tests, so I change it to not access /dev/urandom as a simple solution.

If possible, it would be a good idea to try only the above test cases at dbg level on MacOS.
I would also like some advice on this matter.

Note

This problem is blocking #2687.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/s3fs-fuse/s3fs-fuse/pull/2690 **Author:** [@ggtakec](https://github.com/ggtakec) **Created:** 6/23/2025 **Status:** ❌ Closed **Base:** `master` ← **Head:** `fix/urandom` --- ### 📝 Commits (1) - [`93c6408`](https://github.com/s3fs-fuse/s3fs-fuse/commit/93c64086aae27c67aff9571240fba58090cbeb06) Create random string with date without /dev/urandom ### 📊 Changes **2 files changed** (+10 additions, -10 deletions) <details> <summary>View changed files</summary> 📝 `test/integration-test-main.sh` (+2 -2) 📝 `test/test-utils.sh` (+8 -8) </details> ### 📄 Description ### Relevant Issue (if applicable) #2687 ### Details In the function for adding suffixes to test file names, I changed it so that it does not use `/dev/urandom`, but uses a random string using seconds and microseconds from the `date` command. #### Why was this necessary? I did not understand the root cause of this. However, it seems that the phenomenon is related to `/dev/urandom` used in the `make_random_string` test utility function for MacOS. In order to proceed with the problem phenomenon #2687, I was investigating the test results of `test_update_metadata_external_small(large)_object`. And I found an abnormal slowdown in processing speed that sometimes occurred on MacOS. This was caused by processing being blocked in the following part. ``` TEST_FILE_EXT=$(make_random_string) ``` I tried many things such as changing the way the `make_random_string` function is called, but as long as `/dev/urandom` is used, this problem continues to occur. In particular, when running Github Actions (CI) with `dbglevel=dbg`, the blocking is noticeable. _The block mentioned here means that the s3fs-fuse test script is blocked from running._ While this is blocked, s3fs-fuse periodically references the `/` and `/test-XXXX` directories. _(For example, `s3fs_getattrs` called by `macos-fuse-t`.)_ #### About the solution The fundamental solution to this problem is still unknown. This is a very strange and difficult problem to understand. But we need to avoid blocking work that was not essential to our tests, so I change it to not access `/dev/urandom` as a simple solution. If possible, it would be a good idea to try only the above test cases at dbg level on MacOS. I would also like some advice on this matter. ##### Note This problem is blocking #2687. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>