Is It Good Practice to Use Mkdir as File-Based Locking on Linux

Is it good practice to use mkdir as file-based locking on linux?

IMHO this is a very bad practice. What if the perl script which created the lock directory somehow got killed during the critical section? Another perl script waiting for the lock dir to be removed will wait forever, because it won't get removed by the script which originally created it.
To use safe locking, use flock() on a lock file (see perldoc -f flock).

os.Mkdir and os.MkdirAll permissions

You can use octal notation directly:

os.Mkdir("dirname", 0700)

Permission Bits

+-----+---+--------------------------+
| rwx | 7 | Read, write and execute  |
| rw- | 6 | Read, write              |
| r-x | 5 | Read, and execute        |
| r-- | 4 | Read,                    |
| -wx | 3 | Write and execute        |
| -w- | 2 | Write                    |
| --x | 1 | Execute                  |
| --- | 0 | no permissions           |
+------------------------------------+

+------------+------+-------+
| Permission | Octal| Field |
+------------+------+-------+
| rwx------  | 0700 | User  |
| ---rwx---  | 0070 | Group |
| ------rwx  | 0007 | Other |
+------------+------+-------+

A Unix Permission Primer

Common Permission Usages

0755 Commonly used on web servers. The owner can read, write, execute. Everyone else can read and execute but not modify the file.

0777 Everyone can read write and execute. On a web server, it is not advisable to use ‘777’ permission for your files and folders, as it allows anyone to add malicious code to your server.

0644 Only the owner can read and write. Everyone else can only read. No one can execute the file.

0655 Only the owner can read and write, but not execute the file. Everyone else can read and execute, but cannot modify the file.

www.maketecheasier.com/file-permissions-what-does-chmod-777-means/

Directory Permissions on Linux

When applying permissions to directories on Linux, the permission bits have different meanings than on regular files. (source)

Read bit The user can read the file names contained in the directory.

Write bit The user can {add,rename,delete} files names IF the execute bit is set too.

Execute bit The user can enter the directory and access the files inside.

https://unix.stackexchange.com/a/21252

Permissions Calculator

A handy permissions calculator.

What is the best way to ensure only one instance of a Bash script is running?

If the script is the same across all users, you can use a lockfile approach. If you acquire the lock, proceed else show a message and exit.

As an example:

[Terminal #1] $ lockfile -r 0 /tmp/the.lock
[Terminal #1] $ 

[Terminal #2] $ lockfile -r 0 /tmp/the.lock
[Terminal #2] lockfile: Sorry, giving up on "/tmp/the.lock"

[Terminal #1] $ rm -f /tmp/the.lock
[Terminal #1] $ 

[Terminal #2] $ lockfile -r 0 /tmp/the.lock
[Terminal #2] $ 

After /tmp/the.lock has been acquired your script will be the only one with access to execution. When you are done, just remove the lock. In script form this might look like:

#!/bin/bash

lockfile -r 0 /tmp/the.lock || exit 1

# Do stuff here

rm -f /tmp/the.lock

PHP flock() alternative

There is no alternative available to safely achieve the same under all imaginary possible circumstances. That's by design of computer systems and the job is not trivial for cross-platform code.

If you need to make safe use of flock(), document the requirements for your application instead.

Alternatively you can create your own locking mechanism, however you must ensure it's atomic. That means, you must test for the lock and if it does not exists, establish the lock while you need to ensure that nothing else can acquire the lock in-between.

This can be done by creating a lock-file representing the lock but only if it does not exists. Unfortunately, PHP does not offer such a function to create a file in such a way.

Alternatively you can create a directory with mkdir() and work with the result because it will return true when the directory was created and false if it already existed.

Is mkdir() atomic with AWS Elastic Block Storage as it is on local POXIS filesystems?

Since EBS is not a filesystem...

Amazon Elastic Block Store (Amazon EBS) provides block level storage volumes for use with EC2 instances.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html

...there is no direct answer to the question, because it isn't the correct question. EBS -- as a block device -- is not responsible for or even aware of the actual filesystem operations or its guarantees.

tl;dr: If mkdir() is atomic in the filesystem you are using, then it will still be atomic if that filesystem is on an EBS volume.

Whether using mkdir() for locking is a good practice is a different question.

Reference for proper handling of PID file on Unix

As far as I know, PID files are a convention rather than something that you can find a respected, mostly authoritative source for. The closest I could find is this section of the Filesystem Hierarchy Standard.

This Perl library might be helpful, since it looks like the author has at least given thought to some issues than can arise.

I believe that files under /var/run are often handled by the distro maintainers rather than daemons' authors, since it's the distro maintainers' responsibility to make sure that all of the init scripts play nice together. I checked Debian's and Fedora's developer documentation and couldn't find any detailed guidelines, but you might be able to get more info on their developers' mailing lists.

file locking in php

You should put a lock on the file:

$fp = fopen($updateFile, 'w+');
if (flock($fp, LOCK_EX)) {
    fwrite($fp, 'a');
    flock($fp, LOCK_UN);
} else {
    echo 'can\'t lock';
}

fclose($fp);

Bash script to check if running

You could write the script's PID into a file with echo $$ > /var/run/rsync_job.pid

Then when you start you could first check if that file exists, and if it does read the PID from it and see if that process still exists like

if ps -p $PID &>/dev/null; then
    # it's still running
    exit
fi

Why I cannot create directory in makefile?

The first problem is that DLL isn't defined anywhere.

The second problem is here:

OBJ = $(patsubst %.cpp, %.o, $(SRCS))

See the space after the first comma? It looks innocuous, but it means that the variable OBJ winds up containing myfunc.o, which also looks harmless, until you construct _OBJ which turns out to be ./obj/ myfunc.o, which trips up the compiler.

The third problem is that Make will execute the $(_OBJ) rule before the $(DLL) rule, so the compiler must use the obj/ directory before it exists.

The last problem (I hope) is that you seem to be passing $(CFLAGS) as arguments to the archive-maintaining program, when you should use $(ARFLAGS) (and make sure it actually contains what you intend).

---

Related Topics