Debugging a KNIME workflow run on a command line

I have a workflow that runs fine from the KNIME platform on the desktop (Windows 10) and now I’m trying to run it from a Linux (CentOS) command line.
The workflow is failing after about 10 minutes (It takes around an hour to run on Windows) but not producing any useful error information.
(The output file is not produced.)
A couple of warnings appear on the screen, but they’re expected.
The knime.log file contains the same warnings.

What I’m looking for is:
1) Experience other users may have figuring out why workflows fail when run on the command line.
2) Whether there a way to enhance logging in these situations? [The following message appears on the screen
SLF4J: Failed to load class “org.slf4j.impl.StaticLoggerBinder”.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See for further details.
Perhaps there’s more information that might be available of an additional jar file were supplied. I am at a loss as to which JAR file to add for more logging and where to put the file.]
3) Any additional command line options that help?

My command line:
/var/knime/knime_4.2.1/knime -nosplash -nosave -application org.knime.product.KNIME_BATCH_APPLICATION -workflowFile=truncated3.knwf -workflow.variable=PreviousDataFilePath,/tmp/dump-public-2020-07-07,String -workflow.variable=NewDataFilePath,/tmp/dump-public-2020-08-11,String -workflow.variable=OutputFilePath,/home/centos/test5.xlsx,String -workflow.variable=MaxRecords,50,int

Have you tried the


option. And is there a reason why you do not reset the workflow at the start?

Then you could try and give a location for a log file

Then you could try and also give a workflow directory (not sure if this will help)

Then there is this hint by @ipazin how to modify log setting in the inner workings of knime or set a configuration file.

And finally there is this article elaboration on batch execution. Maybe this gives further ideas.

The error message sounds like there could be a problem with the settings of logging in general. So maybe explicitly telling the system what to do with logs could help.


Thank you, mlauber! I did get the workflow the run on the command line.
The -consoleLog option didn’t product any new info.
I wasn’t using -reset because the workflow was reset when it was exported.
Setting a log4J config file worked.

What worked was adding space to the disk and optimizing the workflow to run faster, and, presumably, with fewer resources.

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