Fix wrong initial semaphore state

[aleksei-timofeyev]

If O_CREAT is specified, and a semaphore with the given name already exists, then mode and value are ignored. The value should be set to 1 in over case.

[aleksei-timofeyev]

@ihuerner please review.

[mdanilov]

@jeremiah We faced with this issue (rare occurence) on our project and think it's critical because if it is happened it may affect the whole functionality of persistence because it is the common component. In our case persistence administrator was not able to install the database.

[ihuerner]

l don't get the problem.
As you said, if a semaphore with the given name already exists, then mode and value are ignored.
This is the case here, why should I modify the ignored parameters?

[mdanilov]

@ihuerner Actually we had a case when semaphore does not exist, and in this case it was created with value 0 and then it was stuck on sem wait and failed due to timeout.

[mdanilov]

Despite of comment above (try to open existing semaphore), sometimes the semaphore does not exist when set_open is called, in this case it will be created with incorrect 0 value.

[ihuerner]

If the tests are still running successfully, I think we can accecpt the suggested modification.
Did you run the tests?

[gunnarx]

@mdanilov Did you run the tests?

[gunnarx]

@martin-ejdestig Have you run into this issue at all? What do you think, should this change be made?

[martin-ejdestig]

@martin-ejdestig Have you run into this issue at all?

Not yet. We (PELUX team) are basically trying to get persistence-storage working at all so that we can evaluate it.

What do you think, should this change be made?

I do not know. But... is the problem perhaps that there is a race condition here? It was a while since I used POSIX semaphores but if the semaphore exists when the first sem_open() with O_EXCL is called and then does not exist when the second call is made, it must have been destroyed with sem_unlink() from somewhere else between these calls.

So... I guess it is correct to have a 1 in the second sem_open() call since we always want the initial value to be 1. And the value is ignored if the semaphore already exists.

But then... if that is correct... why is this just not a single sem_open() call without O_EXCL instead of two? What is gained by passing O_EXCL the first time and leaving it out the second time? If something is gained by doing it this way... it can not be relied on... since the semaphore can apparently be destroyed between the two sem_open() calls.... it is racey.