I have some trouble with the DaemonService using the new ursim (either 18.104.22.168563 or 22.214.171.124512) in Ubuntu 16.04.
I have installed both the simulators as I have always done: same base path, same user permissions, same runit services, same… everything I believe.
Anyway, my URCaps and also the mydaemonswing example do not work: the daemon initialization always fails with
And if I test the runit service through
sudo sv check runsvdir-ursim-126.96.36.199563 it returns as expected:
ok: run: runsvdir-ursim-188.8.131.52563: (pid 15896) 6364s.
I’ve also tried to change the user or group in the
run file of the service, but with no luck.
The only way to enable the daemon service is to start ursim through
sudo ./start-ursim.sh, but it then complains with other missing folders or settings which it is probably been searching in the root directory instead of the user home.
All these problems won’t happen with previous releases of the simulators.
Do I forgot something this time?
Did you find the reason? Does it now show up on
Unfortunately not yet.
~$ ps aux | grep runsv root 1213 0.0 0.0 4392 1196 ? Ss lug05 0:00 runsvdir -P /etc/service log: root 1219 0.0 0.0 4240 648 ? Ss lug05 0:00 runsv runsvdir-ursim-3.4.0-39 root 1217 0.0 0.0 4240 660 ? Ss lug05 0:00 runsv runsvdir-ursim-3.4.2-65 root 1220 0.0 0.0 4240 628 ? Ss lug05 0:00 runsv runsvdir-ursim-184.108.40.20684 root 1218 0.0 0.0 4240 644 ? Ss lug05 0:00 runsv runsvdir-ursim-220.127.116.1161 root 1227 0.0 0.0 4240 652 ? Ss lug05 0:00 runsv runsvdir-ursim-18.104.22.16878 root 1225 0.0 0.0 4240 696 ? Ss lug05 0:00 runsv runsvdir-ursim-22.214.171.12425 root 1226 0.0 0.0 4240 648 ? Ss lug05 0:00 runsv runsvdir-ursim-126.96.36.199512 root 1223 0.0 0.0 4240 648 ? Ss lug05 0:00 runsv runsvdir-ursim-188.8.131.52563 alextoi+ 1230 0.0 0.0 4392 1136 ? S lug05 0:00 runsvdir /opt/universal-robots/ursim-3.4.0-39/service alextoi+ 1236 0.0 0.0 4392 1124 ? S lug05 0:00 runsvdir /opt/universal-robots/ursim-3.4.2-65/service alextoi+ 1233 0.0 0.0 4392 1124 ? S lug05 0:00 runsvdir /opt/universal-robots/ursim-184.108.40.20684/service alextoi+ 1228 0.0 0.0 4392 1112 ? S lug05 0:00 runsvdir /opt/universal-robots/ursim-220.127.116.1161/service alextoi+ 1238 0.0 0.0 4392 1156 ? S lug05 0:00 runsvdir /opt/universal-robots/ursim-18.104.22.16878/service alextoi+ 1232 0.0 0.0 4392 1200 ? S lug05 0:00 runsvdir /opt/universal-robots/ursim-22.214.171.12425/service alextoi+ 1235 0.0 0.0 4392 1196 ? S lug05 0:00 runsvdir /opt/universal-robots/ursim-126.96.36.199512/service alextoi+ 1234 0.0 0.0 4392 1116 ? S lug05 0:00 runsvdir /opt/universal-robots/ursim-188.8.131.52563/service
I am not sure how your setup works, but you will not see the daemon process, if you
grep runsv. Try to search for it without
grep or look for the name of your daemon executable specifically.
This is the line with the process in the output of
Here it is how it looks in
The fact is that I know I do not see the bundle daemon with either 184.108.40.206563 or 220.127.116.11512 simulators, but the question is why?
Indeed, I do see the daemon process running with all the other releases.
How about you modify
start-ursim.sh and put
echo $URSIM_ROOT to see the paths. I can only get my daemon running when I start Polyscope with sudo, but paths are identical.
The path is right, but you got the point: there is an error at the very beginning of the initialization of the simulator.
/opt/universal-robots/ursim-18.104.22.168563/GUI /opt/universal-robots/ursim-22.214.171.124563 /opt/universal-robots/ursim-126.96.36.199563 ERROR: Error reloading cached bundle, removing it: ./felix-cache/bundle112 (java.io.FileNotFoundException: ./felix-cache/bundle112/bundle.location (No such file or directory)) java.io.FileNotFoundException: ./felix-cache/bundle112/bundle.location (No such file or directory) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at org.apache.felix.framework.util.SecureAction.getFileInputStream(SecureAction.java:453) at org.apache.felix.framework.cache.BundleArchive.readLocation(BundleArchive.java:1107) at org.apache.felix.framework.cache.BundleArchive.readBundleInfo(BundleArchive.java:973) at org.apache.felix.framework.cache.BundleArchive.<init>(BundleArchive.java:182) at org.apache.felix.framework.cache.BundleCache.getArchives(BundleCache.java:247) at org.apache.felix.framework.Felix.init(Felix.java:754) at org.apache.felix.framework.Felix.init(Felix.java:624) at org.apache.felix.main.Main.main(Main.java:289) Installing bundle: bundle/jsoup-1.7.3.jar ...
Same problem with
ursim-188.8.131.52595, but not felix errors this time.
I’ll try it on another machine when possible because it is really strange.
I may have found something interesting.
ursim-184.108.40.206512 there is a mistake in the creation of the service bundle links when starting the simulator.
In previous versions, it creates in its
service subdirectory the link to the loaded bundles. However I have found this
service directory in my home, and maybe it is not the right place where it searches for them.
Proper setup when the simulator is started:
Current setup when the
ursim-220.127.116.11512 is started:
<whatever>/ursim-3.5.x/service/ (empty) ~/firstname.lastname@example.org... ~/service/bundle@com...
@jbm can this be addressed as a bug, or it is something related to my specific linux configuration?
I have the same issue.
Did you, or somebody else found the solution?
Currently as I don’t want to start the simulator as root, I start the daemon manually in one Terminal and then runs the simulator.
I also seem to be experiencing this same issue. I just created a fork of my source code from <= PolyScope 3.5.x to > 3.6.x and the first issue that I’m hitting is that my daemon is in a FAILED state. It seems like a similar issue to what is being seen here. It is a simple xmlrpc server (taken from the UR sample code and modified to it my needs).
When I start the daemon up via terminal it runs just fine and I can use it with the simulator but that is not going to work as a long-term solution. Just a workaround until I can figure it out.
I have found the exact same thing in the standard Ubuntu based Starter package… we’ll look into it and come back with a fix as soon as possible.
Seems not fixed in either
Has there been any progress repairing this functionality? The XMLRPC daemon is a critical part of our URCap.
Honestly, this is just a bit annoying while developing on the simulator.
It works fine on real robot.
It’s still being worked on. You can still get it running if you start ursim as root right?
The new URCaps Starter Package for SDK 1.4.4 resolved this issue.
You can find the latest starter package here: Download Center
If running in your own Linux OS, this issue may be caused by
Consider following these steps to resolve the issue.
The issue is not directly related to PolyScope, but rather the configuration of the Linux machine.
When looking at the above linked steps, particularly the hostname and installation of runit will have an impact.
Furthermore, it is not recommended, to start URSim as root, as this will cause PolyScope to have other issues.
IMHO forcing the users to change their hostname to
ursim is not a valid solution.
As an alternative, you are also able to use a “non-linux” URSim in a virtual machine.
Then you are able to deploy directly to this, using the URSim VM option to deploy the URCap.
The URSim VM is directly able to run daemons, and you will not have to change your host computers hostname.
Ok, I believe that this can a good compromise for linux users.
Instead of permanently renaming the hostname of the machine to
ursim, you can:
- add an alias to your hostname in
/etc/hosts; something like this:
127.0.1.1 your_hostname your_alias [...].
/etc/hostnameas it is and temporarily change the current hostname by running
sudo hostname ursim. And this will remain valid until reboot.
Credit to https://jblevins.org/log/hostname.