-
Notifications
You must be signed in to change notification settings - Fork 19
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
tmpcopyup runc-specific extension prevents container from starting up #32
Comments
Thanks for the report. Unfortunately the dump is missing the output for the failing container |
Can you please attach the dump containing the output for container |
Sorry, I had put the output of one container and given you a dump of another (also failing). Let me redo it and redump. Edit: done. new logs uploaded + issue quotes updated as well |
Thanks! I'll take a look at it. |
Thank you. I'm looking forward to your analysis, esp for a workaround as this is blocking my deployments right now. |
Please try the branch https://github.com/Drachenfels-GmbH/crio-lxc/tree/mount-option-filtering NOTE: Since the branch is based on the dev branch you also have to |
@vrubiolo Can you share your kubernetes deployment file ? I want to find out what triggers |
I am actually not using a deployment file per se, just running via Let me know if you want a full dump of the manifest once it is running. |
Yes please! |
Did you try the fixed branch ? |
Not yet, I should be able to do that today. |
Here is the YAML output of |
Thanks. At first sight this doesn't reveal any further information. Btw. updating to the
After that you're done. No need to stop |
From what I had found, it does so when it detects sth like
Great, that would be nice indeed!
Great. I will try this out then. |
Ok, I just tried it and things are definitely better, we don't stumble on the
I am not sure what this means since I had enabled
It looks like another case of a custom option,
Cluster logs: |
Same issue as with |
Please |
It should work now. The mount option set for cgroup2 is |
Thanks for the additional fix, we now get much further, past the mount issue. It still fails however, this time w/ a 255 exit code:
So it looks like the containerized environment was setup and that The LXC source has:
so it might be an LXC issue itself but I am unable to get more information about it. Another possibility is that this is a Is there a way to have output here to know what went wrong? I'd also like to pass additional flags to systemd but I am not sure how to do that in a containerized environment (this is done via the kernel cmdline on a real system IIUC). Logs: 02.11_22.16.05.zip |
environment variables |
Good point, thank you. But then, where does the output goes if there is no console from what I see (I could be wrong)? |
The output from the container init process goes to stdio (stderr, stdout) . The container process inherits stdio from |
That's my issue, there are no logs I can see here ...:
Thanks for the explanation. I don't see anything under
Would you have another suggestion here? |
Pretty please ? 🙏 |
No begging please. ;) https://www.youtube.com/watch?v=-ZRUaDGW7WQ I'll take look at it. |
Good quote, indeed (sorry if I conveyed unintentional context, I just meant to ask, not to be insistent).
Thanks for any pointers you may have, it's the systemd early startup part which I am unfamiliar with. |
Running the container in privileged mode DocumentationI recommend to read both documents here to get better understanding of the security implications:
ExampleI created an c=test-systemd
lxc-create -n $c--template download -- --dist ubuntu --release focal --arch amd64
n=$(buildah from scratch)
p=$(buildah mount $n)
cd $p
rsync -avH /usr/local/var/lib/lxc/$c/rootfs/ .
cd
buildah commit working-container ubuntu-focal:0.1 Now I can run the container in privileged mode using the following manifest: apiVersion: apps/v1
kind: StatefulSet
metadata:
name: systemd-test
spec:
selector:
matchLabels:
app: systemd-test
serviceName: "systemd-test"
replicas: 1
template:
metadata:
labels:
app: systemd-test
spec:
containers:
- name: systemd-test
image: localhost/ubuntu-focal:0.1
imagePullPolicy: Always
command:
- /sbin/init
workingDir: /
env:
# PATH and TERM are set automatically
securityContext:
privileged: true
|
Thank you! 👍 This is what I was missing here (we also run our lxc containers privileged but I had forgotten that because I have all my lxc-XXX commands aliases to prefix them w/ sudo). Great point to also override the image entry point via the manifest, this is much quicker than editing the image configuration itself via Let me try your suggestion and report back ! |
Hi Ruben, I just wanted to chime back to say thanks for the latest manifest and confirm running in privileged mode allowed me to start my existing systemd-based container in Kubernetes. Thank you for the links you pointed at (I had read the systemd container interface when I was debugging my startup issues, a very good read indeed). This is great 🎆, thank you for your excellent work done on this project! My next step will be to stress-test this container, then run Sonobuoy over the sample cluster + expand the cluster capacity to more nodes at the same time I split our current monolith into more containers, now that Kubernetes is up and running. I will also look into picking a distribution for the nodes OS (likely in the Redhat family, as we work w/ those right now). I will let you know how it goes ! |
This is related to #31 |
My systemd-based LXC container fails to start with the following error:
Looking at the LXC config which is generated, I see the following:
It looks like the
tmpcopyup
mount option is a non-OCIrunc
extension and this is what is making the mount fail:If that is true, would there be a workaround? Are you running
systemd
-based containers on your cluster?Here are the logs (this is a shareable testcase, I can provide more if needed, including the rootfs
02.10_22.36.27.zip
Edit: I see
tmpcopyup
is also implemeneted bycrun
The text was updated successfully, but these errors were encountered: