Problem
When KVCACHED_IPC_NAME is set explicitly, _obtain_default_ipc_name() still checks whether the shared-memory segment already exists and may append engine/group/pid suffixes.
That makes an explicit IPC name non-deterministic. In multi-process serving, late-importing TP workers are expected to join the same IPC namespace that the first process created. If the explicit name is auto-suffixed after the segment exists, those workers can end up using a different namespace.
Expected behavior
If KVCACHED_IPC_NAME is set, kvcached should treat it as an exact user-provided namespace after sanitization. Auto-uniqueness should only apply to the default generated name path.
Proposed fix
Return the sanitized explicit name directly, and keep the existing uniqueness logic for the implicit/default name path.
Problem
When
KVCACHED_IPC_NAMEis set explicitly,_obtain_default_ipc_name()still checks whether the shared-memory segment already exists and may append engine/group/pid suffixes.That makes an explicit IPC name non-deterministic. In multi-process serving, late-importing TP workers are expected to join the same IPC namespace that the first process created. If the explicit name is auto-suffixed after the segment exists, those workers can end up using a different namespace.
Expected behavior
If
KVCACHED_IPC_NAMEis set, kvcached should treat it as an exact user-provided namespace after sanitization. Auto-uniqueness should only apply to the default generated name path.Proposed fix
Return the sanitized explicit name directly, and keep the existing uniqueness logic for the implicit/default name path.