Hacker News Reader

Comment by jofla_net | Hacker News Reader

this is great thanks,

was just wondering, could something else remove the dir in between the if and then, before trap?

Just wondering about the atomicity.

The permissions on the parent and lock directory could restrict the access to a specific user and group, but yes, other processes could interfere with this locking if directed to do so.

One condition where this interference is helpful is a crash, where a @reboot entry in the crontab could:

  [ -d /your/lockdir ] && rmdir /your/lockdir

You would also not want to place the lock directory in /tmp or otherwise where other users could manipulate (or see) it. In Red Hat, there is a /var/run/lock directory that might be appropriate.

My biggest use case for directory locking in scripts is handling inotify events.

The problem with lock files and lock directories is that if the lock holder dies without cleaning up you now need to do something to clean up.

On Linux, this is why I always turn to using abstract sockets when I only need local locking. Only one process can bind and the kernel cleans up automatically on process exit.

You could do the same thing with TCP/UDP, but abstract sockets give you more flexibility in naming with 108 characters vs. being forced to use a 16-bit integer. Also it means you aren't using up a port that could otherwise be used for actual network communication.

Abstract sockets also make for a nice process existence monitoring mechanism since any processes connected to the bound socket are guaranteed to be immediately notified when the process dies.

Yes, but that is not a weakness in the locking.

Reply on news.ycombinator.com