Euro-office issues at every restart

[Tandonnet]

Environment

• Nextcloud AIO version: v13.6.0
• Office suite selected: Euro-Office
• Storage: SSD (local, not network storage)
• Trigger: AIO restarting all containers (automatic backups or manual updates)

Steps to reproduce

1. Select Euro-Office as the Office Suite integration in the AIO interface.
2. Let AIO restart the containers.
3. Euro-office takes too long to start and is considered failed by nextcloud.

Expected behavior

Euro-Office should come back up and remain enabled after the automatic restart, the same as before the restart.

Actual behavior

Nextcloud office app is disabled by Nextcloud with the message "euro-office did not start in time", even though the underlying container eventually does start successfully (see logs below). Claude considers it to be caused by the startup/health check happening too early, before PostgreSQL finishes a slow crash-recovery sequence.

Relevant logs (Euro-office container, at the automatic restart)

 * Starting PostgreSQL 16 database server
 * Removed stale pid file.
Error: /usr/lib/postgresql/16/bin/pg_ctl ... exited with status 1:
2026-09-13 04:02:15.717 UTC [56] LOG:  starting PostgreSQL 16.14 ...
2026-09-13 04:02:16.099 UTC [59] LOG:  database system was interrupted; last known up at 2026-08-04 08:21:04 UTC
2026-09-13 04:02:26.274 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 10.14 s, current path: ./base/5/2703
2026-09-13 04:02:36.189 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 20.06 s, current path: ./base/5/2619_vm
2026-09-13 04:02:46.325 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 30.19 s, current path: ./base/5/3608
2026-09-13 04:02:56.263 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 40.13 s, current path: ./base/5/3394_vm
2026-09-13 04:03:06.668 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 50.54 s, current path: ./base/1/4170
pg_ctl: server did not start in time
   ...fail!
 * Starting PostgreSQL 16 database server
 * Removed stale pid file.
Error: /usr/lib/postgresql/16/bin/pg_ctl ... exited with status 1:
2026-09-13 04:03:16.309 UTC [56] LOG:  starting PostgreSQL 16.14 ...
2026-09-13 04:03:16.320 UTC [59] LOG:  database system was interrupted; last known up at 2026-08-04 08:21:04 UTC
2026-09-13 04:03:26.438 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 10.10 s, current path: ./base/1/2600_fsm
2026-09-13 04:03:36.355 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 20.02 s, current path: ./base/1/2699
2026-09-13 04:03:46.339 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 30.01 s, current path: ./base/4/6117
2026-09-13 04:03:56.423 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 40.09 s, current path: ./base/4/2753_vm
2026-09-13 04:04:06.471 UTC [59] LOG:  syncing data directory (fsync), elapsed time: 50.14 s, current path: ./base/16385/3596
pg_ctl: server did not start in time
   ...fail!
 * Starting PostgreSQL 16 database server
   ...done.
Postgres schema already present, skipping.
 * Starting RabbitMQ Messaging Server rabbitmq-server
   ...done.
Starting redis-server: redis-server.
 * Starting nginx nginx
   ...done.
...
2026-09-13 04:14:31,632 INFO spawned: 'converter' with pid 1297
2026-09-13 04:14:31,636 INFO spawned: 'docservice' with pid 1298
2026-09-13 04:14:33,039 INFO success: converter entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2026-09-13 04:14:33,039 INFO success: docservice entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

Note the line database system was interrupted; last known up at 2026-08-04 — PostgreSQL was not shut down cleanly before the restart, which forces a full fsync of the data directory on the next start. On this system that sync takes roughly 10 seconds per file, so it takes several minutes in total (two pg_ctl attempts time out here before the third succeeds ~12 minutes after the restart began). Both converter and docservice eventually start and stay running (RUNNING state), so the Euro-Office container itself is healthy — it just takes far longer than whatever timeout AIO's startup check uses. (This paragraph was written by AI because I don't clearly understand what's going on)

Analysis / suspected cause

This looks like the same category of bug previously reported and fixed for the OnlyOffice container in #7315 (fixed via #7334, released in v12.4.0): a startup/health check that runs before the document server container has actually finished initializing, causing AIO to mark the app as failed and disable it. However, since I'm running v13.6.0 (well past v12.4.0), and Euro-Office is a separate, more recently added container/integration path, it seems the same premature-check issue may exist in the Euro-Office code path independently of the original OnlyOffice fix. This may be related to the general Euro-Office rough edges reported in #8433, #8376, and #8262, though none of those describe this exact "did not start in time" / slow-Postgres-recovery scenario. (Paragraph also partly written by AI)

Possible fixes / things to check

1. Ensure PostgreSQL is given enough time to shut down cleanly (SIGTERM with adequate grace period) before the container is stopped during the automatic restart/update routine, so it doesn't need a full data-directory fsync on the next start.
2. Increase (or make configurable) the startup timeout used by AIO and/or Nextcloud to determine whether the Euro-Office container "started in time," so it accounts for legitimate slow-but-successful startups like this one.
3. Maybe allow for an option to automatically start the app if it was disabled due to "not starting in time" ?

Workaround

I need to manually enable the nextcloud office app at every startup.

Sorry if this is a euro-office issue and not an AIO issue, I wasn't sure and I can post it on the nextcloud-eurooffice repo if that's where the problem is.

[szaimen]

Hi, please post this at https://help.nextcloud.com. There more eyes will see this.