More server configuration options
The Odoo server supports quite a few other options. We can check all the available options with --help
:
$ ./odoo-bin --help
We will review some of the most important options in the following sections. Let's start by looking at how the currently active options can be saved in a configuration file.
Odoo server configuration files
Most of the options can be saved in a configuration file. By default, Odoo will use the .odoorc
file in your home directory. In Linux systems its default location is in the home
directory ($HOME
), and in the Windows distribution it is in the same directory as the executable used to launch Odoo.
Note
In previous Odoo/OpenERP versions, the name for the default configuration file was .openerp-serverrc
. For backward compatibility, Odoo 10 will still use this if it's present and no .odoorc
file is found.
On a clean install, the .odoorc
configuration file is not automatically created. We should use the --save
option to create the default configuration file, if it doesn't exist yet, and store the current instance configuration into it:
$ ~/odoo-dev/odoo/odoo-bin --save --stop-after-init #save configuration to file
Here, we also used the --stop-after-init
option to stop the server after it finishes its actions. This option is often used when running tests or asking to run a module upgrade to check whether it is installed correctly.
Now we can inspect what was saved in this default configuration file:
$ more ~/.odoorc # show the configuration file
This will show all the configuration options available with their default values. Editing them will be effective the next time you start an Odoo instance. Type q
to quit and go back to the prompt.
We can also choose to use a specific configuration file, using the --conf=<filepath>
option. Configuration files don't need to have all those options you've just seen. Only the ones that actually change a default value need to be there.
Changing the listening port
The --xmlrpc-port=<port>
command option allows us to change the listening port of a server instance from the default 8069. This can be used to run more than one instance at the same time, on the same machine.
Let's try this out. Open two terminal windows. On the first, run this:
$ ~/odoo-dev/odoo/odoo-bin --xmlrpc-port=8070
Run the following command on the second terminal:
$ ~/odoo-dev/odoo/odoo-bin --xmlrpc-port=8071
There you go: two Odoo instances on the same server listening on different ports! The two instances can use the same or different databases, depending on the configuration parameters used. And the two could be running the same or different versions of Odoo.
The database filter option
When developing with Odoo, it is frequent to work with several databases, and sometimes even with different Odoo versions. Stopping and starting different server instances on the same port, and switching between different databases, can cause web client sessions to behave improperly.
Accessing our instance using a browser window running in private mode can help avoiding some of these problems.
Another good practice is to enable a database filter on the server instance to ensure that it only allows requests for the database we want to work with, ignoring all others. This is done with the --db-filter
option. It accepts a regular expression to be used as a filter for the valid database names. To match an exact name, the expression should begin with a ^
and end with $
.
For example, to allow only the demo
database we would use this command:
$ ~/odoo-dev/odoo/odoo-bin --db-filter=^demo$
Managing server log messages
The --log-level
option allows us to set the log verbosity. This can be very useful to understand what is going on in the server. For example, to enable the debug log level, use
--log-level=debug
option.
The following log levels can be particularly interesting:
debug_sql
to inspect SQL queries generated by the serverdebug_rpc
to detail the requests received by the serverdebug_rpc_answer
to detail the responses sent by the server
By default, the log output is directed to standard output (your console screen), but it can be directed to a log file with the --logfile=<filepath>
option.
Finally, the --dev=all
option will bring up the Python debugger (pdb
) when an exception is raised. It's useful to do a post-mortem analysis of a server error. Note that it doesn't have any effect on the logger verbosity. More details on the Python debugger commands can be found at
https://docs.python.org/2/library/pdb.html#debugger-commands
.