briefly
briefly copied to clipboard
Briefly does not cleanup files on application exit
I've been encountering an issue where Briefly will not consistently cleanup files on process exit. It appears as though the Briefly application is exiting before it has a chance to run File.rm_rf/1
for each monitored process.
I've created a sample project to demonstrate the issue.
https://github.com/ngeraedts/briefly_shutdown
I believe you need to add Briefly to extra_applications
in your mix.exs. The installation instructions don't mention it, but briefly runs a supervision tree to create and monitor the tempfiles and their owner pids. @cargosensedev is that the case and if so can you update the install docs?
It is never necessary to add a mix dependency to the extra applications list.
On Sun, Dec 2, 2018 at 10:19 AM sampscl [email protected] wrote:
I believe you need to add Briefly to extra_applications in your mix.exs. The installation instructions don't mention it, but briefly runs a supervision tree to create and monitor the tempfiles and their owner pids. @ngeraedts https://github.com/ngeraedts, is that the case and if so can you update the install docs?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/CargoSense/briefly/issues/6#issuecomment-443515400, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPICRS0VPUTANLSC-LQDX8CYdwyGdW1ks5u0-91gaJpZM4OkWdS .
This is clearly happening to me, from time to time I need to manually remove non empty temporal folders created by Briefly.
I'm using 0.3.0
and this is happening to me on MacOS 10.14.6. Don't know if this is happening to some production services that I'm running and are using this library but it's something that I need to check.
@jfcalvo I have run many hours of soak tests on Ubuntu server, creating hundreds of thousands of temporary files and directories, and all the tmp files were deleted without a problem. On the occasion they weren't, it was because I was mistakenly creating the temp files in the supervisor process (start_link method of the child process) rather than the spawned process (init method of the child process), and the supervisor never exited. Are you seeing any Erlang dump files? If the BEAM crashes, then that will prevent files being collected.
You could try using File.rm_rf!
to see if/when the deletions are failing? rm_rf
In MacOS 10.14.6 using Elixir 1.10.3 if I open an elixir console with iex
and write the following:
Erlang/OTP 22 [erts-10.7.1] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe] [dtrace]
Interactive Elixir (1.10.3) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> Briefly.create!
"/var/folders/b0/kzs4_2t50znc719ljxl4dpqr0000gn/T//briefly-1591/briefly-297018-34355-1"
iex(2)>
BREAK: (a)bort (A)bort with dump (c)ontinue (p)roc info (i)nfo
(l)oaded (v)ersion (k)ill (D)b-tables (d)istribution
q
I can see that the file is there and has not been deleted. I do a lot of manual testing in the console so this is where I see that problem (it's true that is not happening to me on production). Maybe I'm missing something? Can be the way that I close the console?
$ ls -l /var/folders/b0/kzs4_2t50znc719ljxl4dpqr0000gn/T//briefly-1591/briefly-297018-34355-1
-rw-r--r-- 1 jfcalvo staff 0 4 jun 20:56 /var/folders/b0/kzs4_2t50znc719ljxl4dpqr0000gn/T//briefly-1591/briefly-297018-34355-1
This has to do with how you are closing your console and is unavoidable if you close it that way. When you close it that way, no cleanup code is run. To terminate your application with the proper shutdown process use System.stop
, or send SIGTERM to the BEAM process.
@benwilson512 is correct that Elixir is not executing a System.stop
when closing the console?
That's correct.