Permissions issue when sharing the cache about capsule HOT 17 CLOSED

Why not set the cache dir to /tmp/capsule/$USER then?

from capsule.

Hi @pron,

That was under consideration, and is still a fallback option, but we'd rather avoid it, because we'd need to have a cleanup process. We have many users using this application, so storing 60M+ in /tmp per user would not be a good solution; therefore, we would end up moving it to /var/tmp, then writing a cleanup process. Also, since we can't rely on any individual users being able to delete the cache dir, it would most likely need to be done outside the running of the app, as some scheduled process.

If we don't write the cleanup process, then, we have the added problem that many of these users have different groups, and we weren't expecting the need to have the app write to local file system. Any type of persistent data is hidden by remote APIs where local permissions are not at issue. We don't want to add special groups for an arbitrary user of the app to be able to write to a shared location.

Before moving forward with the cleanup solution, is there anything that can be done around the .lock file? I only saw 4 references to it in the code, and I didn't notice a cleanup of the file. What is the intended use of the .lock file from capsule's perspective?

Thanks!

from capsule.

Hi @pron,

I re-read the code, and see that you do cleanup the .lock file, in resetAppCache, which is only called by ensureExtractedIfNecessary. In our case, the lock file was not removed for some reason, and on top of that, other users wouldn't be able to interact with the .lock file since the dir's perms are tied to the original cache creator user.

I will take a step back and try to think on this more on the drive into work :)

Thanks!

from capsule.

I will take a look at the .lock file problem (it's intended to prevent concurrent launches from overwriting one another's files when extracting the capsule). Hopefully it will let all of your users share the same cache.

Also, have you considered using a RAM disk that you can destroy after each launch? It can be very small.

But do you have any suggestions? How do you think Capsule should behave?

from capsule.

Hi @pron,

Thanks for being patient, and working through this with me, by continuing to offer good suggestions. I hadn't heard of RAM disks before this, so I learned something there.

Regarding the question on how I think Capsule should behave, I was having a long conversation with one of my coworkers, and we are now in brainstorming sessions here and there around how to work with Capsule, so hopefully, next week, I should have gone through more thinking around this that would allow me to answer that question better.

Thanks for the explanation on .lock. That's what I thought it was for, just wanted to get clarity, since the file was still around after the run, and I verified that Capsule.java uses FileChannel.open, so I'm imagining flock is used underneath, so the fact that the lock file wasn't cleaned up is strange.

from capsule.

I wonder if there is some nuance around the fact that flock was performed by the parent capsule bootstrapping process, and the child process inherited the lock resource, with respect to flock automatically releasing the lock if the process doesn't.

Also, I see that (un)lockAppCache operates on the same lock within the main bootstrapping process. Are there potential error conditions that would cause unlock to not be called?

from capsule.

I will investigate the lock file issue next week. Other than that, it's important to me that Capsule addresses all practical deployment strategies used in different projects, so I'll discuss further what it is that you need, and how Capsule can help.

from capsule.

Cool, thanks, I'll continue to think on it to help on my end. Have a good weekend!

from capsule.

Hi @pron,

I was thinking about how I would want to use capsule when dealing with a shared cache:

• Be able to have capsule set up the cache, independent of a run of the app itself. This would allow me to set up permissions, amongst other things, on the cache as part of the deployment process. One thing I would do as part of deployment would to be remove the old cache, and sync it with the current version of the capsule, since the machine itself is using the same version of the app across all users. Since it's part of deployment time, I can guarantee an admin user is performing the operation.
• Ensure that if the cache is already present, capsule would treat that cache dir as read-only for all intents and purposes, so that the running user's access level is not relevant (except for read access, of course).
• If cache is not present and a write needs to be performed, instead of nio.IOException, I would prefer an exception more specific to the fact that the cache is being setup, so that the user can be given a message to just retry soon.
• Regarding the .lock file itself, that's still pending troubleshooting on why the file is still present when the app is not running. I think for my above points to work, the .lock file would need to be addressed.

Thanks!

from capsule.

I would like to make the cache more transparent rather than less (and I even have an idea involving a FUSE file-system to present the JAR to the Java command line as if it were extracted), but I'll try to make sure that a shared cache -- even though it's not ideal -- will work.

In the meantime, I suggest you take a look at private tmps, which is available, so I understand, in many Linux distributions. It gives each user its own virtual /tmp dir, which is stored in RAM.

from capsule.

Hi @pron,

Thanks again for the good feedback. I was not aware of private tmps; that is good tech to know about.

I appreciate the desire to want to hide the cache from the user, but on production systems where the user home dir is not always writeable (with 80MB+ in single transfer transaction), one natural way of thinking would be to switch to a shared cached line of thinking (or maybe it's just me :]). However, on systems where technology such as private tmps are available, then that is an option. The main issue is that once the default of writing to user home dir's doesn't work, users of capsule will have to start thinking about the cache as part of their overall engineering solution. Thus, it will only be truly transparent if writing to user's home dir is viable.

One potential conceptual way to approach it is, keep the cache transparent, but if it's not going to be transparent within a particular engineering solution, then provide some tools to work on the cache independent of runs. Basically, use good defaults, but allow the tools to handle situations where defaults break down.

Thanks!

from capsule.

Absolutely. My goal is to address the use case you're describing, but I want to make the cache transparent because there are cool things ahead for Capsule, like containerization, FUSE file systems (so no cache would be required at all) and more -- which will make the cache an implementation detail that a capsule might or might not use at all.

I would like a shared cache to work, and it will (but it will probably not be an ideal approach); for permissions, I figure that copying the parent directory's permissions should work.

I'm also considering deleting the cache after each run, and making the cache private to the specific capsule process.

from capsule.

Hi @pron,

I like the approach of scoping the cache to the process, or more generally, the idea of finding a way to avoid the cache. As with all synchronization issues, avoiding the need to synchronize is usually the best approach :]

Thanks!

from capsule.

Can you please try the new development build (1.0-rc1)? It's up on sonatype snapshots if you don't want to build it yourself. It should handle your case by default: if there's no permission to write to the home directory, Capsule will create a temporary -- and unique -- directory under /tmp, which it would delete on termination.

from capsule.

Hi @pron,

Sorry for the late response. I will give it a look this weekend. I have moved onto another project at the moment, so I will be more sporadic in communication. However, thank you for looking into the issue. We have an open task here to complete the migration to capsule, and I will record any notes from this exchange, plus fixes in that task.

from capsule.

Any news? The issue should be fixed in the current release. I will close this issue for lack of activity next week. You'll be able to reopen it at any time.

from capsule.

Hi @pron,

Sorry for the late response. I have made a shift to a project that requires me to learn a ton of new skills, so I haven't been able to break away to test the change. However, thank you so much again for looking into this, and putting in a fix. Sadly, I will not have enough time in the near future to test it, so feel free to close it.

Thanks again!

from capsule.