Cant spin up custom docker-compose.yml file + no logs in /var/log/app_lifecycle.log

Hi,

I’m running quite some containers. But after upgrading from 24.x.x to 25.x.x I noticed some strange behaviour.

  • If I spin down 1 of my custom apps, I’m able to restart this app (because the IMG is still there)
    • If I spin down again the same app and remove the image (via portainer), and spin up again this custom app I get the message

      • “[EFAULT] Failed ‘up’ action for ‘myCustomApp’ app. Please check /var/log/app_lifecycle.log for more details“

        Which then I think, let run ‘sudo nano /var/log/app_lifecycle.log‘, but this file is empty, so no logging is being send to this file.

  • The same error I get, if I setup a custom yml file and again start it from scratch. And yet again no logging :person_shrugging:

Here is a snippet of how my ‘custom app‘ looks like:

include:
  - env_file:
      - /mnt/tank/docker/global/.env.global
      - /mnt/tank/docker/download/.env
    path: /mnt/tank/docker/download/docker-compose.yml



Not sure if it’s the same issue, and you don’t say if you’re on 25.04 or 25.10, but you could give this a shot. 25.10 RC1 Custom App YAML Input Bug? - #2 by zzzhouuu

Thanks,

I’ve added it to all my configs, but still my .log is empty :person_shrugging:

truenas_admin@truenas[~]$ sudo nano /var/log/app_lifecycle.log
[sudo] password for truenas_admin:
truenas_admin@truenas[~]$

I’m now on 25.10.5

I also just tested, and still I have the same issue that if there is no IMG I get, “[EFAULT] Failed ‘up’ action for ‘myCustomApp’ app. Please check /var/log/app_lifecycle.log for more details“

Every Custom App I deploy fails on first install with:

[EFAULT] Failed 'up' action for '<app>' app. Please check /var/log/app_lifecycle.log for more details

/var/log/app_lifecycle.log stays empty — nothing is ever written there.

Reproducible pattern:

  1. Deploy a new Custom App whose image isn’t cached locally yet → fails with EFAULT.

  2. Manually docker compose pull + up the same yml in shell → works fine.

  3. Retry the exact same app via the GUI afterwards → works instantly (image now cached).

So it only fails on a cold pull done through the GUI/middleware job, never once the image is already local. Confirmed this isn’t a stale-registration issue by testing with a completely new app name (testapp-debug1), same EFAULT, and middleware’s own job log shows it auto-cleans up the failed install afterward:

progress.description: "Failure occurred while installing 'testapp-debug1', cleaning up"
File "middlewared/plugins/apps/compose_utils.py", line 63, in compose_action
    raise CallError(err_msg)

compose_action() raises this generic hardcoded error instead of surfacing the actual docker compose stdout/stderr, and that output never makes it into app_lifecycle.log either, so there’s no way to see what actually goes wrong during the pull (timeout? registry hiccup?).

Workaround: manually docker compose pull all images via shell before installing any Custom App through the GUI.

Would appreciate if a dev could check why app_lifecycle.log never receives output on failure, and whether there’s a timeout on the initial up action that’s too short for a cold pull.

Relevant job output (via midclt call core.get_jobs '[["method","=","app.create"],["state","=","FAILED"]]', filtered to the testapp-debug1 run)

{

“id”: 8417,

“method”: “app.create”,

“arguments”: [{“custom_app”: true, “app_name”: “testapp-debug1”}],

“progress”: {

“percent”: 80,

“description”: “Failure occurred while installing ‘testapp-debug1’, cleaning up”

},

“error”: “[EFAULT] Failed ‘up’ action for ‘testapp-debug1’ app. Please check /var/log/app_lifecycle.log for more details”,

“exception”: “Traceback (most recent call last):\n  File "middlewared/plugins/apps/custom_app.py", line 74, in create\n    compose_action(app_name, version, ‘up’, force_recreate=True, remove_orphans=True)\n  File "middlewared/plugins/apps/compose_utils.py", line 63, in compose_action\n    raise CallError(err_msg)\nmiddlewared.service_exception.CallError: [EFAULT] Failed ‘up’ action for ‘testapp-debug1’ app. Please check /var/log/app_lifecycle.log for more details\n”,
“state”: “FAILED”
}

bump