containerd/cgroups/memory.go:179:33: undefined: unix.SYS_EVENTFD2

[ssbarnea]

build fails with undefined symbols on MacOS (HighSierra)

$ make                                                                                                                                                                                                                                                               [12:27:30]
touch .gopathok
go build -i -ldflags '-L/usr/local/opt/zlib/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/nss/lib  -L/usr/local/opt/libarchive/lib -L/usr/local/opt/icu4c/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/sqlite/lib -X github.com/containers/libpod/libpod.gitCommit="23feb0d6f9a6a43e44f959c99100ae24d6c27f6d" -X github.com/containers/libpod/libpod.buildInfo=1542803281' -tags "seccomp btrfs_noversion exclude_graphdriver_btrfs containers_image_ostree_stub   varlink exclude_graphdriver_devicemapper" -o bin/podman github.com/containers/libpod/cmd/podman
# github.com/containers/libpod/vendor/github.com/containerd/cgroups
vendor/github.com/containerd/cgroups/memory.go:179:33: undefined: unix.SYS_EVENTFD2
vendor/github.com/containerd/cgroups/memory.go:179:55: undefined: unix.EFD_CLOEXEC
make: *** [podman] Error 2

[ssbarnea]

This seems to be caused by containerd/cgroups#19 and I am afraid that the reply there worries me.

[mheon]

Cgroups code is not really expected to compile on OS X, so the solution would be to conditional-compile the code using cgroups to not build at all on Mac. There are various other issues with libpod on OS X, the biggest in my mind being the lack of an OCI runtime to start containers (at least, last I looked, no such thing existed). If we don't have something like runc or Kata we won't be able to actually run any containers.

…

On Wed, Nov 21, 2018, 08:04 Sorin Sbarnea ***@***.*** wrote: This seems to be caused by containerd/cgroups#19 <containerd/cgroups#19> and I am afraid that the reply there worries me. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1840 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHYHCASkXwl47bYFGgxaf81ND94BWpiYks5uxU90gaJpZM4YtBHh> .

[ssbarnea]

We need to find a way to address this issue, even if this could mean that podman would delegate commands to a remove host (or vm) that can run. Top priority would be to be able to build containers.

There is a huge number of developers that are using MacOS ar their desktop and for which its (outdated) BSD was more than enough for writing and (unit) testing their code. Docker also worked well on these.

I am less concerned about running as most of the time my DOCKER_HOST variable points to a remote Linux host.

[mheon]

Your best bet if you don't mind if things are running in a VM is probably pypodman connecting over SSH to a Linux VM. I believe someone in our IRC is working on a solution for easily spinning up said VMs, but I'm not sure where he published his code - I'll ask next time I see him online

…

On Thu, Nov 22, 2018, 05:16 Sorin Sbarnea ***@***.*** wrote: We need to find a way to address this issue, even if this could mean that podman would delegate commands to a remove host (or vm) that can run. Top priority would be to be able to build containers. There is a huge number of developers that are using MacOS ar their desktop and for which its (outdated) BSD was more than enough for writing and (unit) testing their code. Docker also worked well on these. I am less concerned about running as most of the time my DOCKER_HOST variable points to a remote Linux host. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1840 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHYHCBIw3WWm-arpqU0E2RPAOVvEaW01ks5uxnmEgaJpZM4YtBHh> .

[rhatdan]

Yes the whole pypodman effort is aimed at allowing the use of podman/docker like commands on a MAC Or Windows box interacting with podman running on a "remote" linux box (Probably a VM). We would love to see this made easy and to work with the CoreOS Team to make it possible.

@dustymabe WDYT?

[mheon]

@ssbarnea You might want to look at https://github.com/boot2podman/boot2podman by @afbjorklund - it might do what you're looking for.

[dustymabe]

cc @praveenkumar

[afbjorklund]

I would like some testers of podman-machine, I made some binaries for Mac and Windows:

https://github.com/boot2podman/machine

Currently it still times out and crashes after "start", but should be OK after the initial chock.

Should work with pypodman and varlink ?

[afbjorklund]

Note that it still defaults to VirtualBox, or possibly my QEMU/KVM driver as an alternative.

But it should be rather doable to "port" the drivers for Mac hyperkit and Win hyper-v...

[ssbarnea]

Thanks for the feedback, I will have a look at that. Still, I cannot refrain from mentioning that somehow I see the "no big fat daemons" statement as confusing for non Linux users. For those users the big-fat-docker-daemon is replaced by a big-fat-virtual-machine.... one that I would also remember to start and stop based on the needs.... looking back I was seeing the docker approach much easier to do, and installable unsing a single line dommand on any platform.

One of the biggest selling points was the "you can build containers on you own machine without having to run docker server".... welll now I need a entire new VM to do the same thing.

On the other hand I do have VIRTHOST defined on my MacOS machine which points to a nearby (linux) virthost. If podman could be smart to know how to use it without extra efforth it could be a solution. The entire idea here is that I am looking for a basic cross platform solution (ignore Windows) for building containers.

So far I don't think a MacOS user can really do "alias docker=podman`.

[mheon]

Hm. If you already have a VM target present and defined, making pypodman use it shouldn't be that difficult. @jwhonce WDYT?

[afbjorklund]

If you run FreeBSD, you have both the linuxulator and jails. I'm not sure Darwin (OS X) has any of that yet ?

If not, you are going to be stuck with virtualization solutions. But it shouldn't be worse than Docker LinuxKit.

[mheon]

I think I heard of an OS X solution, but it was using VM containers (similar to Kata), and I don't believe it was OCI compatible - so we don't know how to talk to it.

[afbjorklund]

Apparently FreeBSD also has both Docker and OCI runc available already. Based on jails, naturally.

Can't see anything available for OS X (?), and Windows just keep talking about Windows containers...

[rhatdan]

I wonder how hard it would be to get podman to run on FreeBSD?

[rhatdan]

@afbjorklund is this as easy to use as boot2docker? How can we get this integrated into pypodman? What is the developer/user experience?
I install pypodman from pypy, now what do I need to do?
Should you podman-machine default to fedora-coreos for its platform?
I would love ot have you and @jwhonce and @dustymabe work on the user experience together.

[rhatdan]

I would love to set up a blueajeans meeting this week or next week to further discuss the user experience here.

[afbjorklund]

@rhatdan : the user experience should be on par (at least when finished...)
My plan was to describe it (user experience) further, we can set up a meeting

As for FreeBSD, I haven't used it years - but it seemed like runc is available ?
Just mentioned it, since it has a native solution and it is related to Mac OS X.

[rhatdan]

We have had one meeting on this, and plan on revisiting this in January.

[baude]

the remote-client for osx is coming along nicely ... i have a PR waiting for merge that will allow for image building from an osx box backended by a linux box running podman.

[ssbarnea]

@baude Now the big question is if we can implement a portable drop-in replacement for docker that would be mostly compatible with docker and run on both linux and macos (as long client is configured to point to a remote host). I will be very happy to test the remoting capability.

I am asking this because at this moment users can easily run docker build|run|ps on any of these platforms so tools using it will just work without modification.

[rhatdan]

@ssbarnea Could you start playing with what we got. @baude has just merged podman build support, although install and running will be a little lacking, we would love to have your feedback.

[rhatdan]

Since we now have a lot of podman-remote built, I am going to close this issue.