aMule won't start after closing (flatpak)

[PhiSYS]

Since I installed v3, after closing aMule (apparently correct as far as I can see in log:)

 2026-07-20 19:32:18: Ahora, saliendo de la aplicación principal...
 2026-07-20 19:32:18: aMule OnExit: terminando el núcleo.
 2026-07-20 19:32:18: Guardando el archivo de partes 1 de 1
 2026-07-20 19:32:18: Todos los archivos de partes han sido guardados.
 2026-07-20 19:32:18: Cierre de aMule completado.

It does not remove the muleLock file.

But even if I delete muleLock manually, it suddenly stops without any anomalous message log:

$ flatpak run org.amule.aMule
 2026-07-20 19:48:24: Initialising aMule 3.0.1 compiled with wxGTK3 v3.2.6 and Boost 1.87
 2026-07-20 19:48:24: Checking if there is an instance already running...
 2026-07-20 19:48:24: No other instances are running.
 2026-07-20 19:48:26: Socket de escucha: correcto.

(org.amule.aMule:2): libayatana-appindicator-WARNING **: 19:48:27.081: libayatana-appindicator is deprecated. Please use libayatana-appindicator-glib in newly written code.
 2026-07-20 19:48:27: Cargando archivos temporales desde /home/myuser/Downloads/temp/aMule.
 2026-07-20 19:48:27: Cargando el archivo de partes 1 de 1
 2026-07-20 19:48:27: Todos los archivos de partes han sido cargados.
 2026-07-20 19:48:27: Añadiendo archivo /home/myuser/Downloads/temp/aMule/003.part.met a compartidos

then stops returning code 137

WORKAROUND

By deleting both muleLock AND lastversion files, it starts fine again, but the problem reproduces as soon as aMule is closed.

I'm using:

• Flatpack aMule v3.0.1 (also happened in v3.0)
• Kubuntu 26.04 x86_64

[got3nks]

Thanks for the detailed report @PhiSYS. Two separate things are going on here, worth keeping apart:

1. muleLock not being removed on exit. Real, but cosmetic — and we've now fixed it on master. aMule terminates via std::_Exit() on shutdown (a workaround for an unrelated crash in wx's networking teardown), which was skipping the step that removes the lock file. It didn't block your restart, though: your log shows aMule checked the leftover lock, saw the previous process was already gone, and proceeded anyway ("No other instances are running"). The single-instance mechanism was also rewritten after 3.0.1, so current builds behave differently here.

2. The exit-137 crash. This is the one that matters, and it's independent of the lock file. Exit code 137 is 128 + 9 — the process was killed by SIGKILL, i.e. something external terminated it (most often the kernel's out-of-memory killer). That's exactly why nothing shows in aMule's own log: a SIGKILL can't be caught or logged.

Startup and lock handling changed a lot since 3.0.1, so the useful first step is to check whether a current build still reproduces the crash. Could you try a fresh build (it includes the muleLock fix above)? Signed in to GitHub, download and install:

• flatpak-x86_64 → unzip → flatpak install --user aMule-*.flatpak, then run it.

If it still crashes with 137, the missing piece is what sent the kill. Right after a crash, please run:

journalctl -k -b | tail -40

and paste the output in a code block. If it's the kernel OOM killer you'll see Out of memory: Killed process … (aMule); if it's systemd-oomd, journalctl -b -u systemd-oomd shows it instead. Either way, that tells us what's actually killing it.

[PhiSYS]

Thanks for your help.

What I did:

• Closed old version of aMule (leaving said leftovers)
• Uninstalled old version of aMule.
• Installed the version you provided.
• It started ok.
• Closed it (again leaving only lastversion as leftover)

  GIT
  3.0.1

• Won't start again.

Initially even if I knew 137 relates to SIGKILL, I quickly discarded OOM in my mind because I was only using 10% of 64GB of RAM. But it may be caused (I don't know) by some flatpak limitation and worth investigating.

As before:

$ flatpak run org.amule.aMule                             
 2026-07-21 22:36:44: Initialising aMule GIT compiled with wxGTK3 v3.2.6 and Boost 1.87 (Snapshot: rev. 3.0.1-219-g3e396ae19)
 2026-07-21 22:36:44: Checking if there is an instance already running...
 2026-07-21 22:36:44: No other instances are running.
 2026-07-21 22:36:46: Socket de escucha: correcto.

(org.amule.aMule:2): libayatana-appindicator-WARNING **: 22:36:47.076: libayatana-appindicator is deprecated. Please use libayatana-appindicator-glib in newly written code.
 2026-07-21 22:36:47: Cargando archivos temporales desde /home/phisys/Downloads/temp/aMule.
 2026-07-21 22:36:47: Cargando el archivo de partes 1 de 1
 2026-07-21 22:36:47: Todos los archivos de partes han sido cargados.
 2026-07-21 22:36:47: Añadiendo archivo /home/myuser/Downloads/temp/aMule/003.part.met a compartidos

Tried with journalctl -k -b | tail -40 but it only showed unrelated older logs, so I tried to launch a journalctl -f in another terminal, and there it is:

jul 21 22:36:44 mypc systemd[3489]: Started app-flatpak-org.amule.aMule-1545559075.scope.
jul 21 22:36:46 mypc systemd[3489]: Started app-flatpak-org.amule.aMule-2014482308.scope.
jul 21 22:36:49 mypc systemd[3489]: app-flatpak-org.amule.aMule-1545559075.scope: Consumed 2.255s CPU time over 5.341s wall clock time, 70.8M memory peak.

Nothing more.

Also, I provide the status of memory, to show how unlikely is that I'm low on memory for a OOM:

$ free -h
               total       usado       libre  compartido   búf/caché  disponible
Mem:            62Gi       8.9Gi        30Gi       613Mi        24Gi        53Gi
Inter:          13Gi       106Mi        12Gi

Something is weird with lasversion file. As soon as I deleted it, aMule could start again.
Now its contents (although I doubt it helps):

GIT

[got3nks]

@PhiSYS thanks for the detailed follow-up — confirming it's SIGKILL (not OOM) and catching the two scopes in the journal is really useful.

Update from our side: I tried hard to reproduce this. Same flatpak GIT snapshot, with lastversion already containing the running version so the "first time you run aMule" dialog is skipped — i.e. your exact crash path — and restarted it many times. It starts cleanly every time (exit 0). So the code path itself isn't the cause; something in the environment is sending the SIGKILL. The main difference between our setups is the desktop: you're on KDE Plasma (Kubuntu), we tested on GNOME/Wayland. That lastversion correlation you spotted is real, but it looks like the "new version" dialog just pauses startup long enough to mask a race that only turns fatal under KDE.

To pin down what's killing it, a few things would help — all pasteable as text, no screenshots:

1. Who sends the kill. Right after a failed launch:

journalctl --user -b --since -2min | grep -iE 'amule|\.scope|kill|Failed with|oom|Consumed'

Anything like "Killing process" or "Failed with result 'signal'" on the aMule scope is the smoking gun.

2. What the second scope is. Your journal showed two app-flatpak-org.amule.aMule-*.scope ~2 s apart. While it's failing (or right after):

systemctl --user list-units 'app-flatpak-org.amule*'
systemctl --user status 'app-flatpak-org.amule.aMule-*.scope'

The Main PID / CGroup lines tell us whether the second scope is a second aMule or a child process.

3. Isolation test — the tray. On KDE the tray icon goes through StatusNotifierWatcher, and our shutdown skips its teardown, so it's the prime suspect. In Preferences, disable the system-tray icon, close aMule, and try again — does it start reliably then?

4. After a clean close, before relaunching: does flatpak ps still list aMule, or does systemctl --user list-units 'app-flatpak-org.amule*' show a leftover scope from the previous run?

If 3 makes it start reliably, that basically confirms it and points straight at the fix.