Linux lock file exists

GIT: /.git/index.lock’: File exists

I have tried: rm -f ./.git/index.lock as per another thread on stackoverflow but I get this error each time: rm: cannot unlink `./.git/index.lock’: Permission denied When I close down aptana (I am using git in the terminal) I cannot delete the file still. Any ideas how to get around this? Another thing to note is this git repo is very slow when I do occasionally get to commit within it (it allows me every 10 tries or so) Thanks

Do you have root or superuser access to the system you are using? In other words, do you own the computer or are you on a public computer, such as in a campus lab?

these commands are for unix and osx systems. you can go to the index.lock file in the explorer and delete it. if you dont see .git folder. you need to set show hidden files in your file folder manager first

7 Answers 7

Both errors suggest index.lock is owned by another user. Run the rm as a superuser, then try your commands again. You might also consider setting core.sharedRepository to true if that is, in fact, the case with your repo:

core.sharedRepository

When group (or true), the repository is made shareable between several users in a group (making sure all the files and objects are group-writable).

When all (or world or everybody), the repository will be readable by all users, additionally to being group-shareable. When umask (or false), git will use permissions reported by umask(2). When 0xxx, where 0xxx is an octal number, files in the repository will have this mode value. 0xxx will override user’s umask value (whereas the other options will only override requested parts of the user’s umask value). Examples: 0660 will make the repo read/write-able for the owner and group, but inaccessible to others (equivalent to group unless umask is e.g. 0022). 0640 is a repository that is group-readable but not group-writable.

See git-init(1).

False by default.

Источник

Linux lockfile explained, how to use them the easy or hard way

You may have experienced it before, you create a cronjob to change some data every X hour or minutes and one day this job takes longer than it usually does and cron spawns another job before the first one is finished.
This can result in data corruption or deletion of data that should not have been deleted, all depending on what the cronjob is set up to do
To prevent bad things from happening, a good rule of thumb is to always use a lockfile
A lockfile is a small file, it virtually takes up no space, at least so little you won’t care (The actual size depends on your filesystem). Sometimes it contains a PID, sometimes a timestamp or just plain empty. Depending on how the lockfile is managed

How lockfiles work

There are multiple ways to write a lockfile, i’ll explain the basics of a lockfile here, in two different ways

Empty file

The first and most simple way is to make your script/program check if a file exists at the beginning of a script, let’s say the filename is /var/lock/myscript.lock
If the lockfile exists, then just exit the script since it seems like the script is already running based on the existence of the lockfile. However if the lockfile does not exist, then create it and continue on with doing what the script has to do
When the script is done doing it’s job, the lockfile has to be deleted before the script exists
That’s basically it, the lockfile is just a file indicating that the script is already running. However this method with just an empty file has one big problem and advantage.
If the script fails and exits before it gets to delete the lockfile, the script will never run again before you go in and delete the lockfile manually, or if your server reboots/crashes while the script is running you will have the same problem
However that is not necessarily bad and can be useful in some cases. Sometimes your script may be written to do some changes that can not be restarted if interrupted before it’s finished, in this case this type of lockfile is a must because the script will not restart on it’s own before you delete the lockfile manually to let it

Lockfile with PID

Let’s say your script name is myscript.sh and the lockfile is located at /var/lock/myscript.lock
If the lockfile exists, your script will read it to see if it has any content, if it finds data in the file, the script will assume it’s a PID (Process ID, every process gets an ID. The ID is just a number starting from 1 which is incremented by 1 for every process spawned) and check if a process with that ID is running
If no process with the PID from the lockfile is found or the lockfile does not exists at all, the script will create the lockfile with the current running scripts PID (Process ID) as the content of the lockfile. Nothing else, just the PID
This way, you do not have to delete the lockfile when done, and in case of a script or system crash your lockfile will still be there, but it does not matter since the script with the PID from the file is no longer running so when the script runs again, it will not find it doing the check at the beginning and therefore write the new PID into the lockfile and continue on with it’s job
I have used this method in multiple scripts and even though it has some downsides, for example if a process with the same ID is spawned (PID’s are reused when you hit the max). But I have never run into any problems like this

Lockfiles the “hard” way

I call it the hard way because it requires you to add some code to your script, it’s not really hard but it’s not as easy as the easy solution further down in this post, but it helps people who are new to lockfiles to understand how it works
Adding the following code on top of a bash script will:

1. Create the lockfile if it does not already exists
2. Read the data from the lockfile
3. Check if a process with the PID matching the data from the lockfile is running
4. If no process with the PID is running, then write the current PID to it
5. However if a process with the PID from the lockfile is running, then just exit the script

Here is the code for a bash script with comments:

# Variable to hold the location of the lockfile lf=/var/lock/myscript.lock # Create empty lock file if none exists touch $lf # Read the content of the lockfile into a variable read lastPID < $lf # If lastPID is not null and a process with that pid exists, exit the script [ ! -z "$lastPID" -a -d /proc/$lastPID ] && exit # Write the PID of the current running script to the lock file echo $$ >$lf # Your code goes here and will do it's job from this point on. No further code related to the lockfile is needed

And here is the code to use just an empty lockfile:

# Variable to hold the location of the lockfile lf=/var/lock/myscript.lock # Check if the lockfile exists, exit if it does [ -f $lf ] && exit # Create the lockfile touch $lf # You script has to do it's job here # At the very end of the script or before it exists, delete the lockfile rm $lf

Lockfiles the easy way

Above i showed you how a lockfile works, and the “hard” way to manage them
Now let’s look into the easy way. This method however required you to install a tiny program that is in the official repositories
The program is called “flock”
To install flock run the following command:
Debian:

Once installed, it’s really easy to use with the following syntax:

/usr/bin/flock -n /path/to/lockfile.lock /path/to/myscript.sh

the -n makes flock exit in case the script is already running, without the -n flock will wait until the first process is done
That’s it, flock will handle it all for you then, just run the script with flock in front of it every time you run it and you will be safe from the script accidentally running multiple times in parallel

4 thoughts on “ Linux lockfile explained, how to use them the easy or hard way ”

1. Nicolaas HyattJune 13, 2016 at 6:33 am Process ID numbers start at 1 and increase, but they have an upper limit depending on the system and configuration. You need to take this into account and add a test to see if the process that has the ID is the same as the script that created it.
   That way if another process is using the same PID your script won’t prematurely terminate.

Источник

Using lock files in a bash shell script

Wrote this script recently – I had written a simple shell script that updated an HTML page with its output, then realised it would be all too easy for simultaneous writes to clobber the file.

This kind of concurrency can & should really be solved properly by using a database obviously, but it got me thinking and playing around and I ended up with the below – it’s clearly very “happy path” with loads of room for improvements – please feel free to suggest some or add to it 🙂

#
# Example script that uses lock files to avoid concurrent writes
# TODO: loads more validation and error handling!
#
# www.DonaldSimpson.co.uk
# 25th May 2011

setup_lockfile() # set name of this program’s lockfile:
MY_NAME=`basename $0`
LOCKFILE=/tmp/lock.$.$$
# MAX_AGE is how long to wait until we assume a lock file is defunct
# scary stuff, with loads of scope for improvement.
# could use fuser and see if there is a process attached/not?
# maybe check with lsof? or just bail out?
MAX_AGE=5
echo «My lockfile name is $»
sleep 1
>

check_lock() # Check for an existing lock file
while [ -f /tmp/lock.$* ]
do
# A lock file is present
if [[ `find /tmp/lock.* -mmin +$` > «0» ]]; then
echo «WARNING: found and removing old lock file. `ls /tmp/lock.$*`»
rm -f /tmp/lock.$*
else
echo «A recent lock file already exists : `ls /tmp/lock.$* | awk -F. `»
echo «Will wait until the lock file is over $ minutes old then remove it. »
fi
sleep 5
done
>

create_lock() # ok to carry on. create a lock file — quickly 😉
touch $
# check we managed to make it ok.
if [ ! -f $ ]; then
echo «Unable to create lockfile $!»
exit 1
fi
echo «Created lockfile $»
>

cleanup_lock() echo «Cleaning up. »
rm -f $
if [ -f $ ]; then
echo «Unable to delete lockfile $!»
exit 1
fi
echo «Ok, lock file $ removed.»
>

setup_lockfile
check_lock
create_lock

# Any calls to exit() from here on should first call cleaup_lock
# Do main processing tasks here.
sleep 20

Share this:

Источник