1

Within a Linux Box I'm using named semaphores to control access to system resources used by different processes.

If the system accidentally crashes, it can happen, that a semaphore has been acquired but not given back yet. Given that situation, I noticed, that even after a reboot the semaphore remains still in a locked state.

To overcome such situation, would it be ok, to unlink the semaphore at system startup before it is used again by one ore more processes? Or would it be better to give it a sem_post() until the semaphore is released?

BTW:

Where are semaphores stored internally. I wonder why they survive system reboots.

MichaelW
  • 1,328
  • 1
  • 15
  • 32

1 Answers1

4

Your second question (Where are semaphores stored internally...?) is answered here: sem_overview(7)

In a nutshell, the named semaphore objects are stored on a virtual file system. By design, they survive until the system shuts down or until they are removed with sem_unlink(3).

A little bit of Google research indicates that the problem you're seeing is not uncommon. If the system crashes, the semaphore persists as you've seen.

It's enough of a problem that some folks even come up with alternatives for using semaphores altogether, see for example: How do I recover a semaphore when the process that decremented it to zero crashes?

As for your first question, I would draw a parallel to writing to a file and having the process or system crash while doing so (or having written to a file and the contents haven't flushed to disk yet). The state and integrity of that file are unknown at that point.

Comparing that scenario to your semaphore problem, I believe deleting the rogue semaphore at system startup is your best bet.

Community
  • 1
  • 1
Phil Brubaker
  • 1,257
  • 3
  • 11
  • 14