dist(AppImage): unable to run models after restarting the app #210

Activity

1. gucio321

   added

   bugSomething isn't workingSomething isn't working

   on Jun 27, 2026
2. novaflash commented on Aug 28, 2026

   

   novaflash

   on Aug 28, 2026

   More actions

   I was able to work around this problem at least with;
   ln -sfn /home/username/.config/Modly/python-embed/bin/python3.11 /home/username/Documents/Modly/modelname/venv/bin/python3.11
3. lightningpixel

   added this to Modly Boardon Sep 4, 2026
4. github-project-automation

   moved this to Backlog in Modly Boardon Sep 4, 2026
5. DrCyanide commented on Sep 15, 2026

   

   DrCyanide

   on Sep 15, 2026

   More actions

   I was getting this same issue on 0.4.2

   #285
6. DrHepa commented on Sep 24, 2026

   

   DrHepa

   on Sep 24, 2026

   SponsorContributor

   More actions

   Consolidating the v0.4.2 reproductions from #285 and #352 here, since this is the earlier canonical AppImage restart issue.

   I investigated the v0.4.2 source and reproduced the symlink-copy behavior. The release attempted to address the ephemeral AppImage runtime by copying python-embed into userData in ensureStableEmbeddedPython(), but the copy currently uses:

   await cp(getEmbeddedPythonDir(), stableDir, {
     recursive: true,
     preserveTimestamps: true,
   })

   Node's fs.cp() defaults verbatimSymlinks to false. A relative runtime link such as bin/python3 -> python3.11 is therefore copied as an absolute link back into the current /tmp/.mount_Modly-* source. After the AppImage exits, that mount disappears and the supposedly stable runtime plus the venv interpreter chain contain dangling links.

   This explains the shared sequence in #285 and #352:

   1. The first run works while the AppImage mount exists.
   2. After restart, checkSetupNeeded() sees the venv Python as missing and asks for the data directory again.
   3. Extension venvs report venv missing or remain in incomplete/registration-pending quarantine.
   4. Repair can fail while trying to recreate a venv through the broken interpreter chain.

   The original --copies suggestion can provide defense in depth for venv creation, but v0.4.2 also needs the stable runtime copy itself corrected and validated.

   Proposed fix

   await cp(getEmbeddedPythonDir(), stableDir, {
     recursive: true,
     preserveTimestamps: true,
     verbatimSymlinks: true,
   })

   Additionally:

   • Before accepting an existing stable runtime, resolve its Python entry point and require the target to exist inside stableDir; rebuild it if validation fails.
   • Ensure the next release rebuilds affected core and extension venvs once through the corrected interpreter.
   • When recovery setup is required, return the previously saved data base directory instead of always defaulting to Documents/Modly; otherwise users can accidentally redirect an existing installation and make models appear lost.

   Regression coverage

   • Copy a fixture Python tree with relative symlinks from a temporary /tmp/.mount_Modly-*-like directory.
   • Remove the source and verify the copied Python link still resolves inside stableDir and executes.
   • Simulate restart and assert checkSetupNeeded() remains false.
   • Verify the saved models/workspace/extensions/dependencies base path is preserved during recovery.
   • Validate a rebuilt AppImage through install, close, reopen, extension discovery, generation, and Repair.

   The source diagnosis and fs.cp() behavior are reproduced. A rebuilt AppImage E2E remains required before considering the fix complete. The longer analysis was initially posted on #352 before identifying this canonical issue: #352 (comment)
7. Lorchie commented on Oct 9, 2026

   

   Lorchie

   on Oct 9, 2026

   Collaborator

   More actions

   This is fixed in v0.4.3. The root cause was the copy of the bundled Python runtime out of the AppImage mount: fs.cp turned relative symlinks (bin/python3 -> python3.11) into absolute links pointing back into /tmp/.mount_Modly-*. That mount disappears when the app closes, so every extension venv broke on the next launch. The copy now keeps relative symlinks as they are. Thanks @DrHepa for the diagnosis.

   After updating, your existing extension venvs should work again. If one still fails, a Repair on the Models page rebuilds it. If the problem is still there on v0.4.3, feel free to reopen this issue with your logs.
8. Lorchie

   closed this as completedon Oct 9, 2026