python3_flask application is not running when installing the plugin from a .plugin file

[dearith]

I come accross a very strange issue.

When I install a python3_flask plugin from a .plugin file, the plugin is installed but is not running.

Steps to reproduce:

bootstrap_plugin.py create --template=python3_flask foo_flask10

cd foo_flask10

make release

plugins.install foo_flask10-0.0.1-1.metwork.mfserv.plugin

mfserv.stop;mfserv.start

plugins.list is OK the plugin is intalled: foo_flask10 │ 0.0.1 │ 1 │ /home/dearith10/metwork/mfserv/var/plugins/foo_flask10

The config.ini file in the source contains the _cmd_and_args:

...
[app_main]

# Command to be executed
# Notes:
# - null means no command to execute
# - this command can be launched several times (see workers/numprocesses)
# - the command must listen to {unix_socket_path} (dynamically generated)
# - the launched command must run foreground and listen for http requests on
#   {unix_socket_path} unix socket
# - you can use following placeholders:
#   - {unix_socket_path} (full path for a unique dynamically generated unix
#                         socket for the worker)
#   - {timeout} (timout in seconds for dealing with 1 request)
#   - {plugin_name} (plugin name)
#   - {plugin_dir} (plugin directory full path)
#   - {app_name} (app name without app_ prefix)
#   - {debug_extra_options} (the content of debug_extra_options only if debug=1
#                            or empty if debug=0)
_cmd_and_args=bjoern_wrapper.py {debug_extra_options} --timeout={timeout} {app_name}.wsgi:app "{unix_socket_path}"

# Very advanced options, change this only if you exactly know what you are doing
# The previous command is wrapped into a signal_wrapper.py app.
# When we want to do a "really smart" restart, the stop signal is catched by
#   signal_wrapper which:
# (1) order to nginx to stop to route new requests to this process
# (2) wait until there is no connection active to the process anymore
#     (the timeout of this way is given by the {timeout} key)
# (3) send {smart_stop_signal} to the configured command ({cmd_and_args})
...

The _cmd_and_args is missing in the mfserv/config/plugins/foo_flask10.ini (but it seems normal compared ot other type of plugin, e.g. aiohttp):

...
# (you can have several section like this one named [app_xxx])
[app_main]

# Very advanced options, change this only if you exactly know what you are doing
# The previous command is wrapped into a signal_wrapper.py app.
# When we want to do a "really smart" restart, the stop signal is catched by
#   signal_wrapper which:
# (1) order to nginx to stop to route new requests to this process
# (2) wait until there is no connection active to the process anymore
#     (the timeout of this way is given by the {timeout} key)
# (3) send {smart_stop_signal} to the configured command ({cmd_and_args})
...

The config.ini file in the /mfserv/var/plugins/foo_flask10 is same as the config.ini of the source file (contains the _cmd_and_args):

The log file of the plugin is empty.

bjoern_wrapper.py exists : /opt/metwork-mfserv-1.0/bin/bjoern_wrapper.py

MFEXT_HOME is OK : MFEXT_HOME=/opt/metwork-mfext-1.0

I didn't find any issue in the other Metwork log files.

The plugin built in dev. (make develop) works.

My other aiohttp plugins work when installing them from a .plugin file.

Any idea ?

[dearith]

Ooops sorry, I think I made a mistake : my foo_flask110 works. But I have migrated another plugin from Metwork 0.9 to Metwork 1.0.

Perhaps, something is wrong in this plugin. But I don't why it working with make develop but not working from .plugin installation. I am looking for the .releaseignore file, but it seems OK.

[dearith]

It's my fault. I have a lua script in the nginx extra conf to redirect to another plugin, and the http port is not the correct one (I have two mfserv running on my machine : metwork 0.9 on 188868 and metwork 1.0 on 18869.

Very sorry. This issue can be cancelled.