Ctrl+K

How to start the server

How to start the server#

Web service#

You can start the default web server bundled in trytond with this command line:

$ trytond -c <config file>

The server will wait for client connections on the interface defined in the web section of the configuration.

Note

When using multiple config files the order is important as last entered files will override the items of first files

Warning

This runs the of Werkzeug development server which should not be used on production systems.

WSGI server#

If you prefer to run Tryton inside your own WSGI server instead of the simple server of Werkzeug, you can use the application trytond.application.app. Following environment variables can be set:

  • TRYTOND_CONFIG: Point to configuration file.

  • TRYTOND_LOGGING_CONFIG: Point to logging file.

  • TRYTOND_LOGGING_LEVEL: An integer to set the default logging level (default: ERROR).

  • TRYTOND_COROUTINE: Use coroutine for concurrency.

  • TRYTOND_DATABASE_NAMES: A list of database names in CSV format, using python default dialect.

Warning

You must manage to serve the static files from the web root.

Coroutine server#

The Werkzeug server uses thread for concurrency. This is not optimal for the long-polling request on the bus as each client consumes permanently one thread. You can start the server with coroutine using the option --coroutine.

Note

This will use the pure-Python, gevent-friendly WSGI server.

Cron service#

If you want to run some scheduled actions, you must also run the cron server with this command line:

$ trytond-cron -c <config file> -d <database>

The server will wake up every minutes and preform the scheduled actions defined in the database. You can also launch the command every few minutes from a scheduler with the option --once.

Worker service#

If you want to use a pool of workers to run asynchronously some tasks, you must activate the worker in the queue section of the configuration and run the worker manager with this command line:

$ trytond-worker -c <config file> -d <database>

The manager will dispatch tasks from the queue to a pool of worker processes.

Services options#

You will find more options for those services by using --help arguments.

Contents