Logbak for python class

I am debugging a python script, that runs in the configuration phase of provisionning workflow. I simply want to see the standard error output in the logs.
i set these loggers :

 36     <logger name="com.morpheus.instance.CatalogUpdateSerice" level="ERROR"/>
 37     <logger name="com.morpheus.task.TaskService" level="DEBUG"/>
 38     <logger name="com.morpheus.task.PythonTaskService" level="DEBUG"/>
 39     <logger name="com.morpheus.task.LocalScriptTaskService" level="DEBUG"/>

but it does’nt shom me what i want. (i don’t have the error output of my script.

what logger should i set to DEBUG ? i’m running 7.0.2

You should not need to set a logger to get standard error output from a python task.

Can you post what you are seeing on your end?

I don’t have any output at all from the script at all :

2024-06-13_21:19:13.38985 '[2024-06-13 21:19:13,389] [RxCachedThreadScheduler-145] INFO  c.m.t.PythonTaskService - Python Binary: /var/opt/morpheus/morpheus-local/workspace/py-7c11c562-1b15-47bb-bdbc-473d386b9
2024-06-13_21:19:13.38990 ''[2024-06-13 21:19:13,390] [RxCachedThreadScheduler-145] INFO  c.m.t.PythonTaskService - Running this script: [sudo, -S, -u, morpheus-local, /var/opt/morpheus/morpheus-local/workspacs]
2024-06-13_21:19:13.39034 ''[2024-06-13 21:19:16,218] [RxCachedThreadScheduler-145] INFO  c.m.t.PythonTaskService - Task Results for additionalPackages: [success:true, output:Collecting requests
2024-06-13_21:19:16.21900   Using cached requests-2.32.3-py3-none-any.whl (64 kB)
2024-06-13_21:19:16.21901 Collecting charset-normalizer<4,>=2
2024-06-13_21:19:16.21902   Using cached charset_normalizer-3.3.2-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (142 kB)
2024-06-13_21:19:16.21903 Collecting urllib3<3,>=1.21.1
2024-06-13_21:19:16.21903   Using cached urllib3-2.2.1-py3-none-any.whl (121 kB)
2024-06-13_21:19:16.21904 Collecting idna<4,>=2.5
2024-06-13_21:19:16.21904   Using cached idna-3.7-py3-none-any.whl (66 kB)
2024-06-13_21:19:16.21905 Collecting certifi>=2017.4.17
2024-06-13_21:19:16.21905   Using cached certifi-2024.6.2-py3-none-any.whl (164 kB)
2024-06-13_21:19:16.21906 Installing collected packages: urllib3, idna, charset-normalizer, certifi, requests
2024-06-13_21:19:16.21907 Successfully installed certifi-2024.6.2 charset-normalizer-3.3.2 idna-3.7 requests-2.32.3 urllib3-2.2.1
2024-06-13_21:19:16.21907 , error:, process:Process[pid=816055, exitValue=0], exitValue:0, exception:null]
2024-06-13_21:19:16.21908 ''[2024-06-13 21:19:16,219] [RxCachedThreadScheduler-145] INFO  c.m.t.PythonTaskService - Executing Task vmcreation-task-createAzureRG - Python Container Scriptlet... [sudo, -S, -u, m62-1b15-47bb-bdbc-473d386b9753/bin/python, -B, -]
2024-06-13_21:19:16.21926 ''[2024-06-13 21:19:17,548] [RxCachedThreadScheduler-145] INFO  c.m.t.PythonTaskService - Executing Task vmcreation-task-createAzureRG - Python Container Scriptlet...Complete

Typically in programs, exitValue=0 means it executed successfully without any errors and exception:null shows no exception were raised. What do you see on the task when you run it?

Here is a task I created that raises a error.

Are you sure your python task is throwing a error? What does it look like if you run it outside of Morpheus?

Hello Tyler,
In the particular case of my logs :

As you can see, i don’t have any more information than the stacktrace. especialy my debug informations, so debbuging this is a nightmare :smiley:


I see.

Although it does tell you the reason for failing. You are trying to access a key in a dictionary that does not exists.


I understand the error ; this is not my problem.
My problem is that i can’t see stderr nor stdout in morpheus-ui logs, and it used to work.

I wanted to dump intermediate value, for example.

ha sorry, totally missed “runs in the configuration phase” in your original post. :sweat_smile:

I’m not aware of a way to do that, but maybe someone else knows?

Not sure if that would be a capability due to the nature of the config phase. Morpheus takes the output of the task and uses that as the spec. Meaning if you had print statements mixed it, it would break the deployment.

As Tyler mentioned, we’re using stdout to resubmit the spec data back to Morpheus during the configuration phase. I’ve found that raising a Python exception and then exiting with a non-zero value will stop the configuration phase in it’s tracks and provide an error message to the user, which can be very helpful.

In the case of debugging, I just tested outputting strings to stderr and it didn’t seem to have an effect on the spec that was output after that. It even showed up in the Morpheus logs. The stdout spec did not show up in the logs, and I believe that’s by design.

1 Like

In that case, it’s nearly impossible to debug a script that is using morpheus context.
I don’t have that problem with powershell, for wich activating the right logger prints out every information i need, including “debugging prints”.
I think i’ve already achieved to have these information in a previous version of morpheus, like 6.0.x