User running podman segfaults #1189
Comments
|
@giuseppe PTAL |
|
@afbjorklund is the podman distributed by Fedora? I cannot reproduce with the last version available there. Could you try https://koji.fedoraproject.org/koji/buildinfo?buildID=1131468 ? |
|
Nope, I built it from source (using deploy/iso/minikube-iso/package/podman/podman.mk Had to do some vendor hack for "varlink" - whatever that is... Seems like it wasn't getting installed with the |
|
@giuseppe : maybe it requires that But maybe not for the "version" command, if that happens to be the case... |
|
Yes, that seems to have been it: Same as documented in #1185 |
|
@afbjorklund re: varlink - If you don't want if in your build, edit the Makefile and remove |
|
@mheon : I have no idea, I was just updating podman (trying to get away from kpod eventually) Happy to build with the varlink feature, as long as it works... Maybe I could |
|
@afbjorklund There's a dependency package ( |
|
@afbjorklund it is required for rootless containers, but if it is not present it should definitely not crash. I've just built the same version you are using but still it works here, I just get the error message and podman exits. On what system are you trying to run it? I've tried to use it only on Fedora and Ubuntu |
|
Users seem to be happy about hi-jacking the old docker daemon (of minikube), not sure if that should be allowed to continue or if they should use their own container infrastructure instead of the (mini) cloud's ? https://kubernetes.io/docs/setup/minikube/#reusing-the-docker-daemon Currently I'm just ssh'ing into the machine, happy that it can show the images now (cache got turned off...) even if seems like listing containers (i.e. ps) got broken out-of-the-box again. Probably just a socket move. Hacking on: kubernetes/minikube#2757 (running Kubernetes with CRI-O) |
|
@giuseppe : it is running the "minikube.iso", which is a buildroot 2018.05 environment |
|
I'm still not able to reproduce the segfault when the /etc/subuid file is missing. What changes have you done to varlink? If you have the binary you have built somewhere, that could help as well. |
|
@giuseppe : I used the vendored version of varlink, to avoid the out-of-the-box build error when just running "make install.tools podman" that the buildroot make naively tried to do. Did not modify anything. Will see if I can upload the minikube.iso and the podman binary somewhere for easier access... There was a stacktrace as well, after the error printout. But I'm not sure if this segfault is "important" or not ? |
|
Here is the ISO: https://github.com/afbjorklund/minikube/releases/download/15e56aa/minikube.iso As requested, direct link to the binary itself: podman Example output _ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
|
|
Using a previous version works fine. So it's probably something with "varlink" ? ^ The git commit above refers to buildroot, not to libpod (which is from tarball) |
|
Call stack looks like the rootless code, and not Varlink. Something seems
to be going wrong in the CGo code in pkg/rootless.
…On Thu, Aug 2, 2018, 08:09 Anders Björklund ***@***.***> wrote:
Using a previous version works fine. So it's probably something with
"varlink" ?
$ podman version
Version: 0.4.1
Go Version: go1.10.2
Git Commit: "f3d114a1effd8a6ef773bee14fe49ea6d8d7c350"
Built: Thu Aug 2 11:58:17 2018
OS/Arch: linux/amd64
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1189 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHYHCFBvqye_EeLxdVzTwcRYwIMBX8WHks5uMuwDgaJpZM4VmtF4>
.
|
|
I am still not able to reproduce locally but inspecting the code and your call stack, I think the error can be fixed by: #1201. Could you please verify if it solves the problem for you? |
|
Didn't seem to help, unfortunately. Think I need to read up on my CGo :-) runtime.cgocall(0xf618e0, 0xc42027d470, 0x4971f1) /home/anders/KUBE/minikube/out/buildroot/output/host/lib/go/src/runtime/cgocall.go:128 +0x64 fp=0xc42027d430 sp=0xc42027d3f8 pc=0x4090c4 github.com/projectatomic/libpod/pkg/rootless._Cfunc_reexec_in_user_namespace(0xc400000005, 0x0) _cgo_gotypes.go:43 +0x4d fp=0xc42027d470 sp=0xc42027d430 pc=0xd36d5d github.com/projectatomic/libpod/pkg/rootless.BecomeRootInUserNS(0x101c300, 0x0, 0x0, 0x0) /home/anders/KUBE/minikube/out/buildroot/output/build/podman-v0.7.4/_output/src/github.com/projectatomic/libpod/pkg/rootless/rootless_linux.go:92 +0x1ff fp=0xc42027d680 sp=0xc42027d470 pc=0xd375bf main.main() /home/anders/KUBE/minikube/out/buildroot/output/build/podman-v0.7.4/_output/src/github.com/projectatomic/libpod/cmd/podman/main.go:32 +0x71 fp=0xc42027df88 sp=0xc42027d680 pc=0xf33e51 |
|
No luck with gdb, so added some oldschool printf debugging instead... It seems like when the program crashes, that argc is 0 (cmdline gone?) So that termination code needs to check for that possibility too... argv = malloc (sizeof (char *) * (argc + 1));
if (argv == NULL)
return NULL;
argc = 0;
argv[argc++] = buffer;
for (i = 0; i < used - 1; i++)
if (buffer[i] == '\0')
argv[argc++] = buffer + i + 1;
argv[argc] = NULL; |
|
Like so: 054d9bc |
|
Thanks, with those additions the segfault doesn't happen anymore. $ podman version
ERRO[0000] open /etc/subuid: no such file or directory
$ sudo podman version
Version: 0.7.4
Go Version: go1.10.2
OS/Arch: linux/amd64 |
it's worked for me, thanks. |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
Description
Running podman as user causes crashes.
Steps to reproduce the issue:
podman versionDescribe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version:Output of
podman info:Additional environment details (AWS, VirtualBox, physical, etc.):
VirtualBox
The text was updated successfully, but these errors were encountered: