Gunicorn error unrecognized arguments

This documentation is for Dash Enterprise.
Dash Enterprise is the fastest way to write & deploy Dash apps and
Jupyter notebooks.
10% of the Fortune 500 uses Dash Enterprise to productionize AI and
data science apps. Find out if your company is using Dash Enterprise.

This page applies to Dash Enterprise 5. If your organization uses Dash Enterprise 4, view deployment troubleshooting information at https://<your-dash-enterprise-server>/Docs/dash-enterprise/troubleshooting.

This troubleshooting guide describes errors that you may encounter when deploying apps to Dash Enterprise as well as steps to resolve them. It can help you if you ran a Git command that was unsuccesful, or if the Overview of your app in the
App Info displays “Build failed” or “Deployment failed”.

Troubleshooting Checklist

• Verify that you can deploy an app in the App Catalog. These apps are supplied by Plotly and come with all the files required for deployment, which often allows you to eliminate app files as the cause of your issue.
• Check that your app contains a Procfile and a requirements.txt (pip) or environment.yml (Conda). Learn more about required files.
• Try running your app in a workspace.
• Try deploying your app from a workspace. In Workspaces, Git and SSH are preconfigured, which often allows you to eliminate Git and SSH configurations as the cause of your issue.
• Find the error message in your terminal, build logs, or app logs. Search for this error message on this page and follow the resolution steps.
• Reach out to our support team with the error that you encountered.

Common Errors

error: failed to push some refs to git@<dash-enterprise>:<app-name>

$ git push plotly main
[...]
To <your-dash-enterprise-server>:<your-dash-app>
! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to '<your-dash-enterprise-host>:<your-dash-app>'

This is a generic error message that indicates that the git push failed. Look for a different error message further up in the logs and search for that error on this page.

remote contains work that you do not have locally

$ git push plotly main
To <your-dash-enterprise-server>/GIT/<your-dash-app>
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '<your-dash-enterprise-server>/GIT/<your-dash-app>'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

This error occurs when the version of your app that is deployed to Dash Enterprise is ahead of what you have on your workstation. For example, if you use a shared GitHub repository to manage your app code, a colleague
may have made a change and pushed it to Dash Enterprise. Use a command like git pull origin main to get your colleague’s work locally before pushing your own changes to Dash Enterprise with git push plotly main.

Procfile not found

git push plotly main is successful, but the build fails and your build logs display

---> DEPLOYMENT SCRIPTS
Procfile not found. Please update your app and retry!
ERROR: failed to build: exit status 1

This error occurs when your app doesn’t contain a Procfile. See App Structure
for more details on Procfile.

Failed to find attribute ‘server’ in ‘app’

git push plotly main is successful, but the deployment fails and your app logs display

[2022-11-10 01:35:53 +0000] [18] [INFO] Worker exiting (pid: 18)
[2022-11-10 01:35:53 +0000] [21] [INFO] Worker exiting (pid: 21)
Failed to find attribute 'server' in 'app'.Failed to find attribute 'server' in 'app'.

This error occurs when server = app.server is missing from the entry point to your app (usually app.py).

The line server = app.server is required to define the server variable so that it can be exposed for the Procfile. See App Structure
for more details.

requirements.txt or environment.yml not detected

git push plotly main is successful, but the build fails and your build logs display

---> DEPLOYMENT SCRIPTS
requirements.txt or environment.yml not detected. Dash Enterprise only supports Python and Conda apps! Exiting..
ERROR: failed to build: exit status 1

This error occurs when your app doesn’t have a requirements.txt (pip) or environment.yml (Conda) file. Dash Enterprise
detects these files to select the buildpack and build your app. See App Structure
for more details.

bash: gunicorn: command not found

git push plotly main is successful, but the deployment fails and your app logs display

[2022-11-10 00:41:09 +0000] [1] [INFO] Handling signal: term
[2022-11-10 00:41:09 +0000] [18] [INFO] Worker exiting (pid: 18)
[2022-11-10 00:41:09 +0000] [21] [INFO] Worker exiting (pid: 21)
[2022-11-10 00:41:09 +0000] [19] [INFO] Worker exiting (pid: 19)
[2022-11-10 00:41:09 +0000] [20] [INFO] Worker exiting (pid: 20)
[2022-11-10 00:41:10 +0000] [1] [INFO] Shutting down: Master
bash: gunicorn: command not found
bash: gunicorn: command not found
bash: gunicorn: command not found
bash: gunicorn: command not found

This error occurs when gunicorn is missing from your app’s requirements.txt file. See App Structure
for more details on gunicorn and requirements.txt.

Could not find a version that satisfies the requirement

git push plotly main is successful, but the build fails and your build logs display something similar to

pip install failed:
ERROR: Could not find a version that satisfies the requirement dash==26.2 (from versions: 0.17.4, 0.17.5, 0.17.7, 0.17.8rc1, 0.17.8rc2, 0.17.8rc3, 0.18.0, 0.18.1, 0.18.2, 0.18.3rc1, 0.18.3, 0.19.0, 0.20.0, 0.21.0, 0.21.1, 0.22.0rc1, 0.22.0rc2, 0.22.0, 0.23.1, 0.24.0, 0.24.1rc1, 0.24.1, 0.24.2, 0.25.0, 0.25.1, 0.26.0, 0.26.1rc1, 0.26.1rc2, 0.26.1rc3, 0.26.1, 0.26.2, 0.26.3, 0.26.4, 0.26.5, 0.26.6, 0.27.0rc1, 0.27.0rc2, 0.27.0rc3, 0.27.0rc4, 0.27.0rc5, 0.27.0rc6, 0.27.0rc7, 0.27.0rc8, 0.27.0rc9, 0.27.0, 0.28.0, 0.28.1, 0.28.2, 0.28.3, 0.28.4, 0.28.5, 0.28.6, 0.28.7, 0.29.0rc1, 0.29.0rc2, 0.29.0rc3, 0.29.0rc4, 0.29.0rc5, 0.29.0rc6, 0.29rc7, 0.29.0rc8, 0.29.0, 0.30.0rc1, 0.30.0rc2, 0.30.0rc3, 0.30.0rc4, 0.30.0rc5, 0.30.0, 0.31.0rc1, 0.31.0rc2, 0.31.0, 0.31.1, 0.32.0rc1, 0.32.0rc2, 0.32.0, 0.32.1, 0.32.2, 0.34.0, 0.35.0rc1, 0.35.0, 0.35.1, 0.35.2, 0.35.3, 0.36.0rc1, 0.36.0, 0.37.0rc1, 0.37.0rc2, 0.37.0, 0.38.0rc1, 0.38.0, 0.39.0, 0.40.0rc1, 0.40.0, 0.41.0, 0.42.0, 0.43.0rc1, 0.43.0rc2, 0.43.0rc3, 0.43.0, 1.0.0a1, 1.0.0, 1.0.1rc1, 1.0.1, 1.0.2, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.4.0, 1.4.1, 1.5.0, 1.5.1, 1.6.0, 1.6.1, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.13.1, 1.13.2, 1.13.3, 1.13.4, 1.14.0, 1.15.0, 1.16.0, 1.16.1, 1.16.2, 1.16.3, 1.17.0, 1.18.0, 1.18.1, 1.19.0, 1.20.0, 1.21.0, 2.0.0rc1, 2.0.0rc2, 2.0.0rc3, 2.0.0, 2.1.0, 2.2.0, 2.3.0, 2.3.1, 2.4.0, 2.4.1, 2.5.0, 2.5.1, 2.6.0, 2.6.1, 2.6.2, 2.7.0)
ERROR: No matching distribution found for dash==26.2

error: exit status 1
ERROR: failed to build: exit status 1

This error can occur if there is a problem in
your requirements.txt file. To resolve, check the versioning in your
requirements.txt file. In the example above, the error occurred because
dash==26.2 is not a version of Dash.

If you’re working in a virtual environment,
you can check your package versions with:

$ pip list

if something in the list differs from your requirements.txt, you can update your requirements.txt with:

pip freeze > requirements.txt

See App Structure for more details on requirements.txt.

fatal: Authentication failed for https://<your-dash-enterprise-server>/GIT/<your-dash-app>/

$ git push plotly main
[...]
fatal: Authentication failed for 'https://<your-dash-enterprise-server>/GIT/<your-dash-app>/'

This error can occur when your administrator has configured Dash Enterprise authentication to
use SAML or OIDC and you are trying to deploy changes over HTTPS. When Dash Enterprise
is configured with SAML or OIDC, HTTPS deployments are not supported.
Resolve this by adding an SSH remote and deploying over SSH.

This error can also occur when you try to git clone an app that you own or co-own over HTTPS in a workspace. This is a known issue. To work around this
issue, you can delete the contents of the ~/.gitconfig file, then run git clone again and supply your Dash Enterprise credentials when prompted.

remote: Access denied

$ git push plotly main
[...]
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 5.18 KiB | 2.59 MiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)

remote: User <your-username> does not have permissions to run git-hook on <your-dash-app>, or <your-dash-app> does not exist
remote: Access denied
To <your-dash-enterprise-server>/GIT/<your-dash-app>
! [remote rejected] main -> main (pre-receive hook declined)

error: failed to push some refs to '<your-dash-enterprise-server>:<your-dash-app>'

$ git push plotly main
[...]
ssh: connect to host <your-dash-enterprise-server> port 22: Connection timed out

fatal: Could not read from remote repository.

Please make sure you have the correct access rights

and the repository exists.

If deploying over HTTPS, then this can occur if your username or password is incorrect. Note that usernames and passwords in Dash Enterprise are case sensitive; e.g. the username Chris.Parmer is different than the username chris.parmer.

Git can sometimes cache these usernames after you’ve typed them. Run git config credential.helper to verify and correct the username.

Also, some operating system’s password managers can cache usernames as well. Open your operating system’s password manager and verify the username and password if you are deploying with https, running into access denied errors, and Git isn’t asking you for your username and password.

Please make sure you have the correct access rights and the repository exists

$ git clone https:<your-dash-app>@//<your-dash-enterprise-server>/GIT/<your-dash-app>
Cloning into '<your-dash-app>'...
ssh: Could not resolve hostname https: Name or service not known
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

This error can occur if there is an error in the repository URL. In the example above, the
repository to be cloned over HTTPS should look like https://<your-dash-enterprise-server>/GIT/<your-dash-app>.

gunicorn: error: unrecognized arguments

git push plotly main is successful, but the deployment fails and your app logs display

[2022-11-10 00:41:09 +0000] [1] [INFO] Handling signal: term
[2022-11-10 00:41:09 +0000] [18] [INFO] Worker exiting (pid: 18)
[2022-11-10 00:41:09 +0000] [21] [INFO] Worker exiting (pid: 21)
[2022-11-10 00:41:09 +0000] [19] [INFO] Worker exiting (pid: 19)
[2022-11-10 00:41:09 +0000] [20] [INFO] Worker exiting (pid: 20)
[2022-11-10 00:41:10 +0000] [1] [INFO] Shutting down: Master
usage: gunicorn [OPTIONS] [APP_MODULE]
gunicorn: error: unrecognized arguments: --timout 2
usage: gunicorn [OPTIONS] [APP_MODULE]
gunicorn: error: unrecognized arguments: --timout 2
usage: gunicorn [OPTIONS] [APP_MODULE]
gunicorn: error: unrecognized arguments: --timout 2
usage: gunicorn [OPTIONS] [APP_MODULE]
gunicorn: error: unrecognized arguments: --timout 2

This error occurs when the web process defined in your Procfile has an invalid argument. In the example above, “timeout” is spelled incorrectly.

To resolve, verify the format and spelling of those arguments. See Gunicorn Docs on Settings for more details.

[CRITICAL] WORKER TIMEOUT

git push plotly main is successful, but the deployment fails and your app logs display something similar to

[2022-11-10 16:25:20 +0000] [4786] [INFO] Booting worker with pid: 4786
[2022-11-10 16:25:20 +0000] [4787] [INFO] Booting worker with pid: 4787
[2022-11-10 16:25:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:4770)
[2022-11-10 16:25:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:4771)
[2022-11-10 16:25:52 +0000] [4770] [INFO] Worker exiting (pid: 4770)
[2022-11-10 16:25:52 +0000] [4771] [INFO] Worker exiting (pid: 4771)
[2022-11-10 16:25:52 +0000] [4851] [INFO] Booting worker with pid: 4851
[2022-11-10 16:25:52 +0000] [4852] [INFO] Booting worker with pid: 4852
[2022-11-10 16:25:53 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:4786)
[2022-11-10 16:25:53 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:4787)
[2022-11-10 16:25:53 +0000] [4786] [INFO] Worker exiting (pid: 4786)
[2022-11-10 16:25:53 +0000] [4787] [INFO] Worker exiting (pid: 4787)

This can happen in the following scenarios:

• Your app takes longer than 30 seconds to start

In this scenario, the gunicorn web process does not have enough
time to complete its task during the booting process. By default,
gunicorn has a 30 second timeout. Workers silent for more than this
many seconds are killed and restarted.

To resolve, we recommend that you first use the --preload flag to reduce your
app’s memory consumption and speed up boot time. Avoid the --preload
flag if you are using shared database connection pools. See
Gunicorn docs on preloading
for more details.

«`
web: gunicorn app:server –workers 4 –preload

«`

Use the --timeout flag only if you cannot use the --preload flag.
--timeout allows you to modify the default amount of time available
for your workers to complete a task. See
Gunicorn docs on timeout
for details.

«`
web: gunicorn app:server –workers 4 –timeout 90

«`

• Your app’s callbacks take more than 30 seconds to finish

To resolve, consider using Background Callbacks.

fatal: Unable to create ‘.git/index.lock’: File exists

$ git add .
fatal: Unable to create '.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

This error can occur if you ran git commit -a in a different terminal. All Git commits create a .git/index.lock file temporarily, but the
git commit -a command does not terminate the Git process after doing so, preventing another process from creating the .git/index.lock file.

To resolve:

1. Run ps aux or ps aux |grep git to list running processes.
2. If you see a process with git commit -a as its COMMAND, make a note of its process ID (PID) and terminate it:
   ps kill <process-ID>
   where <process-ID> is the ID of the git commit -a process.
3. If you don’t see a process corresponding to git commit -a, manually delete the .git/index.lock file:
   rm .git/index.lock

Commit your changes with git commit -m "commit message" to avoid this error in the future.

I’m working on on a Flask app using Flask’s built in dev server. I start it using Flask-Script. I want to switch to using Gunicorn as the web server. To do so, do I need to write some sort of integration code between Flask-Script and Gunicorn? Or is Flask-Script irrelevant to running the app using Gunicorn?

Thanks in advance!

Props to @sean-lynch. The following is working, tested code based on his answer.
The changes I made were:

• Options that aren’t recognized by Gunicorn are removed from sys.argv in remove_non_gunicorn_command_line_args() before trying to start the server. Otherwise Gunicorn throws an error with a message like this: error: unrecognized arguments: --port 5010. I remove -p because, even though it doesn’t cause the error, that’s only because Gunicorn thinks its the short form of its pidfile option, which is obviously not what’s intended.

• GunicornServer.handle() signature modified to match the method it overrides i.e. Command.handle()

—

from flask_script import Command
from gunicorn.app.base import Application

class GunicornServer(Command):

    description = 'Run the app within Gunicorn'

    def __init__(self, host='127.0.0.1', port=8000, workers=6):

        self.port = port
        self.host = host
        self.workers = workers

    def get_options(self):
        return (
            Option('-t', '--host',
                   dest='host',
                   default=self.host),

            Option('-p', '--port',
                   dest='port',
                   type=int,
                   default=self.port),

            Option('-w', '--workers',
                   dest='workers',
                   type=int,
                   default=self.workers),
        )

    def handle(self, app, *args, **kwargs):

        host = kwargs['host']
        port = kwargs['port']
        workers = kwargs['workers']

        def remove_non_gunicorn_command_line_args():
            import sys
            args_to_remove = ['--port','-p']
            def args_filter(name_or_value):
                keep = not args_to_remove.count(name_or_value)
                if keep:
                    previous = sys.argv[sys.argv.index(name_or_value) - 1]
                    keep = not args_to_remove.count(previous)
                return keep
            sys.argv = filter(args_filter, sys.argv)

        remove_non_gunicorn_command_line_args()

        from gunicorn import version_info
        if version_info < (0, 9, 0):
            from gunicorn.arbiter import Arbiter
            from gunicorn.config import Config
            arbiter = Arbiter(Config({'bind': "%s:%d" % (host, int(port)),'workers': workers}), app)
            arbiter.run()
        else:
            class FlaskApplication(Application):
                def init(self, parser, opts, args):
                    return {
                        'bind': '{0}:{1}'.format(host, port),
                        'workers': workers
                    }

                def load(self):
                    return app

            FlaskApplication().run()

manager.add_command('gunicorn', GunicornServer())

this is my first flask app deployment

this my directory tree

/home/goku--
            |_ __pycache__
            |_ virbubble
            |_ flaskapp.py
            |_ wsgi.py

this is the flaskapp.py

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "<h1 style='color:blue'>Hello There!</h1>"

if __name__ == "__main__":
    app.run(host='0.0.0.0')

this is the wsgi.py

from flaskapp import app

if __name__ == "__main__":
    app.run()

I created the goku and added into nginx group

this is the /etc/nginx/conf.d/flaskapp.conf

server {
listen 5000;
server_name 'my IP';
location =/favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/goku;
}
location / {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $ remote-addr;
proxy_set_header Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://unix:/home/goku/flaskapp.sock
}
}

and this is the /etc/systemd/system/flaskapp.service

[Unit]
Description=gunicorn daemon
After=network.target

[Service]
User=goku
Group=nginx
WorkingDirectory=/home/goku
Environment=”PATH=/home/goku/virbubble/bin”
ExecStart= /home/goku/virbubble/bin/gunicorn -access-logfile - --workers 3 -bind unix:/home/goku/flaskapp.sock -m 007 wsgi:app

[Install]
WantedBy=multi-user.target

when I run [[email protected] ~]# sudo systemctl status flaskapp I got this :

● flaskapp.service — gunicorn daemon
Loaded: loaded (/etc/systemd/system/flaskapp.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sun 2022-03-06 13:05:05 UTC; 8min ago

Main PID: 27830 (code=exited, status=2)

Mar 06 13:05:05 localhost systemd[1]: Started gunicorn daemon.

Mar 06 13:05:05 localhost gunicorn[27830]: usage: gunicorn [OPTIONS] [APP_MODULE]

Mar 06 13:05:05 localhost gunicorn[27830]: gunicorn: error: unrecognized arguments: -access-logfile unix:/home/goku/flaskapp.sock wsgi:app

Mar 06 13:05:05 localhost systemd[1]: flaskapp.service: main process exited, code=exited, status=2/INVALIDARGUMENT

Mar 06 13:05:05 localhost systemd[1]: Unit flaskapp.service entered failed state.

Mar 06 13:05:05 localhost systemd[1]: flaskapp.service failed.

Mar 06 13:05:09 localhost systemd[1]: [114B blob data]

and I don’t have flaskapp.sock file

how can I fix this

Как сказал Дайват, вы можете просто использовать приложение Flask прямо с Gunicorn.

Если вы все еще хотите использовать Flask- Script, вам нужно создать пользовательский Command. У меня нет опыта с Gunicorn, но я нашел аналогичное решение для Flask-Actions и поместил его в Flask- Script, хотя следует предупредить, он не проверен.

from flask_script import Command, Option

class GunicornServer(Command):

    description = 'Run the app within Gunicorn'

    def __init__(self, host='127.0.0.1', port=8000, workers=4):
        self.port = port
        self.host = host
        self.workers = workers

    def get_options(self):
        return (
            Option('-H', '--host',
                   dest='host',
                   default=self.host),

            Option('-p', '--port',
                   dest='port',
                   type=int,
                   default=self.port),

            Option('-w', '--workers',
                   dest='workers',
                   type=int,
                   default=self.workers),
        )

    def handle(self, app, host, port, workers):

        from gunicorn import version_info

        if version_info < (0, 9, 0):
            from gunicorn.arbiter import Arbiter
            from gunicorn.config import Config
            arbiter = Arbiter(Config({'bind': "%s:%d" % (host, int(port)),'workers': workers}), app)
            arbiter.run()
        else:
            from gunicorn.app.base import Application

            class FlaskApplication(Application):
                def init(self, parser, opts, args):
                    return {
                        'bind': '{0}:{1}'.format(host, port),
                        'workers': workers 
                    }

                def load(self):
                    return app

            FlaskApplication().run()

Затем вы можете зарегистрировать его для замены Flask локального сервера разработки в python manage.py runserver

manager.add_command("runserver", GunicornServer())

или зарегистрируйтесь как новая команда, например python manage.py gunicorn

manager.add_command("gunicorn", GunicornServer())

Изменить июнь 2016. С помощью последней версии Flask- Script измените метод handle на __call__. старая фляжка script vs новая фляжка script