Skip to content

BUG: Updating Mail App exceeds Workers + CPU and terminates Nextcloud Service #13695

Open

Description

@SchwarzeLanze

Steps to reproduce

  1. Wait for an update of this junk App
  2. Update Mail in bulk with other Apps
  3. Just wait a few seconds and prepare to restart the container

Bulk update without Mail-App install unobtrusive and succesfull.

Expected behavior

It should be possible to update the mailapp without shutting down the whole service

Actual behavior

Worker get exceeded CPU get exceeded

Mail app version

5.12.0

Nextcloud version

34.0.2

Mailserver or service

No response

Operating system

alpine

PHP engine version

PHP 8.3

Nextcloud memory caching

No response

Web server

None

Database

PostgreSQL

Additional info

I know as a user it is easy to criticise but this unreliability is beyond.

Activity

  1. kesselb commented on Sep 21, 2026

    @kesselb
    Contributor

    Hey, thanks for reporting an issue when updating the app.

    I assume you did update from 5.11.x to 5.12.0. That upgrade will run some migrations to alter the database. These are:

    • Version5012Date20260604000000: adds the boolean column ai_generated to mail_local_messages (drafts and outbox, so a handful of rows per user).
    • Version5012Date20260816120000: adds the column master_user to mail_provisionings (one row per provisioning config).
    • Version5120Date20260901000000: replaces the unique index on mail_internal_address with one over (user_id, address). The table only holds addresses users added to their internal-address list.
    • Version5120Date20260820000000: only if you came from 5.11.5 or older; it rewrites four app config values to typed booleans. No schema change.

    None of these touch the big tables (mail_messages, mail_recipients), so I don't see where minutes of CPU or a pile of workers would come from here.

    What runs on every app update, regardless of version, are our repair steps.

    AddMissingDefaultTags for instance walks every mail account on the instance. If your instance has a lot of accounts, that is the more likely candidate.

    Could you share:

    • the exact version you updated from,
    • the output of occ app:update mail (or the updater log), it prints each migration and repair step, so we can see which one hangs,
    • roughly how many mail accounts are configured (select count(*) from oc_mail_accounts;),
    • what exactly "exceeds workers" means, is that php-fpm running out of children while the web updater holds a request open?
  2. self-assigned this
    on Sep 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions