Problems to pass arguments to a JAR in run.yaml

[roberto battistoni]

Dear all,

I have a "run.yaml" to run a JAR file. We need to pass a lot of arguments but something go wrong. This is the snippet of the run.yaml:

 myconfig1:
      main: /Uni.jar
      args:
         - -lsim -nTc 10
         - -sp 50000
         - -kp ./keystore
         - -tf ./config/topology.prop.xml
         - -tIp 127.0.0.1
         - -d 60
         - -td ./traces/
         - -cfg ./config/config.prop.xml

When I run the image the message I got is the following:

"unrecognised option '-nTc'"

It seems to consider only the first argument and not the others.

Any advice?

Regards

R

[Waldek Kozaczuk]

So I have tested it myself and it looks like capstan (or OSv cannot parse properly command line built by capstan) cannot properly handle arguments when passes through YAML args list.

It looks like you are using the "java" runtime that capstan advertises which aims to make it easier to deploy and run Java apps on OSv by automating process of constructing proper java command line and pull extra packages. But apparently it has bugs and in general it comes with another layer of abstraction which sometimes may make it more difficult to troubleshoot the problem.

You can always bypass this layer and use "native" runtime where you have full control of how your OSv command like looks. This is BTW how I use capstan.

Here is how your meta/run.yaml would look like:

runtime: native

config_set:

  myconfig1:

    bootcmd: "/java.so -jar /Uni.jar -lsim -nTc 10 -sp 50000 -kp ./keystore -tf ./config/topology.prop.xml -tIp 127.0.0.1 -d 60 -td ./traces/ -cfg ./config/config.prop.xml"

config_set_default: myconfig1

Also you need to change meta/package.yaml. See this example:

name: java-example

title: Java Example

author: Anonymous

version: "1.0"

require:

#- openjdk8-zulu-full

- openjdk8-zulu-compact3-with-java-beans

- osv.run-java

created: "2018-06-13T18:09:24-04:00"

Please see you can use either full and slimmer version of Open JDK 8 JRE. Also please note extra package which needs to be the last one and you can download it from github https://github.com/cloudius-systems/osv/releases/download/v0.51.0/osv.run-java.mpm/yaml and put it under $HOME/.capstan/packages/. Unfortunately the old Mikelangelo S3 repo has pretty old (2018) artifacts and I am not sure if anybody maintains it. You can always easily create your own S3 OSv packages repo if you want. 

I have tested it with my hello world class and Java app received arguments correctly:

Sv v0.53.0

eth0: 192.168.122.15

java.so: Starting JVM app using: io/osv/nonisolated/RunNonIsolatedJvmApp

java.so: Setting Java system classloader to NonIsolatingOsvSystemClassLoader

Hello from Java on OSv!

Arg: -lsim

Arg: -nTc

Arg: 10

Arg: -sp

Arg: 50000

Arg: -kp

Arg: ./keystore

Arg: -tf

Arg: ./config/topology.prop.xml

Arg: -tIp

Arg: 127.0.0.1

Arg: -d

Arg: 60

Arg: -td

Arg: ./traces/

Arg: -cfg

Arg: ./config/config.prop.xml

I hope this helps,

Waldek

[robertob]

Thank you so much. 

I did all you wrote but I get these lines:

OSv v0.24-472-gf240a59
eth0: 192.168.122.15
/java.so: failed looking up symbol _ZTINSt6thread6_StateE (typeinfo for std::thr


[backtrace]
0x00000000003477cd <elf::object::symbol(unsigned int)+205>
0x0000000000399922 <elf::object::arch_relocate_rela(unsigned int, unsigned int,
0x00000000003446b3 <elf::object::relocate_rela()+147>
0x0000000000346247 <elf::object::relocate()+199>
0x0000000000349cdc <elf::program::load_object(std::string, std::vector<std::str>
0x000000000034a54b <elf::program::get_library(std::string, std::vector<std::strd
0x000000000041ccea <osv::application::application(std::string const&, std::vect>
0x000000000041d515 <osv::application::run(std::string const&, std::vector<std::a
0x000000000041d73b <osv::application::run(std::vector<std::string, std::allocato
0x0000000000213125 <do_main_thread(void*)+1717>
0x000000000044d6a5 <???+4511397>
0x00000000003f5477 <thread_main_c+39>
0x00000000003959a5 <???+3758501>
0x03209500032091ff <???+52466175>
0x00000000003f4b6f <???+4148079>
0xfb89485354415540 <???+1413567808>

I cannot understand why the OSV version is 0.24. I think this is the probem now.

regards

r

[Waldek Kozaczuk]

Try to replace osv-loader.qemu under ~/.capstan with newer version of kernel - https://github.com/cloudius-systems/osv/releases/download/v0.53.0/osv-loader.qemu.

[robertob]

Yes, now it works. 

I read your other messages about how it is frustrating to access the documentation on OSV and I confirm. In general is not easy to understand how to do things and what are the differences with various version of the software.

I thank you for your amazing help

roberto

[robertob]

Now the probem is how to run the Rest server to get the logs inside the image...

All the documentation tell me to include "osv.httpserver-api". I have exposed the port 8000 trough the option "-f" for the capstan run, but the port does not answer.

This is my cmdline to run the image:

" capstan run uni -n "bridge" -f "8000:8000" -e "--ip=eth0,10.0.0.100,255.255.255.0 --defaultgw=10.0.0.1 --nameserver=10.0.0.1 /java.so -jar uni.jar --options ..."

Do I have to start the httpserver in any way?

thanks for the patience

r

[Waldek Kozaczuk]

I have just uploaded newest 0.53.0 packages for API server under https://github.com/cloudius-systems/osv/releases/tag/v0.53.0 (artifacts). Please download and put them under your local .capstan/packages directory.

Then add/replace 'requires' section to include osv.httpserver-html5-gui-and-cli. If you open in a browser you should see the management GUI and changing to /cli should provide you with a terminal (see https://github.com/wkozaczuk/osv-html5-terminal).

BTW I think that forwarding is unnecessary as you use tap device setup which exposes IP of OSv anyway.

[Roberto Battistoni]

I did the include step you suggested but it did not work. 

So I made a test:

capstan run uni -n "nat" -f "8000:8000" -e "/cli/cli.so”

With “nat” configuration I see the REST services from the host (http://localhost:8000/…), but when I switch to “bridge” I don’t see anymore the services.

Other question is: Do I have to activate the httpserver without the cli.so?

Any suggestion?

thanks

roberto

-- 
You received this message because you are subscribed to a topic in the Google Groups "OSv Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osv-dev/72npLe9XERQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to osv-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Waldek Kozaczuk]

On Thursday, March 28, 2019 at 3:16:30 AM UTC-4, robertob wrote:

I did the include step you suggested but it did not work. 

So I made a test:

capstan run uni -n "nat" -f "8000:8000" -e "/cli/cli.so”

I think order matters so this should be:

capstan run -n "nat" -f "8000:8000" -e "/cli/cli.so” uni 

BTW we should make capstan complain about it if I am right.

Also I am confused. It looks like you are trying to run Lua-based true command line app that does NOT require any port. I indicated you could package osv.httpserver-html5-gui-and-cli so you can get HTML5 cli app (html, css, javascript files as opposed to so file which is a different app and not part of osv.httpserver-html5-gui-and-cli) that you can open in a browser - https://github.com/wkozaczuk/osv-html5-terminal

Finally prepend OSv cmdline with '--verbose ' to make OSv show detailed boot message so we can see what exactly does on startup. For example it would should if http server actually started.

To unsubscribe from this group and all its topics, send an email to osv...@googlegroups.com.

[roberto battistoni]

Sorry I didn't be so clear in my explanation.

Running cli.so (with httpserver api) is only a test to understand why are not reachable the REST services. In my case the problem is that with BRIDGE configuration this does not work, instead with NAT it works. 

I need the BRIDGE configuration for my real work but before I must solve this network problem. 

The log following in the case of BRIDGE config:

*******************************************

Booting from Hard Disk...

OSv v0.53.0

2 CPUs detected

Firmware vendor: SeaBIOS

bsd: initializing - done

VFS: mounting ramfs at /

VFS: mounting devfs at /dev

net: initializing - done

vga: Add VGA device instance

eth0: ethernet address: aa:4c:12:77:aa:9c

virtio-blk: Add blk device instances 0 as vblk0, devsize=10737418240

Warning: No hardware source of entropy available to your platform,

        CSPRNG will rely on software source of entropy to provide high-quality randomness.

random: <Software, Yarrow> initialized

VFS: unmounting /dev

VFS: mounting rofs at /rofs

failed to mount /rofs, error = No error information

VFS: mounting zfs at /zfs

zfs: mounting osv/zfs from device /dev/vblk0.1

random: device unblocked.

VFS: mounting devfs at /dev

VFS: mounting procfs at /proc

WARNING: application::prepare_argv(): missing libvdso.so -> may prevent shared libraries specifically Golang ones from functioning

program zpool.so returned 1

BSD shrinker: event handler list found: 0xffffa00000c9c380

        BSD shrinker found: 1

BSD shrinker: unlocked, running

[I/32 dhcp]: Broadcasting DHCPDISCOVER message with xid: [563631264]

[I/32 dhcp]: Waiting for IP...

[I/32 dhcp]: Broadcasting DHCPDISCOVER message with xid: [387072016]

[I/32 dhcp]: Waiting for IP...

[I/211 dhcp]: Received DHCPOFFER message from DHCP server: 192.168.122.1 regarding offerred IP address: 192.168.122.168

[W/211 dhcp]: Got packet with wrong transaction ID (387072016, 563631264)

[I/211 dhcp]: Received DHCPOFFER message from DHCP server: 192.168.122.1 regarding offerred IP address: 192.168.122.168

[I/211 dhcp]: Broadcasting DHCPREQUEST message with xid: [387072016] to SELECT offered IP: 192.168.122.168

[I/211 dhcp]: DHCP received hostname: osv

[I/211 dhcp]: Received DHCPACK message from DHCP server: 192.168.122.1 regarding offerred IP address: 192.168.122.168

[I/211 dhcp]: Server acknowledged IP 192.168.122.168 for interface eth0 with time to lease in seconds: 3600

eth0: 192.168.122.168

[I/211 dhcp]: Configuring eth0: ip 192.168.122.168 subnet mask 255.255.255.0 gateway 192.168.122.1 MTU 1500

[I/211 dhcp]: Set hostname to: osv

Running from /init/30-auto-02: /libhttpserver-api.so &!

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_api.so

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_network.so

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_trace.so

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_os.so

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_env.so

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_fs.so

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_app.so

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_file.so

httpserver: loaded plugin from path: /usr/mgmt/plugins/libhttpserver-api_hardware.so

httpserver: setup redirect: [/] -> [/dashboard/]

httpserver: setup file mapping: [/api-gui] -> [/usr/mgmt/swagger-ui/dist/index.html]

httpserver: setup directory mapping: [/api] -> [/usr/mgmt/api]

httpserver: setup directory mapping: [/dashboard_static] -> [/usr/mgmt/gui/dashboard_static]

could not load libssl.so.1.0.0

httpserver: setup file mapping: [/dashboard] -> [/usr/mgmt/gui/dashboard/index.html]

could not load libcrypto.so.1.0.0

httpserver: setup directory mapping: [/api-gui] -> [/usr/mgmt/swagger-ui/dist]

Rest API server running on port 8000

*******************************************  

thanks

To unsubscribe from this group and all its topics, send an email to osv-dev+u...@googlegroups.com.

[Rick Payne]

On Thu, 2019-03-28 at 14:20 +0100, roberto battistoni wrote:
> [I/211 dhcp]: Received DHCPACK message from DHCP server:
> 192.168.122.1 regarding offerred IP address: 192.168.122.168

This is the typical subnet used by libvirt/qemu, and is typically only
available locally on the machine unless you do something to route
incoming traffic to your machine.

Are you trying to get a 'public' IP addresses? What do you expect to
assign the IP address?

Rick

[roberto battistoni]

Sorry but the DHCP offers the IP both in the NAT and BRIDGE configuration. I think that the "forward" does not work in the bridge configuration. 

For example:

capstan run -n "nat" -f "8000:8000" -e "--verbose /cli/cli.so" uni ==> THIS WORKS and "curl http://localhost:8000/os/version" returns correctly the version "0.53"

capstan run -n "bridge" -f "8000:8000" -e "--verbose /cli/cli.so" uni ==> THIS DOES NOT WORK and "curl http://localhost:8000/os/version" returns "(7) Failed to connect to localhost port 8000: Connection refused"

Any advice?

thanks

[Rick Payne]

On 31 Mar 2019, at 19:56, roberto battistoni <r.batt...@gmail.com> wrote:

Sorry but the DHCP offers the IP both in the NAT and BRIDGE configuration. I think that the "forward" does not work in the bridge configuration. 

Why would it be forwarding in ‘bridge’ mode? I think you’re slightly confused. In bridge mode, you wouldn’t use a port forward as you could talk directly to the device.

Perhaps you can look at how QEMU is actually invoked but the two different options?

For example:

capstan run -n "nat" -f "8000:8000" -e "--verbose /cli/cli.so" uni ==> THIS WORKS and "curl http://localhost:8000/os/version" returns correctly the version "0.53"

I’m not sure what capstan does, but I think for NAT it installs a port forward to the QEMU options. Thus port 8000 on localhost is forwarded to OSv port 8000.

capstan run -n "bridge" -f "8000:8000" -e "--verbose /cli/cli.so" uni ==> THIS DOES NOT WORK and "curl http://localhost:8000/os/version" returns "(7) Failed to connect to localhost port 8000: Connection refused"

I believe in bridge mode it does not - you should be using http://<ip-address-of-OSv>:8000/ (which I think was 192.168.122.168 in your example).

Rick

[roberto battistoni]

Yes, you are right. It was a my mistake.

Thanks a lot

r

[Waldek Kozaczuk]

OSv always prints internal IP but I think it would be nice if scripts/run.py and capstan printed the external ip address (and possibly ports if forwarding) to make it clear to users what is available.