0

Environment

  • Ubuntu 16.04
  • C++

Use-case

  • Process A, constantly starting and stopping
  • B, a Child process of A, forked only once and is running 24x7
  • In other words: A starts, spawns B, A dies ( B orphan ), A start again ( at this point I don;t want B to be spawned again )

Problem at hand

How can I make sure that only a single instance of process B is being created, that is, although process A constantly start and stop.

NadavRub
  • 2,520
  • 27
  • 63
  • Have I got this right? The sequence is: A starts; B starts; A ends (leaving B an orphan); A restarts. At this point you do *not* want B to be started again. – Martin Bonner supports Monica Jan 24 '18 at 16:30
  • Yup, U got it right – NadavRub Jan 24 '18 at 16:31
  • 2
    Make B create a named pipe like `mkfifo("/tmp/singleton", 0666)`, if this command fails is because the pipe already exists meaning you already have a process B running. – Havenard Jan 24 '18 at 16:32
  • So in a way w/ this approach, 'B' is always created but quickly dies if the pipe already exist, right ? – NadavRub Jan 24 '18 at 16:33
  • Well you can check if the pipe exists before forking too if you want. I suppose this would be faster. – Havenard Jan 24 '18 at 16:34
  • @Havenard Why a fifo? More typical would be a directory (which also has atomic create-or-fail semantics) or a file with a set lock. – Alfe Jan 24 '18 at 16:34
  • 1
    @Alfe Because it disappears by itself if the process dies. – Havenard Jan 24 '18 at 16:35
  • https://stackoverflow.com/questions/6898337/determine-programmatically-if-a-program-is-running – newbie Jan 24 '18 at 16:35
  • @Havenard : If the FIFO disappears by itself when the creating process dies, you absolutely need process B to create the FIFO (because otherwise the first time A dies, it will take the FIFO with it). You *could* check before the `fork` *as well*, but that only optimizes start-up for not much benefit. If process B does an `exec`, there is no reason not to create the FIFO in the child process, but before the `exec`. – Martin Bonner supports Monica Jan 24 '18 at 16:38
  • @Havenard How come you think that? The fifo lingers on the file system like any other file after the process terminates. I just tested on my system to make sure my knowledge wasn't outdated. – Alfe Jan 24 '18 at 16:38
  • @Alfe Sorry, it disposes of itself after it is no longer attached to any input. Indeed, just creating the fifo is not enough, you have to `fopen()` it too with `w` mode. Once you close this handle the fifo disappears. Gotta do some testing that right now I don't have the time to, but pretty sure that's the way. Also because it's not a real file it doesn't mess with the hard drive, so there's that advantage over doing it with files. – Havenard Jan 24 '18 at 23:59
  • I have to disappoint you concerning hard drive: It _is_ a directory entry which is stored on the hard drive. It is also kept over reboots, and when you unplug the drive and attach it to another computer you can see it there. Opening the fifo in 'w' mode hangs until some else opens it for reading; you can avoid that using async io, but in any case, termination of the process ***does not*** remove the fifo from the file system. – Alfe Jan 25 '18 at 10:59
  • @Havenard Maybe your idea derives from using sockets. These are really not on any file system and will disappear as soon as the process is gone. But you wouldn't make them using `mkfifo()`. – Alfe Jan 25 '18 at 11:02

0 Answers0