Skip to Content

PMISuite 18 runtime and update services

pmisuite18.service starts Odoo normally. It does not update repositories, deploy translation files, activate languages, or upgrade databases. A restart must not implicitly run -u all.

pmisuite18-update.service is a separate, manually started database upgrade service. It stops pmisuite18.service before running and leaves it stopped afterward, whether the upgrade succeeds or fails.

pmisuite18-update-modules.service uses the same maintenance lifecycle but installs and upgrades explicit module lists instead of upgrading all installed modules. Odoo may also install dependencies and auto-install modules or upgrade affected dependent modules.

Prepare and install

Run these steps as a server administrator during an approved maintenance window. Editing this repository does not install or change a running service.

  1. Check the template against the target host: - The pmisuite18 user and pmiverse group must already exist. - The instance is /srv/pmiverse/_pmisuite18; its venv/bin/python must have the Odoo dependencies installed. No virtualenv activation is needed. - Odoo is at repos/OCB/odoo-bin. Match this path and the configuration's addons_path to the target host's repository layout. - The instance configuration is config/pmisuite18.conf. The separate configuration template is a starting point, not a production-ready configuration. Review credentials, database connection/filter, addons, proxy, ports, and worker settings. - Replace --database=example_database with the intended database name or comma-separated database list. Do not install the placeholder unchanged. This selects databases; review dbfilter separately for HTTP routing. - The unit's --load explicitly selects server-wide modules. All listed addons must be available on addons_path; adapt this list for the host. Command-line options override their corresponding configuration settings. - The service account needs read access to code/configuration and write access to the configured data_dir and data/log/ directory. The latter must exist for the explicit --logfile path used by this unit. Do not recursively change ownership of the repositories. - Requires=postgresql.service pulls in local PostgreSQL and couples the service lifecycle to it. Ordering does not guarantee database readiness. For remote PostgreSQL, remove that requirement and its After entry; use Wants=network-online.target and After=network-online.target instead. - Shutdown allows 300 seconds before remaining processes are killed. Increase TimeoutStopSec if the workload requires a longer graceful shutdown.
  2. Prepare and validate a host-specific copy (verification does not start Odoo):
unit_dir=$(mktemp -d)
cp /srv/pmiverse/_pmiconfig/templates/systemd/odoo18/pmisuite18.service "$unit_dir/"
"${EDITOR:-vi}" "$unit_dir/pmisuite18.service"
systemd-analyze verify "$unit_dir/pmisuite18.service"
  1. Resolve verification errors before continuing. If a unit already exists, inspect systemctl cat pmisuite18.service, including drop-ins, and preserve host-specific settings before replacing it. Then install the reviewed copy:
sudo install -m 0644 "$unit_dir/pmisuite18.service" /etc/systemd/system/pmisuite18.service
sudo systemctl daemon-reload
sudo systemctl enable pmisuite18.service
sudo systemctl restart pmisuite18.service
sudo systemctl status pmisuite18.service --no-pager
sudo journalctl -u pmisuite18.service -n 100 --no-pager

restart also starts an inactive service. Standard output goes to the journal and console, and standard error goes to the journal. Odoo application logs go to /srv/pmiverse/_pmisuite18/data/log/pmisuite.log via --logfile.

Repository and translation maintenance

Install the update service once

Prepare a host-specific copy of pmisuite18-update.service using the same copy/edit/verify procedure as the runtime unit. Match the paths, account/group, PostgreSQL dependency, and --load list to the runtime service. Replace example_database with the explicit database name or comma-separated list to upgrade. Ensure the service account can write data/log/pmiupgrade18.log. Inspect any existing update unit and drop-ins before replacing them.

Both upgrade templates require /usr/bin/flock (util-linux) and use the same lock file in the instance's writable data/ directory. Keep that path identical in both installed units. An overlapping run fails immediately without launching Odoo; it does not cancel the upgrade already running. Never delete the lock file to bypass contention. This protects only commands using this lock, not other instances or manual upgrades. Install the revised full-update unit as well when adding the selected-module unit so both participate in locking.

After reviewing and verifying the copy in $unit_dir:

sudo install -m 0644 "$unit_dir/pmisuite18-update.service" /etc/systemd/system/pmisuite18-update.service
sudo systemctl daemon-reload

Do not enable this unit at boot. It deliberately has no [Install] section, does not retry failures, and has no startup time limit. If replacing a previously enabled update unit, disable its boot activation during installation with sudo systemctl disable pmisuite18-update.service (use the old unit name if different). Do not leave another update service enabled alongside this one.

The update command adds --i18n-overwrite to reload existing translations and --no-http to avoid serving requests. It omits --dev=assets: development asset mode is not needed for module upgrades or translation imports.

Run an update

No Odoo web login is needed. Run these steps from the server command line.

  1. Confirm the explicit database list and a usable backup/recovery plan.
  2. Stop the service with sudo systemctl stop pmisuite18.service before changing runtime repositories or deployed translations. Stop any other Odoo processes serving the same databases too. Explicit stops do not trigger Restart.
  3. Update the repositories and deploy the built i18n_extra files. Follow the pmis-i18n-extra repository README for synchronization and deployment.
  4. Start the update service and wait for the command to finish:
sudo systemctl start pmisuite18-update.service
sudo systemctl show pmisuite18-update.service -p Result -p ExecMainStatus
sudo tail -n 100 /srv/pmiverse/_pmisuite18/data/log/pmiupgrade18.log

Expect Result=success and ExecMainStatus=0, and check the upgrade log. A successful oneshot returns to inactive (dead); that alone is not a failure. For startup failures, also check sudo journalctl -u pmisuite18-update.service -n 100 --no-pager. Do not start the runtime service while the update is running: the units conflict, so doing that would stop the update. This interlock covers only pmisuite18.service, not other instances or manually launched Odoo processes.

This upgrades installed modules and reloads active languages, overwriting existing ordinary translated terms. To also activate Slovenian and Italian, add --load-language=sl_SI,it_IT to the update unit's ExecStart and run sudo systemctl daemon-reload before starting it. Do so only if every listed database should receive both languages; otherwise use separately targeted runs. Remove the option and reload after activation. This is not a full cleanup of retired overrides; use the translation project's reconciliation instructions for those cases. 5. Only after every database upgrade succeeds, run sudo systemctl start pmisuite18.service and check status/logs as above. If any upgrade fails, leave the service stopped and investigate; restarting is not a recovery procedure.

Install and upgrade selected modules

Install pmisuite18-update-modules.service using the same copy/edit/verify/install procedure as the full-update unit; do not enable it at boot. In its host-specific copy, set --database, replace --init=example_new_module with the comma-separated list of modules to install, and replace --update=example_module with the list of installed modules to upgrade. Remove either option when not needed; do not leave unused placeholders in the command. Match the runtime --load list and ensure data/log/pmiupgrade18-modules.log is writable by the service account. Run sudo systemctl daemon-reload after changing the installed unit.

Follow the same backup, runtime-stop, repository-update, and translation-deploy steps above, then use this unit instead of the full-update unit:

sudo systemctl start pmisuite18-update-modules.service
sudo systemctl show pmisuite18-update-modules.service -p Result -p ExecMainStatus
sudo tail -n 100 /srv/pmiverse/_pmisuite18/data/log/pmiupgrade18-modules.log

Check for success and inspect the log before starting pmisuite18.service again. On failure, leave the runtime stopped and investigate; also check the unit's journal. Lock contention produces a failed run without a new Odoo upgrade log. Do not run both upgrade services concurrently. Selected-module updates do not reload translations for all unrelated installed modules; use the full-update service when deploying corrections across the instance.

Choosing installation and upgrade targets

--init=example_new_module (-i) installs a module; --update=example_module (-u) upgrades an installed module. An invocation with -i ... -u all installs the requested module and upgrades all installed modules; it is not a targeted upgrade.

The template includes both options. For installation only, remove --update; for upgrade only, remove --init. To install modules and upgrade everything, set --init to the installation list and --update=all. Review dependencies and auto-install effects before running. Remove completed installation targets from the installed unit before reusing it, and reload systemd after every unit change.