0

I've been searching for how to guarantee that only a single instance of my application will run on Linux. The advice I see offered as "best" is to open a file and then try to lock it. But it's also possible to do this by opening a named POSIX semaphore and requesting exclusive access. To my Windows-addled brain, this seems like the better approach. Can someone explain the disadvantages of this approach and why file locking is preferrable?

Peter Ruderman
  • 12,241
  • 1
  • 36
  • 58
  • 1
    How are you planning on sharing the semaphore between processes? – Jimmy Johnson Jan 16 '13 at 18:48
  • 1
    My understanding was that if two processes call sem_open with the same name, then they will end up opening the same semaphore. See here: http://www.kernel.org/doc/man-pages/online/pages/man7/sem_overview.7.html. Have I misunderstood? – Peter Ruderman Jan 16 '13 at 18:53
  • Ah you learn something everyday. I didn't realize this was possible but after looking at the man page, it looks like the only difference is that it is creating it in memory rather using the file system. The only reason I can think of is that files are just 'easier' to set up and delete if something goes wrong. – Jimmy Johnson Jan 16 '13 at 19:00
  • I recently explored linux and POSIX semaphores, and as far as I know, your proposed approach would be appropriate for running a singleton application on linux. I would prefer that to file locking due to the complications of resource sharing between processes, as BeenCoding2Long mentioned. Curious, can you provide a reference to the file-based approach being described as better? – taz Jan 16 '13 at 19:06
  • Sure. Look no farther than this site. See Charles Duff's answer here: http://stackoverflow.com/questions/220525/ensuring-a-single-instance-of-an-application-in-linux or the accepted answer here: http://stackoverflow.com/questions/5339200/how-to-create-a-single-instance-application-in-c – Peter Ruderman Jan 16 '13 at 19:11
  • 1
    Semaphores will persist until system shut down, whereas file locks will be removed if your process dies for any reason. In the former case, your process dying (i.e. not calling `sem_unlink()` ) will effectively prevent you from starting your program again without rebooting... – Karl Barker Jan 16 '13 at 19:15
  • @KarlBarker Is there any way to work around that? Isn't using a PID file lock potentially subject to a race condition? – taz Jan 16 '13 at 19:22
  • @KarlBarker: I see. So that's the key difference between a POSIX semaphore and Windows. In Windows, the semaphore is removed once all handles to it are closed. But a POSIX semaphore won't be removed until someone explicitly calls sem_unlink(). You should post your comment in an answer, so I can accept. – Peter Ruderman Jan 16 '13 at 19:23
  • @PeterRuderman It may be possible to accomplish this with System V semaphores. From http://www.kernel.org/doc/man-pages/online/pages/man2/semop.2.html: "Flags recognized in sem_flg are IPC_NOWAIT and SEM_UNDO. If an operation specifies SEM_UNDO, it will be automatically undone when the process terminates." – taz Jan 16 '13 at 19:31
  • @taz that 'undo' is not referring to destroying the semaphore, it's undoing the `semop()` the flag is associated with. – Karl Barker Jan 16 '13 at 19:36
  • @KarlBarker I know...I assumed that one of the possible undo-able commands for `semop()` was the creation of the semaphore. Glancing at `semctl` I'm not sure that's the case. It seems there could be ways using controller processes to check whether a process was responsive and remove its semaphore if it wasn't...but this is an added layer of complexity that basically achieves the same thing as using the PID file lock. I somehow missed the distinction this question raises when I researched System V and POSIX semaphores. – taz Jan 16 '13 at 21:40
  • 1
    I dislike code, which pretends to know, that the customer will never want to use more than one instance. The only think that I can imagine is code bound to some exclusive use of some resource -- e.g. a screensaver to a screen -- but even in this case the exclusive opening of the matching resource should make certain of that -- everything else is pretending to know more than the system. –  Jan 03 '14 at 21:26
  • I haven't used these `sem_open` semaphores, but for the past two decades or so I've always assumed that surely they must be a more intelligent replacement for the SysV stuff, which nicely cleans up after the last process goes away. It bears the `open` and `close` terminology and all. **Oops, no, same old cluster-fumble!** Good grief, ... – Kaz Jun 20 '17 at 04:33

1 Answers1

3

From the kernel.org page you posted:

Persistence
      POSIX named semaphores have kernel persistence: if not removed by
      sem_unlink(3), a semaphore will exist until the system is shut down.

If your process dies before explicitly calling sem_unlink(), you will be locking yourself out from opening your application again until you reboot.

If you were using file locks however, they would be released when your process ends for any reason (as mentioned in an SO question you also linked)

Community
  • 1
  • 1
Karl Barker
  • 11,095
  • 3
  • 21
  • 26
  • 1
    ipcrm(1) will save you from the reboot - but yes, some manual actions will be needed, and in that sense the lock file solution would be preferable. – Juha Laiho Jan 16 '13 at 19:45
  • I wonder what the intended use is for such semaphores?! Potentially reference counting was not yet invented when this was designed? –  Jan 03 '14 at 21:20