Client library occasionally not found

[jwimberl]

I am running a daemon process in CentOS 7, using R 3.6.0 and callr 3.7.3. The daemon listens to requests and runs a background session via callr, but occasionally this background process fails to launch, with an error

Rscript[14607]: cannot open file '/tmp/RtmpVGcFTq/callr-client--2016851.so': No such file or directory

This appears somewhat related to issue #157 , though that is marked as fixed. Is this a known issue? Is there any chance that switching to a newer version of R would help?

[gaborcsardi]

That typically happens if some cleaner process cleans up the temporary directory. I forgot how this works exactly, but we can probably make it more robust, still.

[jwimberl]

This is occurring fairly frequently for me -- is there an option to change the temporary directory used by callr in order to mitigate this issue?

[gaborcsardi]

Yes, see ?tmpdir.

[jwimberl]

Thanks; I was hoping to restrict the change to callr itself but I will try this if need be. I am, though, uncertain that a cleaner process could be responsible for this error. On this system the /tmp directory is cleaned every 10 days, and was last cleaned 5 days ago. The issue has occurred multiple times and occurs at most some seconds after the background sessions is launched. Could it be a race condition of some kind involving prepare_client_libs? This error occurs when using r_bg, and not r_session.

[jwimberl]

Oh, I understand now -- the client files are prepared during the start of an R session and are subsequently reused, and so for an R session that has been open for > 10 days the client sofile can be pulled out from under the session's feet -- is this correct?

[gaborcsardi]

Yes, that's correct.

I'll try to improve this, but for now using another directory could be a workaround.

[jwimberl]

Actually, I think this is fixed already by #250 here:

https://github.com/r-lib/callr/pull/250/files#diff-6cdf9383192f059643a614d3b5fa2237b4eb6e8a5ccf0d468a7d75057eb987b7R22-R25

I tested a pretty much identical change, which held up while manually deleting the sofile directory and (not that a difference should be expected) triggering systemctl start systemd-tmpfiles-clean with a short cleanup time.

[gaborcsardi]

OK, so if I understand correctly, this is now fixed.