Universal Robots+

Daemon service does not start any longer

I have some trouble with the DaemonService using the new ursim (either 5.0.3.30563 or 3.6.0.30512) 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 ERROR.
And if I test the runit service through sudo sv check runsvdir-ursim-5.0.3.30563 it returns as expected: ok: run: runsvdir-ursim-5.0.3.30563: (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 ps aux?

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-3.5.0.10584
root      1218  0.0  0.0   4240   644 ?        Ss   lug05   0:00 runsv runsvdir-ursim-3.5.1.10661
root      1227  0.0  0.0   4240   652 ?        Ss   lug05   0:00 runsv runsvdir-ursim-3.5.2.10778
root      1225  0.0  0.0   4240   696 ?        Ss   lug05   0:00 runsv runsvdir-ursim-3.5.3.10825
root      1226  0.0  0.0   4240   648 ?        Ss   lug05   0:00 runsv runsvdir-ursim-3.6.0.30512
root      1223  0.0  0.0   4240   648 ?        Ss   lug05   0:00 runsv runsvdir-ursim-5.0.3.30563
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-3.5.0.10584/service
alextoi+  1228  0.0  0.0   4392  1112 ?        S    lug05   0:00 runsvdir /opt/universal-robots/ursim-3.5.1.10661/service
alextoi+  1238  0.0  0.0   4392  1156 ?        S    lug05   0:00 runsvdir /opt/universal-robots/ursim-3.5.2.10778/service
alextoi+  1232  0.0  0.0   4392  1200 ?        S    lug05   0:00 runsvdir /opt/universal-robots/ursim-3.5.3.10825/service
alextoi+  1235  0.0  0.0   4392  1196 ?        S    lug05   0:00 runsvdir /opt/universal-robots/ursim-3.6.0.30512/service
alextoi+  1234  0.0  0.0   4392  1116 ?        S    lug05   0:00 runsvdir /opt/universal-robots/ursim-5.0.3.30563/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 ps aux:
image

Here it is how it looks in htop.
image

The fact is that I know I do not see the bundle daemon with either 5.0.3.30563 or 3.6.0.30512 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-5.0.3.30563/GUI /opt/universal-robots/ursim-5.0.3.30563 /opt/universal-robots/ursim-5.0.3.30563
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-3.6.1.30595, 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.

From release ursim-3.6.0.30512 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:

<whatever>/ursim-3.5.x/service/bundle@com.qbrobotics...
<whatever>/ursim-3.5.x/service/bundle@com...

Current setup when the ursim-3.6.0.30512 is started:

<whatever>/ursim-3.5.x/service/     (empty)
~/service/bundle@com.qbrobotics...
~/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.

Thanks

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.

2 Likes

Seems not fixed in either ursim-3.7.0.40195 or ursim-5.1.0.40195.

1 Like

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 runit.
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.

1 Like

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 [...].
  • leave /etc/hostname as 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.

3 Likes