Add stack trace into make logs if DEBUG True

[psyray]

To track Error 500 and easily debug reNgine from the make logs command

To activate debug, from the root directory of reNgine :

1. Edit web/entrypoint.sh and add at the top export DEBUG=1

#!/bin/bash

export DEBUG=1

python3 manage.py migrate
python3 manage.py runserver 0.0.0.0:8000

exec "$@"

2. Restart the web container docker-compose restart web
3. To deactivate set DEBUG to 0 and restart web container

Then, with DEBUG set to 1, in the make logs output you could see the full stack trace to debug reNgine,.
Example with the tool arsenal version check API bug.
Now you know the real error TypeError: run_command() got an unexpected keyword argument 'echo'
And you can post it to the issue you can create to help developers to track the root cause and correct the bug easily

proxy_1        | 172.16.20.6 - - [18/Oct/2023:12:32:59 +0000] "GET /api/external/tool/get_current_release/?tool_id=12 HTTP/2.0" 500 103547 "https://rengine.local/scanEngine/cw-okay/tool_arsenal" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0" "-"
web_1          | django.request | Internal Server Error: /api/external/tool/get_current_release/
web_1          | Traceback (most recent call last):
web_1          |   File "/usr/local/lib/python3.10/dist-packages/django/core/handlers/exception.py", line 47, in inner
web_1          |     response = get_response(request)
web_1          |   File "/usr/local/lib/python3.10/dist-packages/django/core/handlers/base.py", line 181, in _get_response
web_1          |     response = wrapped_callback(request, *callback_args, **callback_kwargs)
web_1          |   File "/usr/local/lib/python3.10/dist-packages/django/views/decorators/csrf.py", line 54, in wrapped_view
web_1          |     return view_func(*args, **kwargs)
web_1          |   File "/usr/local/lib/python3.10/dist-packages/django/views/generic/base.py", line 70, in view
web_1          |     return self.dispatch(request, *args, **kwargs)
web_1          |   File "/usr/local/lib/python3.10/dist-packages/rest_framework/views.py", line 509, in dispatch
web_1          |     response = self.handle_exception(exc)
web_1          |   File "/usr/local/lib/python3.10/dist-packages/rest_framework/views.py", line 469, in handle_exception
web_1          |     self.raise_uncaught_exception(exc)
web_1          |   File "/usr/local/lib/python3.10/dist-packages/rest_framework/views.py", line 480, in raise_uncaught_exception
web_1          |     raise exc
web_1          |   File "/usr/local/lib/python3.10/dist-packages/rest_framework/views.py", line 506, in dispatch
web_1          |     response = handler(request, *args, **kwargs)
web_1          |   File "/usr/src/app/api/views.py", line 922, in get
web_1          |     _, stdout = run_command(tool.version_lookup_command, echo=True)
web_1          |   File "/usr/local/lib/python3.10/dist-packages/celery/local.py", line 182, in __call__
web_1          |     return self._get_current_object()(*a, **kw)
web_1          |   File "/usr/local/lib/python3.10/dist-packages/celery/app/task.py", line 411, in __call__
web_1          |     return self.run(*args, **kwargs)
web_1          | TypeError: run_command() got an unexpected keyword argument 'echo'

Activating debug like this also give you the full stack trace in the browser
Here the schedule scan 500 error

[AnonymousWP]

Great. Do we need to add/explain this in the README? Your explanation, that is, regarding how to enable it.

[psyray]

Great. Do we need to add/explain this in the README? Your explanation, that is, regarding how to enable it.

Yes It could be good to explain it to all the users to help us debug things
This PR should be merged ASAP

[AnonymousWP]

Great. Do we need to add/explain this in the README? Your explanation, that is, regarding how to enable it.

Yes It could be good to explain it to all the users to help us debug things This PR should be merged ASAP

Well I obviously can't push commits to your branch, so you'll have to add it by yourself unfortunately.

[psyray]

Great. Do we need to add/explain this in the README? Your explanation, that is, regarding how to enable it.
Yes It could be good to explain it to all the users to help us debug things This PR should be merged ASAP

Well I obviously can't push commits to your branch, so you'll have to add it by yourself unfortunately.

Done !

[yogeshojha]

I will wait until both of you decide on the suggestions by @AnonymousWP .

[psyray]

@AnonymousWP Modifications added
His english is better than mine 😁

[AnonymousWP]

@AnonymousWP Modifications added His english is better than mine 😁

Huh? You could have just merged my suggestions and solve the thread. You committed my changes now or? Seems inefficient.

[yogeshojha]

@AnonymousWP No I think he hasnt commited. @psyray please resolve all comments.

[psyray]

@AnonymousWP Modifications added His english is better than mine 😁

Huh? You could have just merged my suggestions and solve the thread. You committed my changes now or? Seems inefficient.

Sorry bad usage ....
But changes are correct now, no ?

[psyray]

@AnonymousWP No I think he hasnt commited. @psyray please resolve all comments.

Done

[psyray]

Applied

Corrected myself, bad github usage for me

[AnonymousWP]

Suggestion: maybe we could make it easier without having to edit files, e.g. make it a command? Editing reNgine files locally cause Git to pick it up as a changed file, which in turn may become confusing to users when running update.sh, although they're being asked whether they want to apply their local changes or not.

[psyray]

Suggestion: maybe we could make it easier without having to edit files, e.g. make it a command? Editing reNgine files locally cause Git to pick it up as a changed file, which in turn may become confusing to users when running update.sh, although they're being asked whether they want to apply their local changes or not.

You're right.
It could be added to .env file, but it is tracked also by git (it should be removed because it generates the same git problem while updating, no ?)

It could be added to a docker-compose-debug.yaml file, but to launch debug it needs a long make down && make up, a simple quick make restart does not works.

Only the entrypoint.sh provides a way to activate debug with only a make restart
This is why I say to do this.

If you have a solution to switch to debug without change git index only by doing a make restart I'm OK

Maybe we can in the entrypoint.sh check for the existence of a DEBUG file and set export var like this

if [ -f DEBUG ]; then
  export DEBUG=1
fi

[AnonymousWP]

Suggestion: maybe we could make it easier without having to edit files, e.g. make it a command? Editing reNgine files locally cause Git to pick it up as a changed file, which in turn may become confusing to users when running update.sh, although they're being asked whether they want to apply their local changes or not.

You're right. It could be added to .env file, but it is tracked also by git (it should be removed because it generates the same git problem while updating, no ?)

It could be added to a docker-compose-debug.yaml file, but to launch debug it needs a long make down && make up, a simple quick make restart does not works.

Only the entrypoint.sh provides a way to activate debug with only a make restart This is why I say to do this.

If you have a solution to switch to debug without change git index only by doing a make restart I'm OK

Maybe we can in the entrypoint.sh check for the existence of a DEBUG file and set export var like this

if [ -f DEBUG ]; then
  export DEBUG=1
fi

I'm not exactly sure tbh, maybe @yogeshojha has an idea.

[psyray]

This one should be reverted in favor of #1196