Standalone Python process remains alive after SimulationApp.close() returns (Isaac Sim 5.1.0.0) #877

Activity

1. vick-yu

   added

   isaac-sim-api

   isaac-sim-v5-1-0

   on Oct 13, 2026
2. vick-yu commented on Oct 13, 2026

   

   vick-yu

   on Oct 13, 2026

   More actions

   Thanks for the careful writeup and the immutable evidence package -- the
   fsync-backed lifecycle markers make this much easier to analyze than the
   typical "my script hangs" report.

   To answer your three questions directly:

   1. Is natural process exit expected after SimulationApp.close() with fast_shutdown=False?

   Not guaranteed in Isaac Sim 5.1.0, and this is a known architectural limitation
   of that version.

   In 5.1.0, close() with fast_shutdown=False calls
   shutdown_and_release_framework(), which performs extension-by-extension
   teardown and then returns control to Python. After that point, CPython's
   interpreter shutdown proceeds normally -- but native Kit and Carbonite worker
   threads (the tasking pool, renderer threads, etc.) are not joined by the
   Python side before returning. These are non-daemon C threads. CPython's
   atexit and threading cleanup wait for daemon threads, but non-daemon
   native C threads that are not tracked by Python's threading module are left
   to finish on their own schedule.

   In your measurement, the process survived ~24 seconds after main() returned.
   That interval corresponds to Kit's native teardown completing independently of
   the Python runtime -- this is the framework cleaning up after itself, but doing
   so asynchronously from Python's perspective.

   The 5.1 documentation describes the option as:

   fast_shutdown (bool) -- True to exit process immediately, false to shutdown
   each extension.

   "Shutdown each extension" refers to the extension teardown sequence, not a
   guarantee that the process exits immediately after close() returns.

   2. Is there a supported cleanup or shutdown sequence for this case?

   Yes. The supported workaround in 5.1.0 is to use fast_shutdown=True
   (the default) if bounded process exit is a hard requirement for your supervisor.
   With fast_shutdown=True, Kit calls quickReleaseFrameworkAndTerminate
   internally, which terminates the process immediately after the framework is
   released -- your supervisor will see a clean exit within seconds.

   If you need graceful extension teardown and bounded process exit, the
   cleanest approach in 5.1.0 is to add an explicit os._exit(0) after
   close() returns:

   import os
   app.close()
   # Give native threads a brief grace period, then force exit.
   os._exit(0)

   os._exit() bypasses CPython's atexit handlers and terminates immediately,
   which is safe after close() has already finished its cleanup sequence.

   Note for Isaac Sim 6.0.0 and later: this behavior is improved. The 6.0+
   SimulationApp switches from shutdown_and_release_framework() to
   app.shutdown() (which handles fast_shutdown internally and avoids a GIL
   deadlock that could occur in the older path). It also registers an atexit
   handler so the SDK can clean up even if close() is never called explicitly.
   If you are able to move to 6.0.0 or later, the post-close process-survival
   window is substantially reduced even with fast_shutdown=False.

   3. Which artifact would best distinguish the remaining process-lifetime condition?

   A strace -p <pid> -e trace=futex,nanosleep,epoll_wait -f snapshot taken in
   the ~24-second window between main() returning and process exit would show
   which syscalls the surviving native threads are blocked on. If you see futex
   waits with a consistent caller (e.g., carb.tasking thread joining its pool),
   that pinpoints the specific subsystem keeping the process alive.

   Alternatively, attaching gdb -p <pid> and running info threads followed
   by thread apply all bt at that moment would give the full native thread
   backtraces and identify any threads that have not yet exited.

   In practice, for production use, the os._exit(0) pattern or fast_shutdown=True
   is the pragmatic solution rather than diagnosing the specific native teardown
   sequencing.

   ---

   The issue package you provided is thorough and the observation is accurate.
   This is a real limitation of the 5.1.0 teardown path, not a user error.
3. vick-yu commented on Oct 27, 2026

   

   vick-yu

   on Oct 27, 2026

   More actions

   Hi @FrankAsanteVanLaarhoven — thanks again for the exceptionally thorough writeup and the immutable evidence package. We haven't heard back since our reply explaining the non-daemon native thread behavior and the available workarounds (fast_shutdown=True, sys.exit() after close()). We'll go ahead and close this out. If you're still hitting this or have follow-up findings, you can reopen it directly via the 'Reopen issue' button, or open a new issue for 6.0.0+ referencing this one. Thanks for contributing such a well-documented report!
4. vick-yu

   closed this as completedon Oct 27, 2026