Ten Non-Obvious Traps When Migrating from Odoo 18 to Odoo 19 CE and the systemd-logind Incident

Every major version migration in enterprise software promises performance leaps, modernized interfaces, and streamlined APIs. Upgrading from Odoo 18.0 to Odoo 19.0 Community Edition delivers undeniable architectural improvements: the elimination of legacy web client views, modernized Chart.js integration, unified row-level security checks, and high-performance aggregate queries.

However, beneath the surface of the official release notes lies a treacherous minefield of breaking ORM changes, silent compilation failures, and low-level Linux kernel interactions. Over a six-month migration campaign across production cloud environments, our infrastructure engineering team encountered and remediated a series of subtle failures. Several of these issues do not log clear stack traces; instead, they cause silent data corruption, bypass financial price constraints during ORM flushes, corrupt Cyrillic and Romanian PDF invoices, or crash the database engine entirely.

This lab report details our forensic investigation into the root causes of these failures, provides executable remediation scripts, and catalogs the ten most dangerous silent traps in the Odoo 19 ORM.

Kernel-Level Forensics of systemd-logind Shared Memory Purges (UID 1001)

The most catastrophic failure we encountered during Odoo 19 deployments on modern Linux (Debian 12 / Ubuntu 24.04) did not originate in Python code. It occurred at the interface between the Linux systemd-logind daemon and PostgreSQL's shared memory architecture.

The Phenomenon

Without warning, a production PostgreSQL instance running alongside Odoo would crash with the following fatal error:

Simultaneously, every active Odoo HTTP worker, websocket connection, and background cron thread would throw psycopg2.OperationalError: server closed the connection unexpectedly.

Forensic Root Cause

In enterprise cloud images (such as Bitnami Odoo appliances), non-root service accounts are frequently provisioned starting at UID 1000. On these appliances:

• User bitnami is assigned UID 1000.
• User postgres is assigned UID 1001.

Under systemd's design philosophy, any user ID ≥1000 (governed by SYS_UID_MAX in /etc/login.defs) is classified as an interactive human user, rather than a system daemon service (which typically occupy UIDs 100…999).

In Debian 12, /etc/systemd/logind.conf ships with the default configuration parameter:

Per systemd documentation, when RemoveIPC=yes is set, systemd-logind aggressively purges all System V IPC semaphores and POSIX shared memory segments (/dev/shm/*) belonging to a user when their last interactive session closes (user_stop()).

Whenever an automated script, cron job, or operator opened an SSH shell or executed a command via sudo -u postgres or su - postgres, systemd-logind created a temporary user session. The moment that shell or remote execution closed, logind executed clean_ipc_by_uid(1001). In doing so, it unlinked /dev/shm/PostgreSQL.* and wiped the active lock table semaphores that PostgreSQL relies on for inter-process communication between the postmaster and its client backends. The PostgreSQL master daemon immediately panics and restarts.

Setting RemoveIPC=no prevents logind from unlinking IPC memory on user logout, permanently eliminating shared memory eviction.

Ten Silent ORM Traps in Odoo 19

Migrating custom modules from Odoo 18 to Odoo 19 is not simply a matter of bumping __manifest__.py. The Odoo core development team introduced several breaking architectural changes that fail silently without halting server execution.

Ignored _sql_constraints Declarations

In Odoo 18, database constraints were declared as a list of tuples:

In Odoo 19, declaring _sql_constraints merely logs a deprecation warning. The ORM does not execute the underlying ALTER TABLE ADD CONSTRAINT statement. If an organization relies on this declaration for data integrity (e.g., unique VAT numbers, serial numbers, or transaction tokens), the database will silently accept duplicate entries.

In Odoo 19, developers must declare constraints as class-level attributes using models.Constraint:

List _inherit = ['model'] Without _name Converting to AbstractModel

In Odoo 18, writing _inherit = ['sale.order'] or _inherit = 'sale.order' without specifying _name worked interchangeably to extend a model in-place. In Odoo 19, if _inherit is passed as a Python list without _name, the model registry compiler silently treats the class as an AbstractModel. The model will not extend the database table, new fields will not be created, and subsequent views referencing those fields will fail with Field does not exist.

Always use a single string _inherit = 'sale.order' when extending models in-place.

Deprecation of read_group() in Favor of _read_group()

In Odoo 18, analytical summaries frequently invoked self.env['account.move.line'].read_group(domain, fields, groupby). In Odoo 19, read_group() is deprecated in favor of _read_group(), which returns raw SQL tuples rather than loosely-typed dictionaries, providing substantial memory savings:

@api.constrains Flushing Under self.env.su == True

In Odoo 19, when a record is created or modified through complex business workflows (such as checking out a point-of-sale order or confirming a sale), computed stored fields trigger a recomputation flush at the end of the transaction. During this flush phase, the environment is elevated to superuser (self.env.su == True).

If a developer wrote a validation constraint with a common shortcut:

The constraint will be silently bypassed during bulk operations and automated confirmation workflows, allowing unauthorized discounts into the ledger.

Role-dependent commercial guardrails must be validated explicitly inside create() and write() methods where self.env.user reflects the real operator, while @api.constrains must enforce invariant mathematical bounds regardless of su.

sale.order.line.product_uom Renamed to product_uom_id

In Odoo 19, the legacy field product_uom on sale.order.line was formally renamed to standard relational nomenclature: product_uom_id. Custom QWeb PDF templates, automated actions, or Python integrations that access line.product_uom.name will raise an immediate AttributeError.

@api.returns Removed from ORM

The legacy decorator @api.returns('model.name') has been completely deleted from Odoo 19. Any legacy codebase retaining this decorator will fail to import with AttributeError: module 'odoo.api' has no attribute 'returns'.

check_access_rights() and check_access_rule() Unified into check_access()

In Odoo 19, the fragmented security API has been consolidated. Calling record.check_access_rights('read') is deprecated. Security audits must use:

which validates both Model ACLs (ir.model.access) and Record Rules (ir.rule) in a single pass.

Translation CLI Migration (--i18n-export Removed)

Running the legacy command odoo-bin --i18n-export=file.po fails on Odoo 19. The translation engine has moved to dedicated subcommands:

In addition, in Odoo 19, fuzzy translation entries (#, fuzzy in .po files) are now actively loaded into the database, whereas Odoo 18 silently ignored them.

wkhtmltopdf Cyrillic & Romanian Diacritic Fallback Trap

By default, Odoo sets res.company.font = 'Lato'. The bundled font /opt/bitnami/odoo/lib/odoo/addons/web/static/fonts/lato/Lato-Reg-webfont.ttf (53 KB) contains only Basic Latin characters (U+0020–00FF). It completely lacks Russian Cyrillic (U+0400–04FF) and Romanian comma-below diacritics (Ș, ș, Ț, ț U+0218–021B, Ă, ă U+0102–0103).

When generating PDF invoices, wkhtmltopdf renders ASCII letters in Lato, but mid-word encounters ș or Cyrillic characters and abruptly substitutes them with the system fallback font DejaVu Sans. The result is severe typographical degradation: inconsistent glyph heights, distorted character spacing, and misaligned invoice tables.

After updating fontconfig, change res.company.font to 'Roboto' or 'Montserrat' and purge cached report attachments in ir.attachment.

PostgreSQL UNACCENT Index Crash in hr_recruitment

When installing hr_recruitment on Odoo 19, the initialization script attempts to create a trigram index:

In default PostgreSQL distributions, the unaccent(text) function is marked STABLE (provolatile = 's'). PostgreSQL strictly requires all functions used within index expressions to be marked IMMUTABLE. The migration aborts with: psycopg2.errors.InvalidObjectDefinition: functions in index expression must be marked IMMUTABLE.

When to Delay an Odoo 19 Upgrade

Upgrading to Odoo 19 is not an automatic imperative for every deployment. CTOs must weigh three operational constraints before scheduling a migration window:

1. Organizations relying on dozens of unmaintained third-party community modules that have not been audited for Odoo 19 breaking changes (_sql_constraints, _read_group, product_uom_id) risk silent constraint bypassing and data corruption if they migrate immediately. An upgrade should only proceed after full static analysis and unit test refactoring.
2. Enterprises running Odoo on restricted shared hosting where the infrastructure team cannot configure RemoveIPC=no in /etc/systemd/logind.conf or install custom system fonts in /usr/local/share/fonts will subject the database to unpredictable IPC termination and corrupted PDF generation on Debian 12. In such environments, staying on an isolated, hardened LTS release is mathematically safer.
3. High-throughput read-mostly reporting nodes with cached views gain relatively little from Odoo 19's unified security checks and models.Constraint, which primarily benefit transactional write-heavy databases, so the performance differential rarely justifies the refactoring overhead on its own.

For teams preparing their Debian 12 and Ubuntu 24.04 hosts, remember that RemoveIPC=yes was designed as an upstream systemd security policy for shared multi-user workstations so stale shared memory segments would not leak data after logout. Disabling it via RemoveIPC=no on dedicated database nodes does not introduce memory leaks because PostgreSQL manages its own shared memory lifecycle cleanly upon graceful shutdown. Alongside auditing _sql_constraints and inspecting generated PDF font objects with re.findall(rb'/BaseFont\s*/([^\s/>]+)', pdf_bytes) to catch unwanted /Lato-Regular and /DejaVuSans substitutions, locking down systemd-logind is mandatory before cutting over production traffic.