How to stop django server

PyDev and Django: how to restart dev server?

I’m new to Django. I think I’m making a simple mistake.

I launched the dev server with Pydev:

RClick on project >> Django >> Custom command >> runserver

The server came up, and everything was great. But now I’m trying to stop it, and can’t figure out how. I stopped the process in the PyDev console, and closed Eclipse, but web pages are still being served from http://127.0.0.1:8000.

I launched and quit the server from the command line normally:

But the server is still up. What am I doing wrong here?

7 Answers 7

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

By default, the runserver command runs in autoreload mode, which runs in a separate process. This means that PyDev doesn’t know how to stop it, and doesn’t display its output in the console window.

Run the project 1. Right click on the project (not subfolders) 2. Run As > Pydev:Django

Terminate 1. Click terminate in console window

The server is down

I usually run it from console. Running from PyDev adds unnecessary confusion, and doesn’t bring any benefit until you happen to use PyDev’s GUI interactive debugging.

Edit: Latest PyDev versions (since PyDev 3.4.1) no longer need any workaround:

i.e.: PyDev will properly kill subprocesses on a kill process operation and when debugging even with regular reloading on, PyDev will attach the debugger to the child processes.

Old answer (for PyDev versions older than 3.4.1):

Unfortunately, that’s expected, as PyDev will simply kill the parent process (i.e.: as if instead of ctrl+C you kill the parent process in the task manager).

The solution would be editing Django itself so that the child process polls the parent process to know it’s still alive and exit if it’s not. see: How to make child process die after parent exits? for a reference.

Documentation

django-admin and manage.py ¶

django-admin is Django’s command-line utility for administrative tasks. This document outlines all it can do.

In addition, manage.py is automatically created in each Django project. It does the same thing as django-admin but also sets the DJANGO_SETTINGS_MODULE environment variable so that it points to your project’s settings.py file.

Usage¶

Getting runtime help¶

Run django-admin help to display usage information and a list of the commands provided by each application.

Run django-admin help to display a description of the given command and a list of its available options.

App names¶

Determining the version¶

Run django-admin version to display the current Django version.

The output follows the schema described in PEP 440:

Displaying debug output¶

Available commands¶

check ¶

Uses the system check framework to inspect the entire Django project for common problems.

By default, all apps will be checked. You can check a subset of apps by providing a list of app labels as arguments:

Specifies the database to run checks requiring database access:

By default, these checks will not be run.

Lists all available tags.

Activates some additional checks that are only relevant in a deployment setting.

compilemessages ¶

Specifies the locale(s) to process. If not provided, all locales are processed.

Specifies the locale(s) to exclude from processing. If not provided, no locales are excluded.

Includes fuzzy translations into compiled files.

createcachetable ¶

Creates the cache tables for use with the database cache backend using the information from your settings file. See Django’s cache framework for more information.

Prints the SQL that would be run without actually running it, so you can customize it or use the migrations framework.

dbshell ¶

diffsettings ¶

The settings module to compare the current settings against. Leave empty to compare against Django’s default settings.

dumpdata ¶

Outputs to standard output all data in the database associated with the named application(s).

If no application name is provided, all installed applications will be dumped.

Note that dumpdata uses the default manager on the model for selecting the records to dump. If you’re using a custom manager as the default manager and it filters some of the available records, not all of the objects will be dumped.

Uses Django’s base manager, dumping records which might otherwise be filtered or modified by a custom manager.

Specifies the number of indentation spaces to use in the output. Defaults to None which displays all data on single line.

Prevents specific applications or models (specified in the form of app_label.ModelName ) from being dumped. If you specify a model name, then only that model will be excluded, rather than the entire application. You can also mix application names and model names.

Uses the natural_key() model method to serialize any foreign key and many-to-many relationship to objects of the type that defines the method. If you’re dumping contrib.auth Permission objects or contrib.contenttypes ContentType objects, you should probably use this flag. See the natural keys documentation for more details on this and the next option.

Omits the primary key in the serialized data of this object since it can be calculated during deserialization.

Outputs only the objects specified by a comma separated list of primary keys. This is only available when dumping one model. By default, all the records of the model are output.

Specifies a file to write the serialized data to. By default, the data goes to standard output.

Fixtures compression¶

flush ¶

Removes all data from the database and re-executes any post-synchronization handlers. The table of which migrations have been applied is not cleared.

If you would rather start from an empty database and rerun all migrations, you should drop and recreate the database and then run migrate instead.

Suppresses all user prompts.

inspectdb ¶

Introspects the database tables in the database pointed-to by the NAME setting and outputs a Django model module (a models.py file) to standard output.

Use this if you have a legacy database with which you’d like to use Django. The script will inspect the database and create a model for each table within it.

As you might expect, the created models will have an attribute for every field in the table. Note that inspectdb has a few special cases in its field-name output:

This feature is meant as a shortcut, not as definitive model generation. After you run it, you’ll want to look over the generated models yourself to make customizations. In particular, you’ll need to rearrange models’ order, so that models that refer to other models are ordered properly.

By default, inspectdb creates unmanaged models. That is, managed = False in the model’s Meta class tells Django not to manage each table’s creation, modification, and deletion. If you do want to allow Django to manage the table’s lifecycle, you’ll need to change the managed option to True (or remove it because True is its default value).

Database-specific notes¶

Oracle¶

PostgreSQL¶

If this option is provided, models are also created for partitions.

Only support for PostgreSQL is implemented.

If this option is provided, models are also created for database views.

loaddata ¶

Searches for and loads the contents of the named fixture into the database.

Ignores fields and models that may have been removed since the fixture was originally generated.

Specifies a single app to look for fixtures in rather than looking in all apps.

Excludes loading the fixtures from the given applications and/or models (in the form of app_label or app_label.ModelName ). Use the option multiple times to exclude more than one app or model.

What’s a “fixture”?¶

A fixture is a collection of files that contain the serialized contents of the database. Each fixture has a unique name, and the files that comprise the fixture can be distributed over multiple directories, in multiple applications.

Django will search in three locations for fixtures:

Django will load any and all fixtures it finds in these locations that match the provided fixture names.

If the named fixture has a file extension, only fixtures of that type will be loaded. For example:

If you omit the extensions, Django will search all available fixture types for a matching fixture. For example:

The fixtures that are named can include directory components. These directories will be included in the search path. For example:

When fixture files are processed, the data is saved to the database as is. Model defined save() methods are not called, and any pre_save or post_save signals will be called with raw=True since the instance only contains attributes that are local to the model. You may, for example, want to disable handlers that access related fields that aren’t present during fixture loading and would otherwise raise an exception:

You could also write a decorator to encapsulate this logic:

Note that the order in which fixture files are processed is undefined. However, all fixture data is installed as a single transaction, so data in one fixture can reference data in another fixture. If the database backend supports row-level constraints, these constraints will be checked at the end of the transaction.

Compressed fixtures¶

Note that if two fixtures with the same name but different fixture type are discovered (for example, if mydata.json and mydata.xml.gz were found in the same fixture directory), fixture installation will be aborted, and any data installed in the call to loaddata will be removed from the database.

MySQL with MyISAM and fixtures

The MyISAM storage engine of MySQL doesn’t support transactions or constraints, so if you use MyISAM, you won’t get validation of fixture data, or a rollback if multiple transaction files are found.

Database-specific fixtures¶

If you’re in a multi-database setup, you might have fixture data that you want to load onto one database, but not onto another. In this situation, you can add a database identifier into the names of your fixtures.

For example, if your DATABASES setting has a ‘users’ database defined, name the fixture mydata.users.json or mydata.users.json.gz and the fixture will only be loaded when you specify you want to load data into the users database.

Loading fixtures from stdin ¶

Loading from stdin is useful with standard input and output redirections. For example:

makemessages ¶

Runs over the entire source tree of the current directory and pulls out all strings marked for translation. It creates (or updates) a message file in the conf/locale (in the Django tree) or locale (for project and application) directory. After making changes to the messages files you need to compile them with compilemessages for use with the builtin gettext support. See the i18n documentation for details.

Updates the message files for all available languages.

Specifies the locale(s) to process.

Specifies the locale(s) to exclude from processing. If not provided, no locales are excluded.

Specifies the domain of the messages files. Supported options are:

Follows symlinks to directories when looking for new translation strings.

Disables breaking long message lines into several lines in language files.

Suppresses writing ‘ #: filename:line ’ comment lines in language files. Using this option makes it harder for technically skilled translators to understand each message’s context.

Controls #: filename:line comment lines in language files. If the option is:

Requires gettext 0.19 or newer.

makemigrations ¶

Suppresses all user prompts. If a suppressed prompt cannot be resolved automatically, the command will exit with error code 3.

Outputs an empty migration for the specified apps, for manual editing. This is for advanced users and should not be used unless you are familiar with the migration format, migration operations, and the dependencies between your migrations.

Enables fixing of migration conflicts.

Generate migration files without Django version and timestamp header.

Makes makemigrations exit with a non-zero status when model changes without migrations are detected.

migrate ¶

The behavior of this command changes depending on the arguments provided:

Marks the migrations up to the target one (following the rules above) as applied, but without actually running the SQL to change your database schema.

Allows Django to skip an app’s initial migration if all database tables with the names of all models created by all CreateModel operations in that migration already exist. This option is intended for use when first running migrations against a database that preexisted the use of migrations. This option does not, however, check for matching database schema beyond matching table names and so is only safe to use if you are confident that your existing schema matches what is recorded in your initial migration.

Shows the migration operations that will be performed for the given migrate command.

Allows creating tables for apps without migrations. While this isn’t recommended, the migrations framework is sometimes too slow on large projects with hundreds of models.

Suppresses all user prompts. An example prompt is asking about removing stale content types.

Makes migrate exit with a non-zero status when unapplied migrations are detected.

Deletes nonexistent migrations from the django_migrations table. This is useful when migration files replaced by a squashed migration have been removed. See Squashing migrations for more details.

optimizemigration ¶

Optimizes the operations for the named migration and overrides the existing file. If the migration contains functions that must be manually copied, the command creates a new migration file suffixed with _optimized that is meant to replace the named migration.

Makes optimizemigration exit with a non-zero status when a migration can be optimized.

runserver ¶

If you run this script as a user with normal privileges (recommended), you might not have access to start a port on a low port number. Low port numbers are reserved for the superuser (root).

This server uses the WSGI application object specified by the WSGI_APPLICATION setting.

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making web frameworks, not web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)

The development server automatically reloads Python code for each request, as needed. You don’t need to restart the server for code changes to take effect. However, some actions like adding files don’t trigger a restart, so you’ll have to restart the server in these cases.

If you’re using Linux or MacOS and install both pywatchman and the Watchman service, kernel signals will be used to autoreload the server (rather than polling file modification timestamps each second). This offers better performance on large projects, reduced response time after code changes, more robust change detection, and a reduction in power usage. Django supports pywatchman 1.2.0 and higher.

Large directories with many files may cause performance issues

The default timeout of Watchman client is 5 seconds. You can change it by setting the DJANGO_WATCHMAN_TIMEOUT environment variable.

You can run as many concurrent servers as you want, as long as they’re on separate ports by executing django-admin runserver more than once.

You can provide an IPv6 address surrounded by brackets (e.g. [200a::1]:8000 ). This will automatically enable IPv6 support.

A hostname containing ASCII-only characters can also be used.

If the staticfiles contrib app is enabled (default in new projects) the runserver command will be overridden with its own runserver command.

Logging of each request and response of the server is sent to the django.server logger.

Disables the auto-reloader. This means any Python code changes you make while the server is running will not take effect if the particular Python modules have already been loaded into memory.

Disables use of threading in the development server. The server is multithreaded by default.

django-admin and manage.py — Django documentation

Contents

django-admin and manage.py

django-admin is Django’s command-line utility for administrative tasks. This document outlines all it can do.

In addition, manage.py is automatically created in each Django project. It does the same thing as django-admin but also sets the DJANGO_SETTINGS_MODULE environment variable so that it points to your project’s settings.py file.

Usage

Getting runtime help

Run django-admin help to display usage information and a list of the commands provided by each application.

Run django-admin help to display a description of the given command and a list of its available options.

App names

Determining the version

Run django-admin version to display the current Django version.

The output follows the schema described in PEP 440:

Displaying debug output

Available commands

check

Uses the system check framework to inspect the entire Django project for common problems.

By default, all apps will be checked. You can check a subset of apps by providing a list of app labels as arguments:

The system check framework performs many different types of checks that are categorized with tags. You can use these tags to restrict the checks performed to just those in a particular category. For example, to perform only models and compatibility checks, run:

New in version 3.1.

Specifies the database to run checks requiring database access:

By default, these checks will not be run.

Lists all available tags.

Activates some additional checks that are only relevant in a deployment setting.

compilemessages

Specifies the locale(s) to process. If not provided, all locales are processed.

Specifies the locale(s) to exclude from processing. If not provided, no locales are excluded.

Includes fuzzy translations into compiled files.

New in version 3.0.

createcachetable

Creates the cache tables for use with the database cache backend using the information from your settings file. See Django’s cache framework for more information.

Prints the SQL that would be run without actually running it, so you can customize it or use the migrations framework.

dbshell

Runs the command-line client for the database engine specified in your :setting:`ENGINE ` setting, with the connection parameters specified in your :setting:`USER`, :setting:`PASSWORD`, etc., settings.

New in version 3.1.

diffsettings

The settings module to compare the current settings against. Leave empty to compare against Django’s default settings.

dumpdata

Outputs to standard output all data in the database associated with the named application(s).

If no application name is provided, all installed applications will be dumped.

The output of dumpdata can be used as input for :djadmin:`loaddata`.

Note that dumpdata uses the default manager on the model for selecting the records to dump. If you’re using a custom manager as the default manager and it filters some of the available records, not all of the objects will be dumped.

Uses Django’s base manager, dumping records which might otherwise be filtered or modified by a custom manager.

Specifies the serialization format of the output. Defaults to JSON. Supported formats are listed in Serialization formats.

Specifies the number of indentation spaces to use in the output. Defaults to None which displays all data on single line.

Prevents specific applications or models (specified in the form of app_label.ModelName ) from being dumped. If you specify a model name, then only that model will be excluded, rather than the entire application. You can also mix application names and model names.

Uses the natural_key() model method to serialize any foreign key and many-to-many relationship to objects of the type that defines the method. If you’re dumping contrib.auth Permission objects or contrib.contenttypes ContentType objects, you should probably use this flag. See the natural keys documentation for more details on this and the next option.

Omits the primary key in the serialized data of this object since it can be calculated during deserialization.

Outputs only the objects specified by a comma separated list of primary keys. This is only available when dumping one model. By default, all the records of the model are output.

Specifies a file to write the serialized data to. By default, the data goes to standard output.

flush

Removes all data from the database and re-executes any post-synchronization handlers. The table of which migrations have been applied is not cleared.

If you would rather start from an empty database and re-run all migrations, you should drop and recreate the database and then run :djadmin:`migrate` instead.

Suppresses all user prompts.

inspectdb

Introspects the database tables in the database pointed-to by the :setting:`NAME` setting and outputs a Django model module (a models.py file) to standard output.

Use this if you have a legacy database with which you’d like to use Django. The script will inspect the database and create a model for each table within it.

As you might expect, the created models will have an attribute for every field in the table. Note that inspectdb has a few special cases in its field-name output:

This feature is meant as a shortcut, not as definitive model generation. After you run it, you’ll want to look over the generated models yourself to make customizations. In particular, you’ll need to rearrange models’ order, so that models that refer to other models are ordered properly.

By default, inspectdb creates unmanaged models. That is, managed = False in the model’s Meta class tells Django not to manage each table’s creation, modification, and deletion. If you do want to allow Django to manage the table’s lifecycle, you’ll need to change the managed option to True (or remove it because True is its default value).

Database-specific notes

Oracle

PostgreSQL

If this option is provided, models are also created for partitions.

Only support for PostgreSQL is implemented.

If this option is provided, models are also created for database views.

loaddata

Searches for and loads the contents of the named fixture into the database.

Ignores fields and models that may have been removed since the fixture was originally generated.

Specifies a single app to look for fixtures in rather than looking in all apps.

Specifies the serialization format (e.g., json or xml ) for fixtures read from stdin.

Excludes loading the fixtures from the given applications and/or models (in the form of app_label or app_label.ModelName ). Use the option multiple times to exclude more than one app or model.

What’s a “fixture”?

A fixture is a collection of files that contain the serialized contents of the database. Each fixture has a unique name, and the files that comprise the fixture can be distributed over multiple directories, in multiple applications.

Django will search in three locations for fixtures:

Django will load any and all fixtures it finds in these locations that match the provided fixture names.

If the named fixture has a file extension, only fixtures of that type will be loaded. For example:

If you omit the extensions, Django will search all available fixture types for a matching fixture. For example:

The fixtures that are named can include directory components. These directories will be included in the search path. For example:

When fixture files are processed, the data is saved to the database as is. Model defined save() methods are not called, and any pre_save or post_save signals will be called with raw=True since the instance only contains attributes that are local to the model. You may, for example, want to disable handlers that access related fields that aren’t present during fixture loading and would otherwise raise an exception:

You could also write a decorator to encapsulate this logic:

Note that the order in which fixture files are processed is undefined. However, all fixture data is installed as a single transaction, so data in one fixture can reference data in another fixture. If the database backend supports row-level constraints, these constraints will be checked at the end of the transaction.

Compressed fixtures

Note that if two fixtures with the same name but different fixture type are discovered (for example, if mydata.json and mydata.xml.gz were found in the same fixture directory), fixture installation will be aborted, and any data installed in the call to loaddata will be removed from the database.

MySQL with MyISAM and fixtures

The MyISAM storage engine of MySQL doesn’t support transactions or constraints, so if you use MyISAM, you won’t get validation of fixture data, or a rollback if multiple transaction files are found.

Database-specific fixtures

If you’re in a multi-database setup, you might have fixture data that you want to load onto one database, but not onto another. In this situation, you can add a database identifier into the names of your fixtures.

For example, if your :setting:`DATABASES` setting has a ‘master’ database defined, name the fixture mydata.master.json or mydata.master.json.gz and the fixture will only be loaded when you specify you want to load data into the master database.

Loading fixtures from stdin

Loading from stdin is useful with standard input and output redirections. For example:

makemessages

Runs over the entire source tree of the current directory and pulls out all strings marked for translation. It creates (or updates) a message file in the conf/locale (in the Django tree) or locale (for project and application) directory. After making changes to the messages files you need to compile them with :djadmin:`compilemessages` for use with the builtin gettext support. See the i18n documentation for details.

This command doesn’t require configured settings. However, when settings aren’t configured, the command can’t ignore the :setting:`MEDIA_ROOT` and :setting:`STATIC_ROOT` directories or include :setting:`LOCALE_PATHS`.

Updates the message files for all available languages.

Specifies the locale(s) to process.

Specifies the locale(s) to exclude from processing. If not provided, no locales are excluded.

Specifies the domain of the messages files. Supported options are:

Follows symlinks to directories when looking for new translation strings.

Disables breaking long message lines into several lines in language files.

Suppresses writing ‘ #: filename:line ’ comment lines in language files. Using this option makes it harder for technically skilled translators to understand each message’s context.

Controls #: filename:line comment lines in language files. If the option is:

Requires gettext 0.19 or newer.

makemigrations

Creates new migrations based on the changes detected to your models. Migrations, their relationship with apps and more are covered in depth in the migrations documentation.

Suppresses all user prompts. If a suppressed prompt cannot be resolved automatically, the command will exit with error code 3.

Outputs an empty migration for the specified apps, for manual editing. This is for advanced users and should not be used unless you are familiar with the migration format, migration operations, and the dependencies between your migrations.

Enables fixing of migration conflicts.

Generate migration files without Django version and timestamp header.

Makes makemigrations exit with a non-zero status when model changes without migrations are detected.

migrate

Synchronizes the database state with the current set of models and migrations. Migrations, their relationship with apps and more are covered in depth in the migrations documentation.

The behavior of this command changes depending on the arguments provided:

Marks the migrations up to the target one (following the rules above) as applied, but without actually running the SQL to change your database schema.

Allows Django to skip an app’s initial migration if all database tables with the names of all models created by all CreateModel operations in that migration already exist. This option is intended for use when first running migrations against a database that preexisted the use of migrations. This option does not, however, check for matching database schema beyond matching table names and so is only safe to use if you are confident that your existing schema matches what is recorded in your initial migration.

Shows the migration operations that will be performed for the given migrate command.

Allows creating tables for apps without migrations. While this isn’t recommended, the migrations framework is sometimes too slow on large projects with hundreds of models.

Suppresses all user prompts. An example prompt is asking about removing stale content types.

New in version 3.1.

Makes migrate exit with a non-zero status when unapplied migrations are detected.

runserver

If you run this script as a user with normal privileges (recommended), you might not have access to start a port on a low port number. Low port numbers are reserved for the superuser (root).

This server uses the WSGI application object specified by the :setting:`WSGI_APPLICATION` setting.

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)

The development server automatically reloads Python code for each request, as needed. You don’t need to restart the server for code changes to take effect. However, some actions like adding files don’t trigger a restart, so you’ll have to restart the server in these cases.

If you’re using Linux or MacOS and install both pywatchman and the Watchman service, kernel signals will be used to autoreload the server (rather than polling file modification timestamps each second). This offers better performance on large projects, reduced response time after code changes, more robust change detection, and a reduction in power usage. Django supports pywatchman 1.2.0 and higher.

Large directories with many files may cause performance issues

The default timeout of Watchman client is 5 seconds. You can change it by setting the DJANGO_WATCHMAN_TIMEOUT environment variable.

When you start the server, and each time you change Python code while the server is running, the system check framework will check your entire Django project for some common errors (see the :djadmin:`check` command). If any errors are found, they will be printed to standard output.

You can run as many concurrent servers as you want, as long as they’re on separate ports by executing django-admin runserver more than once.

You can provide an IPv6 address surrounded by brackets (e.g. [200a::1]:8000 ). This will automatically enable IPv6 support.

A hostname containing ASCII-only characters can also be used.

If the staticfiles contrib app is enabled (default in new projects) the :djadmin:`runserver` command will be overridden with its own runserver command.

Logging of each request and response of the server is sent to the django.server logger.

Disables the auto-reloader. This means any Python code changes you make while the server is running will not take effect if the particular Python modules have already been loaded into memory.

Disables use of threading in the development server. The server is multithreaded by default.

How to stop gunicorn properly

Note: I have a semi-automated server deployment with fabric. Thus using something like ps aux | grep gunicorn to kill the process manually by pid is not an option.

10 Answers 10

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

One option would be to use Supervisor to manage Gunicorn.

Something like this should work:

should kill all running gunicorn processes

pkill gunicorn stops all gunicorn daemons. So if you are running multiple instances of gunicorn with different ports, try this shell script.

Here is the command which worked for me :

It will kill any process with the name gunicorn

I have used PID_FILE for simplicity but you should use something like /tmp/MY_APP_PID as file name.

If the PID file exists it means the service is running. If it is not there, the service is not running. To stop the service just kill it as mentioned.

again but when I ran

it needed to first terminate my database as well as my EC2 instance, cloudwatch alarm etc. Is there any way for me to restart the DJango process so that it can update the URLS.py file without me having to run

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

You do not need to stop and start your environment. From what I understand you need to update your environment with your updated source code. Did you try git commit folloed by git aws.push? Take a look here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-reference-get-started.html

Let me know if you run into any issues with git aws.push.

You can also try restart app server on your environment using aws cli: http://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/restart-app-server.html But as far as I can tell, git aws.push will suffice.

I’ve had troubles with my Django files not updating after using:

The eb cli tool does not have a restart command, however you can login to the AWS console and restart your environment through the actions menu on the dashboard for your eb environment.

This generally fixes any issues that I have. However sometimes I’ve had to ssh directly into the instance and enable debugging through the settings.

The other command that Rohit referenced is from a different aws cli tool. I haven’t personally tried it but here is more documentation on the command and how to install it: