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

rkt: initial run working #1

Closed
3 tasks
philips opened this issue Nov 12, 2014 · 8 comments
Closed
3 tasks

rkt: initial run working #1

philips opened this issue Nov 12, 2014 · 8 comments
Milestone

Comments

@philips
Copy link
Contributor

philips commented Nov 12, 2014

Take an already mounted and setup stage1 and stage2 filesystem and run it. The basic steps involve:

  • Generating unit files from the container manifest
  • Placing unit files into the stage1 filesystem
  • Exec'ing systemd nspawn

This should all work as a service file and be cleaned up.

@philips philips added the core label Nov 12, 2014
@philips philips added this to the MVP milestone Nov 12, 2014
@philips
Copy link
Contributor Author

philips commented Nov 26, 2014

w00t, this is done.

@philips philips closed this as completed Nov 26, 2014
philips added a commit that referenced this issue Dec 1, 2014
fix(CONTRIBUTING.md): Fix title case
@thebyrd
Copy link

thebyrd commented Dec 1, 2014

@philips I ran into

david@ubuntu:~/rocket-v0.1.0$ sudo ./rkt run sha256-701c24b2d275f0e291b807a464ae2390bcd8d7c5b4f2d7e47e6fd917cd5e5588
stage1/usr/bin/systemd-nspawn: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory

Here's some system info:

david@ubuntu:~/rocket-v0.1.0$ uname -a
Linux ubuntu 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
david@ubuntu:~/rocket-v0.1.0$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:    14.04
Codename:   trusty

@thebyrd
Copy link

thebyrd commented Dec 1, 2014

ah, Ubuntu 14.04 doesn't come with systemd... nvm

@jonboulle
Copy link
Contributor

@thebyrd We are actively working on this - see #69

@thebyrd
Copy link

thebyrd commented Dec 1, 2014

perfect. thanks!

@philips
Copy link
Contributor Author

philips commented Dec 1, 2014

@thebyrd Just install libseccomp as a workaround until we get the static or chrooted nspawn working. I tested it on ubuntu and it works fine after that.

@philips
Copy link
Contributor Author

philips commented Dec 1, 2014

@thebyrd To be very specific simply: sudo apt-get install libseccomp2

@thebyrd
Copy link

thebyrd commented Dec 1, 2014

Thx

alban added a commit to alban/rkt that referenced this issue May 21, 2015
Move the pid logic back to stage1/rootfs/enter/enter.c (revert part of
rkt#826), so the pid logic is an implementation detail of stage1,
as it does not appear in Documentation/devel/stage1-implementors-guide.md

See rkt#910 and rkt#826

Tests: there are no functional tests to check that the race in rkt#826 is
correctly fixed. However, I tested manually in the following way:

 * Test rkt#1:
     1. Start a pod:
        sudo bin/rkt  --debug --insecure-skip-verify run --interactive docker://busybox
     2. Pretend that rkt is slow and the ppid file is not yet written:
        cd /var/lib/rkt/pods/run/$uuid && mv ppid ppid-disabled
     3. Enter the pod:
        sudo bin/rkt enter abbc9f3d /bin/sh
     4. Notice that the enter command is waiting (without taking much cpu)
     5. Pretend that rkt finished its job:
        cd /var/lib/rkt/pods/run/$uuid && mv ppid-disabled ppid
     6. Notice that the enter command succeeds

 * Test rkt#2:
     1. Repeat steps 1-4 from test rkt#1
     2. Stop the pod: ^]^]^]
     3. Notice that the enter command stops too

 * Test rkt#3:
     1. patch stage1/init/init.go:
        +       ioutil.WriteFile("/tmp/rkt-waiting", []byte(""), 0644)
        +       for {
        +               if _, err := os.Stat("/tmp/rkt-waiting"); os.IsNotExist(err) {
        +                       break
        +               }
        +               time.Sleep(100 * time.Millisecond)
        +       }
     2. Start a pod
     3. Enter the pod
     4. Notice that the enter command is waiting (without taking much cpu)
     5. Let nspawn start:
        rm /tmp/rkt-waiting
     6. Notice that the enter command succeeds
alban added a commit to alban/rkt that referenced this issue May 21, 2015
Move the pid logic back to stage1/rootfs/enter/enter.c (revert part of
rkt#826), so the pid logic is an implementation detail of stage1,
as it does not appear in Documentation/devel/stage1-implementors-guide.md
Some stage1 might not have pid: stage1 based on virtual machines.

See rkt#910 and rkt#826

Tests: there are no functional tests to check that the race in rkt#826 is
correctly fixed. However, I tested manually in the following way:

 * Test rkt#1:
     1. Start a pod:
        sudo bin/rkt  --debug --insecure-skip-verify run --interactive docker://busybox
     2. Pretend that rkt is slow and the ppid file is not yet written:
        cd /var/lib/rkt/pods/run/$uuid && mv ppid ppid-disabled
     3. Enter the pod:
        sudo bin/rkt enter abbc9f3d /bin/sh
     4. Notice that the enter command is waiting (without taking much cpu)
     5. Pretend that rkt finished its job:
        cd /var/lib/rkt/pods/run/$uuid && mv ppid-disabled ppid
     6. Notice that the enter command succeeds

 * Test rkt#2:
     1. Repeat steps 1-4 from test rkt#1
     2. Stop the pod: ^]^]^]
     3. Notice that the enter command stops too
        FIXME: does not work yet

 * Test rkt#3:
     1. patch stage1/init/init.go:
        +       ioutil.WriteFile("/tmp/rkt-waiting", []byte(""), 0644)
        +       for {
        +               if _, err := os.Stat("/tmp/rkt-waiting"); os.IsNotExist(err) {
        +                       break
        +               }
        +               time.Sleep(100 * time.Millisecond)
        +       }
     2. Start a pod
     3. Enter the pod
     4. Notice that the enter command is waiting (without taking much cpu)
     5. Let nspawn start:
        rm /tmp/rkt-waiting
     6. Notice that the enter command succeeds
alban referenced this issue in endocode/rkt May 21, 2015
Move the pid logic back to stage1/rootfs/enter/enter.c (revert part of
rkt#826), so the pid logic is an implementation detail of stage1,
as it does not appear in Documentation/devel/stage1-implementors-guide.md
Some stage1 might not have pid: stage1 based on virtual machines.

See rkt#910 and rkt#826.

Tests: there are no functional tests to check that the race in rkt#826 is
correctly fixed. However, I tested manually in the following way:

 * Test #1:
     1. Start a pod:
        sudo bin/rkt  --debug --insecure-skip-verify run --interactive docker://busybox
     2. Pretend that rkt is slow and the ppid file is not yet written:
        cd /var/lib/rkt/pods/run/$uuid && mv ppid ppid-disabled
     3. Enter the pod:
        sudo bin/rkt enter abbc9f3d /bin/sh
     4. Notice that the enter command is waiting (without taking much cpu)
     5. Pretend that rkt finished its job:
        cd /var/lib/rkt/pods/run/$uuid && mv ppid-disabled ppid
     6. Notice that the enter command succeeds

 * Test rkt#2:
     1. Repeat steps 1-4 from test #1
     2. Stop the pod: ^]^]^]
     3. Notice that the enter command stops too
        FIXME: does not work yet

 * Test rkt#3:
     1. patch stage1/init/init.go:
        +       ioutil.WriteFile("/tmp/rkt-waiting", []byte(""), 0644)
        +       for {
        +               if _, err := os.Stat("/tmp/rkt-waiting"); os.IsNotExist(err) {
        +                       break
        +               }
        +               time.Sleep(100 * time.Millisecond)
        +       }
     2. Start a pod
     3. Enter the pod
     4. Notice that the enter command is waiting (without taking much cpu)
     5. Let nspawn start:
        rm /tmp/rkt-waiting
     6. Notice that the enter command succeeds
alban referenced this issue in endocode/rkt May 29, 2015
Move the pid logic back to stage1/rootfs/enter/enter.c (revert part of
rkt#826), so the pid logic is an implementation detail of stage1,
as it does not appear in Documentation/devel/stage1-implementors-guide.md
Some stage1 might not have pid: stage1 based on virtual machines.

See rkt#910 and rkt#826.

Tests: there are no functional tests to check that the race in rkt#826 is
correctly fixed. However, I tested manually in the following way:

 * Test #1:
     1. Start a pod:
        sudo bin/rkt  --debug --insecure-skip-verify run --interactive docker://busybox
     2. Pretend that rkt is slow and the ppid file is not yet written:
        cd /var/lib/rkt/pods/run/$uuid && mv ppid ppid-disabled
     3. Enter the pod:
        sudo bin/rkt enter abbc9f3d /bin/sh
     4. Notice that the enter command is waiting (without taking much cpu)
     5. Pretend that rkt finished its job:
        cd /var/lib/rkt/pods/run/$uuid && mv ppid-disabled ppid
     6. Notice that the enter command succeeds

 * Test rkt#2:
     1. Repeat steps 1-4 from test #1
     2. Stop the pod: ^]^]^]
     3. Notice that the enter command stops too
        FIXME: does not work yet

 * Test rkt#3:
     1. patch stage1/init/init.go:
        +       ioutil.WriteFile("/tmp/rkt-waiting", []byte(""), 0644)
        +       for {
        +               if _, err := os.Stat("/tmp/rkt-waiting"); os.IsNotExist(err) {
        +                       break
        +               }
        +               time.Sleep(100 * time.Millisecond)
        +       }
     2. Start a pod
     3. Enter the pod
     4. Notice that the enter command is waiting (without taking much cpu)
     5. Let nspawn start:
        rm /tmp/rkt-waiting
     6. Notice that the enter command succeeds
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants