I have a python-flask hangman game, that I tried to wrap into a single executable file using pyinstaller with the following command line:
pyinstaller -w -F --add-data "templates:templates" --add-data "static:static" hangman.py
It seemed to work fine, and created build, dist, as well as the .spec file However, when I try to run the executable, I get the following error:
flask_sqlalchemy/__init__.py:800: UserWarning: SQLALCHEMY_TRACK_MODIFICATIONS adds significant overhead and will be disabled by default in the future. Set it to True to suppress this warning.
* Serving Flask app "hangman" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
Traceback (most recent call last):
File "hangman.py", line 101, in <module>
File "flask/app.py", line 990, in run
File "werkzeug/serving.py", line 1012, in run_simple
File "werkzeug/serving.py", line 956, in inner
File "werkzeug/serving.py", line 807, in make_server
File "werkzeug/serving.py", line 701, in __init__
File "socketserver.py", line 452, in __init__
File "http/server.py", line 138, in server_bind
File "socketserver.py", line 466, in server_bind
OSError: [Errno 98] Address already in use
[46425] Failed to execute script 'hangman' due to unhandled exception!
I am relatively new to programming, so please don't mind any wrong use of technical terms.
Try to turn off the reloader like this :
app.run(debug=True, use_reloader=False)
[Edit]
it seems like some other application is using the same port. Check it by
netstat -tulpn
To get more information, you can use also :
tasklist
When you got the pid, I'd suggest stop it manually
You can also kill it via command kill:
Taskkill /PID THE_PORT /F
Related
after updating the Werkzeug version from 2.0.3 to 2.1.0, I keep getting errors every time I run the server, and here is the error log:
Exception happened during processing of request from ('127.0.0.1', 44612)
Traceback (most recent call last):
File "/usr/lib/python3.8/socketserver.py", line 683, in process_request_thread
self.finish_request(request, client_address)
File "/usr/lib/python3.8/socketserver.py", line 360, in finish_request
self.RequestHandlerClass(request, client_address, self)
File "/usr/lib/python3.8/socketserver.py", line 747, in __init__
self.handle()
File "/home/oladhari/.virtualenvs/reachat/lib/python3.8/site-packages/werkzeug/serving.py", line 363, in handle
super().handle()
File "/usr/lib/python3.8/http/server.py", line 427, in handle
self.handle_one_request()
File "/usr/lib/python3.8/http/server.py", line 415, in handle_one_request
method()
File "/home/oladhari/.virtualenvs/reachat/lib/python3.8/site-packages/werkzeug/serving.py", line 243, in run_wsgi
self.environ = environ = self.make_environ()
File "/home/oladhari/.virtualenvs/reachat/lib/python3.8/site-packages/django_extensions/management/commands/runserver_plus.py", line 326, in make_environ
del environ['werkzeug.server.shutdown']
KeyError: 'werkzeug.server.shutdown'
this exception keep appearing while incrementing by 2 ( ('127.0.0.1', 44612) -> ('127.0.0.1', 44628) and the server crash
checking the changes log, I have found this detail:
Remove previously deprecated code. #2276
Remove the non-standard shutdown function from the WSGI environ when running the development server. See the docs for alternatives.
here is the link to the changes log
it asks to check the documentation for alternatives but can not find any
please let me know how I would resolve this error, thank you
NB: my python version is 3.8
Literally just ran into this today. According to their (git repo issue 1715) and assuming you are running runserver_plus, there are three options that worked for some users. The first worked for me:
Not altering your files and adding the option --keep-meta-shutdown. My full command looks like python manage.py runserver_plus --cert-file /path/to/cert.pem --key-file /path/to/key.pem --keep-meta-shutdown localhost:9000
Comment out open lines 325 and 326 under your runserver_plus.py
Upgrading python to 3.10
Hope this helps!
The Django-extensions issue for this recommends running runserver_plus with the --keep-meta-shutdown argument.
Alternatively, you can just downgrade Werkzeug to 2.0.* until this is fixed:
pip install Werkzeug==2.0.*
If using a requirements.txt file, use the following:
Werkzeug==2.0.*
I have set up airflow on an Ubuntu server. I started the webserver just fine as a daemon process. I can start the scheduler using
airflow scheduler
and it works fine and the dags run. I then stop it and remove all the airflow-scheduler files in $AIRFLOW_HOME (airflow-scheduler.err, airflow-scheduler.log, airflow-scheduler.out)
I then try to start it as a daemon process using
airflow scheduler -D
It appears to start okay without error. However when I got to the webserver it says:
"The scheduler does not appear to be running. Last heartbeat was received 2 minutes ago.
The DAGs list may not update, and new tasks will not be scheduled."
When I look in airflow-scheduler.err I see:
Traceback (most recent call last):
File "/home/emauser/.local/lib/python3.6/site-packages/sqlalchemy/pool/base.py", line 503, in <lambda>
File "/home/emauser/.local/lib/python3.6/site-packages/sqlalchemy/pool/base.py", line 702, in _finalize_fairy
File "/usr/lib/python3.6/logging/__init__.py", line 1337, in error
File "/usr/lib/python3.6/logging/__init__.py", line 1444, in _log
File "/usr/lib/python3.6/logging/__init__.py", line 1454, in handle
File "/usr/lib/python3.6/logging/__init__.py", line 1516, in callHandlers
File "/usr/lib/python3.6/logging/__init__.py", line 865, in handle
File "/usr/lib/python3.6/logging/__init__.py", line 1071, in emit
File "/usr/lib/python3.6/logging/__init__.py", line 1061, in _open
NameError: name 'open' is not defined
Any idea why I'm getting an error on the built-in open function from the logging module?
Before restarting your scheduler in daemon mode, make sure no other scheduler process are running.
ps aux | grep airflow-scheduler
If there are any , kill them and then start your scheduler as a daemon .
OS Windows 10,
I am using Docker Engine version 18.09.2, the API version is 1.39
The website explaining the steps to run CAT is: https://libraries.io/pypi/medcat
I am building the medcat image locally. Output looks good until the end of the build process:
Step 10/11 : ENTRYPOINT ["python"]
---> Using cache
---> 66b414e2093d
Step 11/11 : CMD ["api.py"]
---> Using cache
---> db2acf6c4649
Successfully built db2acf6c4649
Successfully tagged cat:latest
SECURITY WARNING: You are building a Docker image from Windows against
a non-Windows Docker host. All files and directories added to build
context will have '-rwxr-xr-x' permissions. It is recommended to
double check and reset permissions for sensitive files and
directories.
When I am trying to start the container I just built, I get:
IT IS UMLS
* Serving Flask app "api" (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a
production deployment.
Use a production WSGI server instead.
* Debug mode: on
Traceback (most recent call last):
File "api.py", line 66, in <module>
app.run(debug=True, host='0.0.0.0', port=5000)
File "/usr/local/lib/python3.7/site-packages/flask/app.py", line
944, in run
run_simple(host, port, self, **options)
File "/usr/local/lib/python3.7/site-packages/werkzeug/serving.py",
line 1007, in run_simple
run_with_reloader(inner, extra_files, reloader_interval,
reloader_type)
File "/usr/local/lib/python3.7/site-packages/werkzeug/_reloader.py",
line 332, in run_with_reloader
sys.exit(reloader.restart_with_reloader())
File "/usr/local/lib/python3.7/site-packages/werkzeug/_reloader.py",
line 176, in restart_with_reloader
exit_code = subprocess.call(args, env=new_environ,
close_fds=False)
File "/usr/local/lib/python3.7/subprocess.py", line 323, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/local/lib/python3.7/subprocess.py", line 775, in __init__
restore_signals, start_new_session)
File "/usr/local/lib/python3.7/subprocess.py", line 1522, in
_execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/cat/api/api.py'
Does anyone have experience with building on Windows? Does the security warning have anything to do with this?
Update:
I added the permission for linux executable as in the received answer at this post. Then I built the image locally using the following command docker build --network=host -t cat -f Dockerfile.MedMen ., and the end of the building process gives me the same Security Warning.
Then I checked docker run --env-file=./envs/env_medann ubuntu:18.04 env, which gave me:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=3d5fd66fadbe
TYPE=UMLS
DEBUG=False
CNTX_SPAN=6
CNTX_SPAN_SHORT=2
MIN_CUI_COUNT=100
MIN_CUI_COUNT_STRICT=1
MIN_ACC=0.01
MIN_CONCEPT_LENGTH=1
NEG_PROB=0.2
LBL_STYLE=def
SPACY_MODEL=en_core_sci_md
UMLS_MODEL=/cat/models/med_ann_norm.dat
VOCAB_MODEL=/cat/models/med_ann_norm_dict.dat
MKL_NUM_THREAD=1
NUMEXPR_NUM_THREADS=1
OMP_NUM_THREADS=1
HOME=/root
This is because windows & linux has CR-LF & LF difference issue, meanwhile, permission need to be added for linux executable.
For your case, as you have got the source code, I think you have git installed on your windows. Then, you can open Git Bash, change the path to your source code directory, and execute next in it:
find . -type f | xargs dos2unix
chmod -R 777 *
Finally, rebuild it.
Update:
I try your code completely, it seems the issue is in cat/api/api.py, it misses a #!. So, into your sourcecode, edit cat/api/api.py, add next at the beginning of the sourcecode:
#!/usr/bin/env python
Then, rebuild with Dockerfile & run it again, you can see the effect from browser:
We have established pipelines scripts that work very well. Lately, we decided to deploy to elastic beanstalk automatically, with the use of bitbucket pipelines and following the tutorial which uses the command eb deploy to deploy. Apparently, this command fails on pipelines. The config files seem legit because it runs locally. It also runs from inside a container of the same image that we have specified in the pipelines file and also by using docker exec from the local to run the command inside a container of the same image. The following are the pipelines file and the error we get using eb deploy --verbose command. I am obviously missing something here. Any help or direction would be appreciated. Thanking you in advance.
feature/KKLT-1065-deploy-via-pipelines:
- step:
deployment: staging
caches:
- composer
script:
- php -r "file_exists('.env') || copy('.env.example', '.env');"
- cat .env
- composer install
- php artisan cache:clear
- php artisan migrate
- php artisan db:seed
- eb init KMLT-staging-ttl -r eu-central-1 -p "64bit Amazon Linux 2017.09 v2.6.4 running PHP 7.1"
- eb deploy --verbose
services:
- postgres
+ eb deploy --verbose
INFO: Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ebcli/core/ebrun.py", line 41, in run_app
app.run()
File "/usr/lib/python2.7/site-packages/cement/core/foundation.py", line 797, in run
return_val = self.controller._dispatch()
File "/usr/lib/python2.7/site-packages/cement/core/controller.py", line 472, in _dispatch
return func()
File "/usr/lib/python2.7/site-packages/cement/core/controller.py", line 475, in _dispatch
self._parse_args()
File "/usr/lib/python2.7/site-packages/cement/core/controller.py", line 452, in _parse_args
self.app._parse_args()
File "/usr/lib/python2.7/site-packages/cement/core/foundation.py", line 1076, in _parse_args
for res in self.hook.run('post_argument_parsing', self):
File "/usr/lib/python2.7/site-packages/cement/core/hook.py", line 150, in run
res = hook[2](*args, **kwargs)
File "/usr/lib/python2.7/site-packages/ebcli/core/hooks.py", line 35, in pre_run_hook
set_profile(app.pargs.profile)
File "/usr/lib/python2.7/site-packages/ebcli/core/hooks.py", line 47, in set_profile
profile = commonops.get_default_profile()
File "/usr/lib/python2.7/site-packages/ebcli/operations/commonops.py", line 973, in get_default_profile
profile = get_config_setting_from_branch_or_default('profile')
File "/usr/lib/python2.7/site-packages/ebcli/operations/commonops.py", line 1008, in get_config_setting_from_branch_or_default
setting = get_setting_from_current_branch(key_name)
File "/usr/lib/python2.7/site-packages/ebcli/operations/commonops.py", line 991, in get_setting_from_current_branch
branch_name = source_control.get_current_branch()
File "/usr/lib/python2.7/site-packages/ebcli/objects/sourcecontrol.py", line 184, in get_current_branch
stdout, stderr, exitcode = self._run_cmd(revparse_command, handle_exitcode=False)
File "/usr/lib/python2.7/site-packages/ebcli/objects/sourcecontrol.py", line 480, in _run_cmd
stdout, stderr, exitcode = exec_cmd(cmd)
File "/usr/lib/python2.7/site-packages/cement/utils/shell.py", line 40, in exec_cmd
proc = Popen(cmd_args, *args, **kw)
File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
INFO: OSError - [Errno 2] No such file or directory
Try python3 version of eb instead of python2.7. Might have more success.
I am currently having a problem with vagrant. I used it before for a number of tasks, but now when I do vagrant up and then vagrant ssh, everything seems to work ok. Then I navigate into the vagrant folder to run a python file and when I run it I get the following error:
vagrant#vagrant:/vagrant$ python project.py
Traceback (most recent call last):
File "project.py", line 75, in
app.run(host='0.0.0.0.', port=8080)
File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 841, in run
run_simple(host, port, self, **options)
File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 720,
in run_simple
s.bind((hostname, port))
File "/usr/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
socket.gaierror: [Errno -2] Name or service not known
I tried multiple times to restart vagrant, I also tried vagrant destroy and restarted the process. I manually deleted and powered it off a couple of times, but I always experience the same error. I would appreciate any help. Thank you.
The problem isn't vagrant... This line in the stacktrace shows there could be a typo in your python script
app.run(host='0.0.0.0.', port=8080)
Should be
app.run(host='0.0.0.0', port=8080)