Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Fix Version/s: CU-2.6.32-042stab111.X, OpenVZ-legacy
-
Component/s: Containers::Kernel
-
Security Level: Public
-
Environment:Operating System: All
Platform: All
-
External issue URL:
-
External issue ID:3280
Description
I opened this bug upstream (https://github.com/systemd/systemd/issues/421), but poettering said it's not a systemd bug and to open this bug here.
<<
Sounds like a kernel/OpenVZ bug to me.
The first name_to_handle_at() call is invoked with an fd of the root directory for the path "sys". The second name_to_handle_at() call is invoked on the same fd, but for the path "" and the AT_EMPTY_FLAG flag is set.
According to the man page ENOENT means: "pathname is an empty string, but AT_EMPTY_PATH was not specified in flags." Which doesn't apply here, because we do set AT_EMPTY_FLAG.
This works fine on other container managers (such as nspawn). I presume OpenVZ still needs some special kernel patches, no? Somehow they appear to break name_to_handle_at(). Please report this issue to OpenVZ hence.
I don't think there's anything to fix in systemd here. Closing hence.
>>
<<
Sounds like a kernel/OpenVZ bug to me.
The first name_to_handle_at() call is invoked with an fd of the root directory for the path "sys". The second name_to_handle_at() call is invoked on the same fd, but for the path "" and the AT_EMPTY_FLAG flag is set.
According to the man page ENOENT means: "pathname is an empty string, but AT_EMPTY_PATH was not specified in flags." Which doesn't apply here, because we do set AT_EMPTY_FLAG.
This works fine on other container managers (such as nspawn). I presume OpenVZ still needs some special kernel patches, no? Somehow they appear to break name_to_handle_at(). Please report this issue to OpenVZ hence.
I don't think there's anything to fix in systemd here. Closing hence.
>>
