R HOME is invalid on KNIME Server

I created a simple workflow on my laptop using the KNIME Analytics Platform and it worked. This workflow has an "R Snippet" node. I then deployed this workflow to R Server and executed it there, but it does not work. The error message is "Execute failed: R Home is invalid."

What do I need to do in order to make this workflow work on Knime Server? I installed R on the server and I am able to run R scripts on the server.

I have attached two files:

1. local.png shows the workflow on my laptop (works fine).

2. webportal.png shows the workflow execution on the webportal.

Here is some more information.

Page 8 of the Knime Server Administration manual (https://download.knime.org/server/4.3/KNIME_Server_Administration_Guide_4.3.pdf) talks about how to make use of a preference file to take local changes to the server. We tried that, but it did not work.

This is what we did:

1. We copied the exported file from our laptop to the "workflow_repository/config" folder on the server.

2. We made the name of that file be preferences.epf.

3. We also edited the file to change the path of R. That line looks like this now: "/instance/org.knime.ext.r.bin/knime.r.home=/usr/lib64/R"

By the way, we installed R on the Linux server "after" we installed "Knime Server". We are running RedHat. We installed R by runnning "sudo yum install R".

I should mention that we have successfully deployed and executed workflows that do not use the R node.

Every time we make a change on the server, we stop and start by doing this:



Our problem has been solved. The steps that I described in this post were all correct. The problem is that we had a bit of bad luck with a hung process on the Linux server. Here's what happened:

1. We installed KNIME Server on the Linux machine on January 7.

2. We installed R on the Linux machine on January 10. We then restarted KNIME Server by running the shutdown.sh and starup.sh scripts in /bin/. We actually did this many times after installing R, but things would not work.

3. On January 13 we did a "ps -ef" on the Linux server and we noticed that the KNIME exectutor processes being used were from January 7. We killed those processes and restarted KNIME. Things started working.

I was not able to duplicate this problem again. I'm attributing it to bad luck on January 7.

It's all good now.