Re: [Boost-users] [boost] [interprocess] Semaphore cleanup after crash

Ion, I was wondering whats your take on this. Is it something that can/should be added to boost or would you prefer that I just hack it in my code only? Sachin Garg On Wed, Jul 30, 2008 at 12:50 AM, Sachin Garg wrote:

On Tue, Jul 29, 2008 at 11:33 PM, Sachin Garg wrote:

...

On Tue, Jul 29, 2008 at 10:32 PM, Ion Gaztañaga wrote:

...

Sachin Garg wrote:

...

If a semaphore is not in-use (open) by any process, in this case (in my application) I can safely 'remove' it and start afresh. Is there some way to find out if any process is using a semaphore at a time so that I can call 'remove'?

Inteprocess is modeled after posix primitives, so there is no way to know if someone is attached. Think about this as if the semaphore was a file. What would you do if you are communicating two processes with a file and one process crashes? I think you should have some keepalive mechanism to detect that a process has died and recreate ipc mechanisms on failure.

Yep, I understand this is the posix way of removing everything, be it semaphores or other stuff. By keepalive do you mean having an umbrella process to take care of recovering from such crashes? Or is it some other standard mechanism that I am not aware of?

...

...

When I just add a 'remove' on process start this works great on windows (as remove just fails if another process has the semaphore open), but on linux sem_unlink is used which has the behavior of deleting it even if its in use.

This same problem happens with std::remove(const char *filename) (windows version fails if the file is in use but unix version calls unlink and removes that file from the filesystem without failing while attached processes still write to that phantom file) but this is a difference I don't know how to solve.

Yep. I tried forcing use of interprocess' cywgin and windows implementation of named_semaphore on linux (just for experimenting) as these are done differently. Windows one fails to compile and cygwin implementation fails as that uses shm_unlink which works same as sem_unlink, the posix way :-)

...

...

What is the general practice when it comes to cleaning up semaphores after process crashes? Maybe some way to ensure that 'post' and 'close' are always called even when application has otherwise crashed? Is there some way to use boost's windows style semaphores on linux instead of native posix style?

I tried looking and many have asked this question (in context of recovering from posix semaphores, which are used by boost on linux), but I couldn't find any answers. Lars had asked this here also, almost an year ago but no answers in that thread either. This seems like a basic issue but am totally lost on how to even approach it.

In general I see no general solution. You can't register cleanup actions when a process crashes (well, the OS can, but not the user code). If anyone has any idea about this, I would be glad to hear it.

The method discussed with Bob (in same thread), does that makes sense? To programatically do what he proposes using commands.

I am not aware of system calls for this but it seems possible (ipcs does this 'somehow') to find which process last used a semaphore and then it can be checked if that process id is still alive, and only then we can call sem_unlink. All this can be abstracted with boost in a smart_remove or a safe_remove. Idea being to sem_unlink only when no other process is using it.

If it doesn't looks like something of too much general value (though I think it would be) I would atleast like to do this in my code, so any pointers to relevant system calls will be really really helpful.

Thanks for all the great work done in interprocess.

ps. I figured something can be done using semctl/semget etc but they need sem's set id as parameter. Haven't yet figure out how to find that id for a posix named semaphore.

Sachin Garg