-
Notifications
You must be signed in to change notification settings - Fork 18.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gcplogs: forcibly set HOME on static UNIX binary #29478
Conversation
windowsRS1 failing because
I'll fix later |
Is this something to integrate into https://github.com/docker/docker/blob/master/pkg/homedir/homedir.go, or better kept separate? |
@thaJeztah Existing
The function I'll add to
|
// However, in static binary, os/user.Current() leads to segfault due to a glibc issue that won't be fixed | ||
// in a short term. (golang/go#13470, https://sourceware.org/bugzilla/show_bug.cgi?id=19341) | ||
// So we forcibly set HOME so as to avoid call to os/user/Current() | ||
if dockerversion.IAmStatic == "true" && runtime.GOOS != "windows" && os.Getenv("HOME") == "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only really needs to be runtime.GOOS == "linux"
as it is a glibc bug...
// LookupCurrentHome returns the home directory for the current user. | ||
// The current implementation for UNIX does not call os/user.Current(), because a call to os/user.Current() | ||
// in a static binary leads to segfault due to a glibc issue that won't be fixed in a short term. | ||
// (#29344, golang/go#13470, https://sourceware.org/bugzilla/show_bug.cgi?id=19341) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do not need this comment on Windows
Windows CI out of disk space. |
@AkihiroSuda ok windows running again but the test failure is real:
|
b9f3656
to
30c71d4
Compare
30c71d4
to
2bf2779
Compare
@thaJeztah @justincormack |
// system, because a call to os/user.Current() in a static binary leads to | ||
// segfault due to a glibc issue that won't be fixed in a short term. | ||
// (#29344, golang/go#13470, https://sourceware.org/bugzilla/show_bug.cgi?id=19341) | ||
func GetStatic() (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering; should we have a dummy GetStatic()
in non-linux files? What's the general approach in this situation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the issue is specific to glibc's TLS handling, I think we do not need dummies for non-linux files, but I can add them if needed.
(I'm not sure this is an issue for non-Linux glibc-based systems. e.g. Debian GNU/kFreeBSD(?) 😅 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was more that GetStatic()
is an exported function, so I was wondering if it's common practice to have an exported function only available on some platforms/architectures.
Change itself looks good to me
Needs a rebase. |
It needs the first two commits removing as #29475 is merged |
Fix moby#29344 If HOME is not set, the gcplogs logging driver will call os/user.Current() via oauth2/google. However, in static binary, os/user.Current() leads to segfault due to a glibc issue that won't be fixed in a short term. (golang/go#13470, https://sourceware.org/bugzilla/show_bug.cgi?id=19341) So we forcibly set HOME so as to avoid call to os/user/Current(). Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
2bf2779
to
b86e3be
Compare
@thaJeztah @cpuguy83 @justincormack Rebased and added dummy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
At this point, the bug doesn't seem to exist anymore. What are the plans to back out this code? |
How was this fixed? |
Impossible to tell. I guess not, as I was able to reproduce. Why do we continue to use broken glibc? What a constant piece of junk... |
This commit also eliminates call for `os/user.Current()`, which segfaults when glibc is statically linkedin. (moby/moby#29478) Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
- What I did
Fix #29344
The PR consists of 3 commits, but the first and the second one are dupe of #29475 for vendoring golang/oauth2@96382aa .Please review the latest commit in this PR. (I will rebase this PR when #29475 is merged)
EDIT: rebased
- How I did it
If
HOME
is not set, the gcplogs logging driver will callos/user.Current()
viaoauth2/google
.However, in static binary,
os/user.Current()
leads to segfault due to a glibc issue that won't be fixedin a short term. (golang/go#13470, https://sourceware.org/bugzilla/show_bug.cgi?id=19341)
So this PR forcibly sets
HOME
so as to avoid call toos/user/Current()
.- How to verify it
make binary
)HOME
(typically, just starting the daemon via systemd is enough)level=warning msg="gcplogs requires HOME to be set for static daemon binary. Forcibly setting HOME to /root."
docker run --rm --log-driver=gcplogs busybox echo hello
many times and make sure all of them succeeds without SEGV- Description for the changelog
gcplogs: forcibly set HOME on static UNIX binary
- A picture of a cute animal (not mandatory but encouraged)