Workflow gets stuck in Task Manager after execution via Windows Task Scheduler

Hey guys,

I have got the problem that my knime workflow doesn’t terminate and still remains in the Windows Task Manager, after it finnished succesfully.

I am using the following code to execute the workflow.

“C:\Program Files\KNIME\knime.exe” -reset -consoleLog -nosave -nosplash -application org.knime.product.KNIME_BATCH_APPLICATION -workflowFile= …"

The problem occures when I use the Security options in the Windows Task Scheduler (i am using Windows Server 2019 btw), shown below.

task%20scheduler

When choosing the option “Run whether use is logged on or not” the workflow will be executed in the background, so unfortunately there will be no console that shows any potential errors.

On the other hand, when just testing the batch file out of the shell, it works fine and the task terminates after the workflow has finnished. And it also works fine when running the batch file with the Secuirty options set to “Run only when user is logged on” out of the Task Scheduler.

Does someone know how to fix this problem?

Thanks in advance
Tobi

Hi @Tobias_Grein,

please post the full batch command to trigger your workflow. In addition you search for other forum posts about batch execution as it was a challenge to me in the beginning too. It was all about the parameters and their order at the very end …

Cheers
Mike

Hi @mw,

this is the full code and those are the only variables I am using in that batch file.

Cheers
Tobi

Hi @Tobias_Grein,

here is my shell script to execute Knime via batch mode. Please note that application is triggered w/o exe since it’s running on Linux.

#!/bin/bash
cd /PATH-TO-KNIME-APP/
./knime -consoleLog -nosplash -application org.knime.product.KNIME_BATCH_APPLICATION -reset -nosave --launcher.suppressErrors -workflowDir=/PATH-TO knime-workspace-WITH-escaped\ spaces
./knime -consoleLog -nosplash -application org.knime.product.KNIME_BATCH_APPLICATION -reset -nosave --launcher.suppressErrors -workflowDir=/NEXT-WORKFLOW-TO-EXECUTE

In case you’d like to log the errors you’ve got to use the corresponding instructions. I am explicitly not logging them as the log level with warning contains too much noise.

Maybe worth to read some of the more advanced examples like this.

Hope this helps …

Cheers
Mike

Hi @mw,
thank you for sharing your script with me. Unfourtanetly changing the order of the variables did not solve the problem.
But I have another guess on what may cause the problem.

I am reading files from a mounted drive that are automatically assinged during server start. Do you know if I have to reconnect or use the credenitals for login in the batch file again so that the script can finally be executed via the Windows Task Scheduler?

Cheers
Tobi

Are you re-asking this question?

Hey guys,

the topic can be closed. =)

The solution was to map the drives in the batch file, so that the mapping is done during the batch execution.

@echo off
echo start
:: delete mapped netdrive
net use Y: /delete
net use Z: /delete
:: map drives
net use /persistent:No Y: \IP-Adress\file-path pw /user
net use /persistent:No Z: \IP-Adress\file-path pw /user

“C:\Program Files\KNIME\knime.exe” -consoleLog -nosplash -application org.knime.product.KNIME_BATCH_APPLICATION -reset -nosave -workflowFile=“C:\Users*******” -preferences=“C:\Users**********epf”
:: delete mapped netdrive
net use Y: /delete
net use Z: /delete

echo finnished

The problem in my case is that the user who executes the Task Scheduler, does not have the specific rights to read and write to the mapped drives. So if you map the drives first by hand with the right user and then use the task scheduler to execute the task with the system user, it fails and remains in the Task Manager.

However, if you do the mapping in the batch file, the workflow can acess the drives with the right credentials, while the scheduled task is executed by the local system user.

Thank you all for your suggestions and help.

Cheers
Tobi

1 Like

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