search

nanovms / ops

ops - build and run nanos unikernels
https://ops.city
MIT License
1.27k stars 132 forks source link

Ops "run" with nanos-version "0.1.39" failing. #1321

Closed luigizuccarelli closed 2 years ago

luigizuccarelli commented 2 years ago

OS : fedora35 OPS: 0.1.31 NANOS: 0.1.39

executing the following https client (with certs) for secure connection

ops run client --nanos-version "0.1.39" -c config.json
booting /home/lzuccarelli/.ops/images/client.img ...
en1: assigned 10.0.2.15
ffffc00000cc7f90:   ffffffff800b7f5d    (syscall_context_pause + 000000000000013d/000000000000015c)
ffffc00000cc7fb0:   ffffffff800c4ce1    (syscall_handler + 0000000000000131/00000000000005e1)
assertion sc->start_time != 0 failed at /home/eyberg/go/src/github.com/nanovms/nanos/src/unix/unix_internal.h:905  in syscall_accumulate_stime(); halt

executing the exact same binary with version "0.1.38" works fine

ops run client --nanos-version "0.1.38" -c config.json
booting /home/lzuccarelli/.ops/images/client.img ...
en1: assigned 10.0.2.15
2022/04/18 11:50:38 CAFile: certs/UnikernelCA.crt

Response from server: 
    HTTP status: 200 OK
sanderssj commented 2 years ago

Hi @luigizuccarelli, Please check to see if this problem still occurs on the nightly build. You can do this by running

ops run client -n -c config.json

Also, can you please give us more information about the application and exactly what it is doing? Is it something that we can download and try?

Thanks!

luigizuccarelli commented 2 years ago

@sanderssj - Thanks for the response. I tried running with the -n flag but still got the syscall_accumulate_stime() error.

TBH the client is a simple golang https (net/http) poc that I'm playing with, I have tried with this though, it's a simple echo-service that I use for demos in kuberenetes/openshift. The link is here https://github.com/luigizuccarelli/golang-simple-echoservice

To build the binary, use make build I tried with the following

ops run --nanos-version="0.1.38" build/microservice -e LOG_LEVEL=trace -e NAME=echo-service -e SERVER_PORT=9000 -e VERSION=1.0.0 -p 9000
booting /home/lzuccarelli/.ops/images/microservice.img ...
en1: assigned 10.0.2.15
2022/04/19 07:48:06  [TRACE]  : Input paramaters -> name LOG_LEVEL : required false
2022/04/19 07:48:06  [TRACE]  : Input paramaters -> name NAME : required false
2022/04/19 07:48:06  [TRACE]  : Input paramaters -> name SERVER_PORT : required true
2022/04/19 07:48:06  [TRACE]  : Input paramaters -> name VERSION : required true
en1: assigned FE80::D42C:C9FF:FE51:7A21

this worked. However with "0.1.39" I get this

 ops run --nanos-version="0.1.39" build/microservice -e LOG_LEVEL=trace -e NAME=echo-service -e SERVER_PORT=9000 -e VERSION=1.0.0 -p 9000
booting /home/lzuccarelli/.ops/images/microservice.img ...
en1: assigned 10.0.2.15
ffffc00000d67f90:   ffffffff800b7f5d    (syscall_context_pause + 000000000000013d/000000000000015c)
ffffc00000d67fb0:   ffffffff800c4ce1    (syscall_handler + 0000000000000131/00000000000005e1)
assertion sc->start_time != 0 failed at /home/eyberg/go/src/github.com/nanovms/nanos/src/unix/unix_internal.h:905  in syscall_accumulate_stime(); halt
sanderssj commented 2 years ago

Thanks for the example! I haven't been able to reproduce the problem yet though; nanos version 0.1.39 works fine for me with the program. Please let me know a little more about your platform:

Thank you!

luigizuccarelli commented 2 years ago

@sanderssj - here is the info

Thanks again for looking into this for me

wjhun commented 2 years ago

Hello, @luigizuccarelli. We have isolated an issue when running on glibc-2.34-based systems, as described in nanovms/nanos#1713. I can reproduce the failure with the latest release and, with this fix, am able to start your service. Note that the git hash of the fix commit is used as an argument to --nanos-version below:

$ ops run --nanos-version=81c7170 build/microservice -e LOG_LEVEL=trace -e NAME=echo-service -e SERVER_PORT=9000 -e VERSION=1.0.0 -p 9000
booting /home/wjhun/.ops/images/microservice.img ...
en1: assigned 10.0.2.15
2022/04/19 21:19:19  [TRACE]  : Input paramaters -> name LOG_LEVEL : required false
2022/04/19 21:19:19  [TRACE]  : Input paramaters -> name NAME : required false
2022/04/19 21:19:19  [TRACE]  : Input paramaters -> name SERVER_PORT : required true
2022/04/19 21:19:19  [TRACE]  : Input paramaters -> name VERSION : required true
en1: assigned FE80::4CA4:B7FF:FE5B:CCD

Please let us know if this fix works for you.

Thanks, Will

luigizuccarelli commented 2 years ago

@wjhun - Awesome this works. Thank you all so much for the update. I'll close this issue

luigizuccarelli commented 2 years ago

This is fixed in this PR.