Knime AP won't launch, corrupt files in workspace?

I have been using the Knime Analytics Platform as a standalone application on linux for a few years. Recently when I launched the application the startup process appeared to stall. It would not render the welcome page and would not display items in my local workspace or the Node Repository.

When I created a new empty Knime workspace directory and and configured Knime to use the new directory it launched with no problems. If I import individual workflows or workflow groups from the old workspace directory they import and run successfully. This suggest to me that one or more files in the old workspace directory have become corrupted and are preventing the application from launching. I have tried deleting the knime-workspace/.metadata directory, but this does not fix the problem. A new .metadata directory is created the next time knime is launched, but it still stalls.

Are there any other files or directories that might become corrupted and prevent the Knime AP from completing its launch? I suppose the problem could be contained in a workflow group directory.

Hi @dougb

I’m sorry to hear about the issue. You are right, this can be caused by a corrupt workflow. This would probably be indicated by an error as seen in this forum post.

A possible quick fix would be to start KNIME Analytics Platform with the -clean parameter (or add it in the knime.ini in the installation folder).

If that does not help, you could check your logs with e.g.
grep incompatible <workspace-dir>/.metadata/.log
or manually check the last few entries. If you want, you can also share your logs and I’ll have a look at them.

As a workaround, I’d suggest copying roughly half of the workflows at a time over to a new workspace and see, if the program still launches (as in a binary search).

Kind regards
Marvin

PS. just incase this is a version specific problem, could you let me know which version of KNIME Analytics Platform you are using?

1 Like

Hi Marvin:
Thank you for responding to my request for assistance.

I have done a bit more trouble shooting today.
Here is what I observe today:

  1. I began my trouble shooting by renaming my old knime-workspace directory and creating a new empty one.

  2. I launch Knime 4.3.2 from the command line of my CentOS Linux 7 machine. It launches very quickly and a Example Wokflows appears in my local workspace.
    I list the files in my workspace directory:

$ ls -al
total 320K
drwxrwx—. 4 ddb17 hd 4.0K May 10 15:40 .
drwxr-x—. 103 ddb17 hd 24K May 7 16:44 …
drwxrwx—. 7 ddb17 hd 4.0K May 7 16:44 Example Workflows
drwxrwx—. 4 ddb17 hd 4.0K May 10 15:40 .metadata
ls -al .metadata
total 400K
drwxrwx—. 4 ddb17 hd 4.0K May 10 15:40 .
drwxrwx—. 4 ddb17 hd 4.0K May 10 15:40 …
drwxrwx—. 2 ddb17 hd 4.0K May 10 15:40 knime
-rw-rw----. 1 ddb17 hd 0 May 10 15:40 .lock
-rw-rw----. 1 ddb17 hd 3.4K May 10 15:40 .log
drwxrwx—. 9 ddb17 hd 4.0K May 10 15:40 .plugins
-rw-rw----. 1 ddb17 hd 26 May 10 15:40 version.ini

  1. I exit Knime using the File/Exit pull down menu.
    I confirm that no knime processes are running using ps -ef.
    I notice that all of the same files are present in the /.metadata directory:

ls -al .metadata
total 400K
drwxrwx—. 4 ddb17 hd 4.0K May 10 15:40 .
drwxrwx—. 4 ddb17 hd 4.0K May 10 15:40 …
drwxrwx—. 2 ddb17 hd 4.0K May 10 15:41 knime
-rw-rw----. 1 ddb17 hd 0 May 10 15:40 .lock
-rw-rw----. 1 ddb17 hd 3.4K May 10 15:40 .log
drwxrwx—. 10 ddb17 hd 4.0K May 10 15:41 .plugins
-rw-rw----. 1 ddb17 hd 26 May 10 15:40 version.ini

  1. I launch Knime again using the command line and it stalls not completing the loading of the user interface.

  2. If I exit the Knime application using the UI and delete the .metadata directory before relaunching Knime launches quickly and completely.
    My expectation was that the .lock file would be removed when the application was existed, but that is not what I observe.

I understand that because I have run this trouble shooting with a nearly empty workspace directory I may not be seeing all of the problems I originally described.

Doug

Hi Doug,

That’s a new one for me. I’ll have to do some digging and get back to you afterwards.
Could you send me the <workspace-dir>/.metadata/.log file?

Does anything change if you start KNIME with the -clean parameter?

Kind regards
Marvin

1 Like

Hi @dougb , it does not look like the .lock file is acting as a flag. Though I am running on Windows, I’m assuming it would work/run the same way in Linux.

When I close my Knime, the .lock file does not disappear, and I am able to re-launch Knime. The weird thing is that the .lock file does not get updated either when I re-launch Knime, and I can confirm that I am looking at the proper folder, since the .log file does get updated. I would have expected the .lock file to be removed upon closing of Knime, but it does not look like it’s acting as a semaphore flag.

Do try with the -clean parameter as @marvin.kickuth suggested.

Another thing to try, can you try to Restart (File/Restart) instead of Exit and see if the problem happens there too?

I am attaching the /.metadata/.log file. I generated this file after deleting the .metdata directory. The first time I launch Knime it launches quickly with all of the UI. It asks if I want to send data to Knime. Some content is written to the log file (see attached log file which has some added comments).

I then exit the application and launch the application a second time. This time the same content gets logged at startup, but the application stalls and does not complete the display of the UI. When I exit the application this time some content gets written to the log file which includes:
!MESSAGE Unhandled event loop exception
!MESSAGE An internal error occurred during: “Workflow Coach loader”.

I have a second linux machine (Ubuntu LTS 20.04) where I also have Knime installed. On that machine I do not see this problem and I see the same behavior of the .lock file that is seen by @Bruno29a. The .lock files persists between exit and re-launch the Knime application.

On the problematic machine (CentOS 7) I tried using File/Restart and see the behavior as when I exit and re-launch the application.

My suspicion is that the problem I am experiencing may be due to a missing or incompatible linux library on the older CentOS 7 machine since I do not see the problem on my machine running Ubuntu 20.04. I am stuck trying to make it work though as it is on a machine inside a data center that has high speed access to the large data sets I need to use.

Thanksknime_log.txt (13.3 KB)

1 Like

Hi @dougb

thanks for the logs (and the comments inside!). They don’t look too bad, nothing that would suggest anything is really broken.

KNIME AP doesn’t have many dependencies. Pretty much any machine with a GUI and Java support should do, but I don’t want to rule your idea out (especially if you have many plugins installed).

Is it possible for you to try a fresh KNIME Analytics Platform installation?
Convenient download link

If that doesn’t work or isn’t possible, you could (after once again deleting .metadata…) set the log level to DEBUG under File → Preferences → KNIME. Then restart the program, and send us the hopefully more detailed .metadata/.log file.

Kind regards
Marvin

It surely is a weird one, more so because of the fact that @dougb is able to create the workflow, so I’m leaning only at 50% towards missing/incompatible Linux library.

I do have a CentOS 7 box, but none my Linux instances have GUI installed, all command line only, so unfortunately I can’t test this on my side.

If you are hosting the OS, can you run a disk diagnosis to see if your hardware is ok? Even if it’s a VM, it’s still being saved on the Host’s physical drive.

Also @dougb , have you tried running Knime with the -clean parameter as @marvin.kickuth suggested?

I have not figured out what caused the problems I described earlier, but I have noticed that if I delete the contents of the ~/knime-workspace/.metadata/.plugins directory it consistently launches with no problem.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.