Skip to content
This repository has been archived by the owner on Feb 24, 2020. It is now read-only.

build, enter: Fixes for old centos #1529

Merged
merged 2 commits into from Oct 6, 2015
Merged

build, enter: Fixes for old centos #1529

merged 2 commits into from Oct 6, 2015

Conversation

krnowak
Copy link
Collaborator

@krnowak krnowak commented Oct 2, 2015

This fixes generation of invalid shell script by autotools and the lack of setns function.

Fixes #1443.

@@ -27,6 +27,12 @@
#include <sys/wait.h>
#include <unistd.h>

#ifdef USE_NR_SETNS_MACRO_INSTEAD
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to use

#ifndef setns
#include <linux/unistd.h>
static int setns(int fd, int nstype) {
  return syscall(__NR_setns, fd, nstype);
}
#endif

instead of declaring USE_NR_SETNS_MACRO_INSTEAD in configure.ac.

Then, no need to modify the call sites of setns()

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That won't work - preprocessor does not tell you if the function is defined or not.

What I could do is to use your code, but replace the #ifndef setns with #USE_NR_SETNS_MACRO_INSTEAD. This macro is defined only when we don't have setns function.

@jonboulle
Copy link
Contributor

/cc @jaybuff

@jaybuff
Copy link

jaybuff commented Oct 5, 2015

How about not using setns from glibc at all? It's only used in one place and the "if not defined define it" logic is odd. Let's just have our own setns and use it all the time. It's a one line function.

@krnowak
Copy link
Collaborator Author

krnowak commented Oct 5, 2015

I'm not sure if going for the lowest common denominator is the way to go. I would rather insist on dropping support for too old distros (there is already CentOS 7.0 with glibc 2.17 and autoconf 2.69 released almost half year ago), so I would consider adding a support for CentOS 6.7 a rather exceptional situation.

I just don't see too much sense in making new version of software running on some really old software (5 years since glibc 2.12 or 7 years since autoconf 2.63 were released are a lot of time).

True, your suggestion would make the fix easier/shorter, but I'd prefer to avoid following that way.

@jaybuff
Copy link

jaybuff commented Oct 5, 2015

@krnowak are you suggesting dropping this PR and officially not supporting builds on centos 6.x? IMHO replacing setns(...) with syscall(308, ...) in one place is a small price to pay to support an old, but popular, set of distros.

@jonboulle
Copy link
Contributor

No, we are definitely going to try to support builds on CentOS 6.x

On Mon, Oct 5, 2015 at 2:00 PM, Jay Buffington notifications@github.com
wrote:

@krnowak https://github.com/krnowak are you suggesting dropping this PR
and officially not supporting builds on centos 6.x? IMHO replacing
setns(...) with syscall(308, ...) in one place is a small price to pay to
support an old, but popular, set of distros.


Reply to this email directly or view it on GitHub
#1529 (comment).

@vcaputo
Copy link
Contributor

vcaputo commented Oct 5, 2015

+1 for the simple always use our own setns syscall wrapper approach, no need for the added complexity of detecting the glibc wrapper.

Centos 6.7 has buggy autoconf/m4/whatever - it is getting confused
with empty conditional bodies preceded with m4 comments, which results
in generating shell code with empty conditional bodies, which in turn
is an invalid code.

Just put some colons (which serve as an explicit noop in shell) to be
safe.

Also, lower autoconf required version.
Another fix for CentOS 6.7 - setns function was added to glibc 2.14,
but CentOS has only 2.12.
@krnowak
Copy link
Collaborator Author

krnowak commented Oct 6, 2015

I'm against the said simple solution - I want compatibility stuff to stick out like a sore thumb. I updated the PR, so it does not modify setns call site.

@iaguis
Copy link
Member

iaguis commented Oct 6, 2015

I think the solution implemented now is simple enough.

@krnowak
Copy link
Collaborator Author

krnowak commented Oct 6, 2015

Anyway, rkt builds fine with this PR, but I wasn't able to run any pod: Couldn't mount the host cgroups: error creating host cgroups: mkdir /sys/fs/cgroup: no such file or directory. Some people had the issues like this with docker-in-docker on CentOS 6.7: jpetazzo/dind#17, but I see no solution there.

@iaguis
Copy link
Member

iaguis commented Oct 6, 2015

#1064 (comment)

@jonboulle
Copy link
Contributor

@jaybuff hmm, were you able to successfully run with this?

@jonboulle jonboulle added this to the v0.10.0 milestone Oct 6, 2015
@jaybuff
Copy link

jaybuff commented Oct 6, 2015

I was able to successfully build this (help reports version 0.8.1+gita65939d) and rkt run succeeded for me.

I was under the impression that the Couldn't mount the host cgroups: error creating host cgroups: mkdir /sys/fs/cgroup issue was resolved with commit d858582. I'm confused why @krnowak is seeing that here.

@jonboulle jonboulle modified the milestones: v0.9.0, v0.10.0 Oct 6, 2015
@jonboulle
Copy link
Contributor

OK, I'm going to land this and we can revisit if there are runtime issues.

jonboulle added a commit that referenced this pull request Oct 6, 2015
build, enter: Fixes for old centos
@jonboulle jonboulle merged commit 600457c into rkt:master Oct 6, 2015
@jaybuff
Copy link

jaybuff commented Oct 6, 2015

👍

@krnowak
Copy link
Collaborator Author

krnowak commented Oct 6, 2015

I'm not sure either, why I got the error. Anyway, I tried mounting it manually and got basically the same error. It's probably because the stock kernel in CentOS is quite ancient (2.6.32). On some howtos about running Docker in CentOS 6 there was a hint about using newer kernel (3.10 or something).

@jaybuff
Copy link

jaybuff commented Oct 6, 2015

Oh, yes, I am using a 3.18 kernel with CentOS 6u5, so that would explain it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

rkt should compile on centos 6.x
6 participants