Missing automatic removal of listener unix socket (uds)

[achimnol]

Describe the bug

There seems to be no explicit removal of the listener UNIX socket during Glide runtime drop or language-specific client cleanup (at least Python and NodeJS).

The listener implementation in the Rust core has two places to remove the socket file:

• close_socket() method
• after breaking out the accept() loop due to an syscall error

But there are no other places calling close_socket() method except test codes.

• https://github.com/search?q=repo%3Avalkey-io%2Fvalkey-glide+close_socket&type=code
• https://github.com/search?q=repo%3Avalkey-io%2Fvalkey-glide+std%3A%3Afs%3A%3Aremove_file&type=code

So I wonder if the current implementation relies on automatic cleanup of tmpfs upon reboots or periodic cleanup. If so, this design is prone to potential memory/inode leaks in long-running servers as the socket files are accumulated whenever processes using valkey-glide are created. Relying on it is also prone to unintended removal of socket files.

Expected Behavior

The listener unix socket should be cleaned up when the user process terminates.

Current Behavior

It does not.

Reproduction Steps

Just repeat spwaning Python/NodeJS processes using valkey-glide and check /tmp.

Possible Solution

• Add deliberate, explicit removal of UDS when the user process is terminated. It is required to prevent memory/inode leaks for long-running server instances where processes using valkey-glide are frequently spawned. Otherwise, users need to rely on automatic tmpfs cleanup services.
• If so, we need to fix the following:
  • Make UDS location user-configurable. Currently it's hard-coded as /tmp.
  • Add an warning in the documentation about potential unintended removal of UDS under /tmp for long-running server processes in the presence of automatic tmpfs cleanup services.
  • Periodically refresh mtime of UDS under /tmp, but this would not be a perfect solution depending on tmpfs cleanup configuration.

Additional Information/Context

• Invalid State error + Closed Client #4653: I suspect the unix socket may be unintentionally removed by the tmpfs cleanup service as just opening a single connection for a long time does not update mtime of the socket file.
• CI: Node tests fail on MacOS runners with error "Can't assign requested address (os error 49)" #3064: I suspect there is no explicit unix socket cleanup here.

Client version used

2.0.1

Engine type and version

Redis 6.2

OS

Ubuntu 24.04

Language

Python

Language Version

3.13

Cluster information

No response

Logs

No response

Other information

No response

[asafpamzn]

@achimnol , Thanks a lot for reaching out.
@liorsve can you please see if this is related to #4653 and if your fix is going to solve it as well.

[liorsve]

@asafpamzn My minor fix (merged to main but not released yet) improves the error handling on the python side only after the socket closes, so it doesn't solve the real underlying problem of why it closed in the first place. At least for #4653 which is running on Fargate, from what I can see there is no automatic cleanup by Fargate while a container is running (only when a task is stopped or terminated), but if the application has this cleanup it indeed could be root cause of this.

[asafpamzn]

Thanks @liorsve lets see if we can recreate the issue.
I don't think that it is related to fargate. @achimnol managed to recreate on Ubuntu. @achimnol please let me know if there is specific env that is needed for the recreation.

[avifenesh]

@achimnol Hi, im working on it. Cleaning temp manually is intrusive behaviour for a library.
My direction here currently is to
A. create the file in a process scoped runtime dir - $XDG_RUNTIME_DIR/BaseDirs::runtime_dir and make it configurable with global env parameter.
B. make the close function to clean up their own file, in case there is no other client alive, using ref count.
C. Make Rust drop functionality to explicitly clean the file.
D. For the other issue mentioned - create retry create on another path if cant connect using the same path, and returning disconnection error so user can retry reconnect on this error, if it passed the internal retry without success.
WDYT?
@timos-flwls and to you?

[timos-flwls]

Honestly my experience with sockets and unix is limited. I am not sure how I can help apart from help test any fix.

[avifenesh]

@timos-flwls no need for help :)
Already reproduced and tested the fix; PR already opened. Just notifying you about the progress.

[timos-flwls]

oh great, well its much appreciated!

[jamesx-improving]

actually @avifenesh , since one other user asked GLIDE to be "read only fs compatible", I was experimenting creating "abstract namespace socket" instead of file-based UDS. Maybe we can just move towards this direction, and hit 2 birds with one stone?

[avifenesh]

actually @avifenesh , since one other user asked GLIDE to be "read only fs compatible", I was experimenting creating "abstract namespace socket" instead of file-based UDS. Maybe we can just move towards this direction, and hit 2 birds with one stone?

@jamesx-improving We can elaborate on it more in the next meeting, but I've looked at this direction before.
The issue with abstract ones is security that can be better but needs to be handled completely manually, while UDS comes out of the box with unix security model.
The second, more problematic one is that unnamed are Linux only and not supported on macOS.

[achimnol]

Pinging if there are any progress here!

[achimnol]

@avifenesh @jamesx-improving I'd like to check how things are going here.
Even with abstract namespace sockets, I believe it should be automatically, explicitly cleaned up after use and the core nature of this issue does not go anywhere.

[jamesx-improving]

@avifenesh any chance you could help to take another look at this issue? 🙏