I did an strace and it shows that there’s no attempt to unlink the shared memory file. I’ll provide a fuller trace extract here, but the only mentions of one particular left-over file are:
916110 unlink("/dev/shm/915244crawl4r0") = -1 ENOENT (No such file or directory)
916110 openat(AT_FDCWD, "/dev/shm/915244crawl4r0", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0700) = 201
916110 ftruncate(201, 524288) = 0
916110 mmap(NULL, 524288, PROT_READ|PROT_WRITE, MAP_SHARED, 201, 0) = 0x7fabbef80000
916110 close(201) = 0
916110 clone3({flags=CLONE_VM|CLONE_VFORK|CLONE_CLEAR_SIGHAND, exit_signal=SIGCHLD, stack=0x7fabbf264000, stack_size=0x9000}, 88) = 916113
916113 execve("/nix/store/20sd8x85vxm2s895d7iywqj82b013bm2-sublimetext4-bin-4192/.sublime_text-wrapped", ["/nix/store/20sd8x85vxm2s895d7iyw"..., "--crawl", "915244crawl4s0", "915244crawl4r0", "915244", "/home/user/.config/sublime-te"..., "/home/user/.cache/sublime-tex"..., "/nix/store/20sd8x85vxm2s895d7iyw"...], 0x7fffda6757c0 /* 78 vars */) = 0
916110 munmap(0x7fabbef80000, 524288) = 0
So the parent thread creates the file, sets its length, mmaps it, closes it, passes the name to the crawler thread, and munmaps it. There’s no sign that either thread attempts to unlink it, and I used strace -f so the tracing included all subprocesses.
However, the child thread doesn’t seem to do much:
916113 rt_sigprocmask(SIG_BLOCK, NULL, ~[KILL STOP], 8) = 0
916113 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
916113 execve("/nix/store/20sd8x85vxm2s895d7iywqj82b013bm2-sublimetext4-bin-4192/.sublime_text-wrapped", ["/nix/store/20sd8x85vxm2s895d7iyw"..., "--crawl", "915244crawl4s0", "915244crawl4r0", "915244", "/home/user/.config/sublime-te"..., "/home/user/.cache/sublime-tex"..., "/nix/store/20sd8x85vxm2s895d7iyw"...], 0x7fffda6757c0 /* 78 vars */) = 0
916113 brk(NULL ) = 0x5634f1701000
916113 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1f6ab07000
916113 access("/etc/ld-nix.so.preload", R_OK) = -1 ENOENT (No such file or directory)
916113 openat(AT_FDCWD, "/etc/sane-libs/glibc-hwcaps/x86-64-v3/librt.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
916113 newfstatat(AT_FDCWD, "/etc/sane-libs/glibc-hwcaps/x86-64-v3/", 0x7ffc5f2cf260, 0) = -1 ENOENT (No such file or directory)
916113 openat(AT_FDCWD, "/etc/sane-libs/glibc-hwcaps/x86-64-v2/librt.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
916113 newfstatat(AT_FDCWD, "/etc/sane-libs/glibc-hwcaps/x86-64-v2/", 0x7ffc5f2cf260, 0) = -1 ENOENT (No such file or directory)
916113 +++ killed by SIGKILL +++
So it’s certainly not unlinking the file right after starting, but perhaps the problem is that it’s never getting a chance to do that.
It’s odd that it’s getting a SIGKILL, which prevents it from running any kind of cleanup before it terminates. I’d have expected it to get a SIGTERM or SIGINT. I exited Sublime from the GUI with File > Quit so there shouldn’t have been any emergency termination. I did watch the progress of indexing in the GUI and waited until it was idle for a while before quitting. It’s getting killed with SIGKILL by the parent thread, though:
916110 kill(916113, SIGKILL) = 0
I should run the trace again with timestamps, so I can see how long it executes before being killed.
