search

github / codeql

CodeQL: the libraries and queries that power security researchers around the world, as well as code scanning in GitHub Advanced Security
https://codeql.github.com
MIT License
7.67k stars 1.54k forks source link

OverlappingFileLockException and permission issue #6543

Open xiaoxinz-cisco opened 3 years ago

xiaoxinz-cisco commented 3 years ago

Hi,

I was facing below error while running codeql cli:

Running queries.
A fatal error occurred: Error initializing the IMB disk cache: the cache directory is already locked by another running process. Only one instance of the IMB can access a cache directory at a time. The lock file is located at /scratch/workspaces/xr-ws/xr-git/iosxr-codeql-db/db-cpp/default/cache/.lock
(eventual cause: OverlappingFileLockException)
Finished running CodeQL CLI.

how can we avoid and resolve this issue?

Another question is, if we have two persons run ql on the same db, we noticed that there are always cache permission problems. For example, codeql-db is created by person A, but when B run a query, there are permission errors like

A fatal error occurred: Severe disk cache trouble (corruption or out of space) at db/default/cache/predicates/62.pack: Failed to delete file in disk cache (eventual cause: AccessDeniedException "/db/default/cache/predicates/62.pack”)
A fatal error occurred: Error reading generation info file: db/default/cache/cached-strings/pools/poolInfo (eventual cause: AccessDeniedException "db/default/cache/cached-strings/pools/poolInfo")
smowton commented 3 years ago

The first problem: is the database in use within VSCode at the time? Only one program can use it at a time, so you'll need to remove the database from VSCode (or close VSCode) before this will work.

xiaoxinz-cisco commented 3 years ago

Hi @smowton,

Thanks, I'm not running it within VSCode, using CLI instead.

smowton commented 3 years ago

Oh sure, I thought you might have VSCode sitting in the background. Does lsof | grep lock show you what process is holding that lock file?

smowton commented 3 years ago

Regarding using a database owned by someone else, it appears at least at the moment we create parts of the database with mode 600 (i.e., private to the creating user) as you've noticed. I'd recommend copying the database over to your own private copy first (since it includes private files, you'll want the owning user to make them visible to you, for example by making a tarball of the database that you can read).