Hi all,

I am a newbie to a number of technologies here, so i am seeking the kind of answers that are very detailed .

Background:
I have a FreeRadius/Postegresql installation that crashed at some point; reason to be that, Postegresql would not start, the error displayed was ...
(The issue was resolved by increasing the semaphore limits ).

Now, what does it mean exactly I googled this a little bit but always this term comes mentioned in some advanced programming context, I would like to understand what does it mean but in the context that i have mentioned above.

Thanks in advance .

Semaphores are a programming concept, not necessarily advanced. The wikipedia page on semaphores overview them well.

The important part there is that there was no space left and by adding higher limits, using more memory for this application, you were able to resolve the problem. Software applications report problems when they run out of available resources or memory, and these reports can vary when you reach system limits.

Other limits in Linux are things like the number of processes or the number of files allowed on a system which can be changed for applications where there are a number of concurrent processes running or if an application needs a number of open files in order to run. In this case, semaphore were being used, which is just another limit.

Therefore another resource to understand are the limits.conf where some of the system maximums are configurable.

1 members found this post helpful.

... and the key rationale for these limits is to avoid, say, "fork()-bombing," whether intentional or accidental. If your innocently buggy program goes into a loop acquiring semaphores or spawning processes or gobbling memory or what-have-you, it must be stopped before it impacts the system as a whole. (And, so that you can recognize that the problem exists(!), and fix it.)

Relational data base managers (RDBMS) make use of semaphores (and messages too) to insure that multiple users (or processes) do not clash when updating a table; the idea is the same as semaphores on railroads so that two trains do not use the same section of track at the same time, one waits, the other goes.

You may want to look at any applications you've written to see how many updates are happening at any given time rather than simply increasing the number of semaphores. PostgreSQL handles collisions pretty well (as do MariaDB/MySQL) but it's more or less up to you to do updates serially in your application software. Look to see if you have multiple processes updating the same table at the same time and consider using a single function to do the updates (or inserts or deletes) which will give the DBMS a better chance at not running out of semaphores. Also, if you've use semaphores in your programming but sure that when a semaphore has completed that it release the semaphore so you don't get overflow.

Have a look at what the [I]ipcs/I] utility show you. On a quiescent system (mine) you'll see something like this
Those semaphore arrays are managed by MariaDB in this case -- if you see a whole lot of them, that's a hint to look deeper, and, of course, simply increasing the size of space you need might be the right answer but so may looking into how you are updating from multiple processes.

Hope this helps some.

2 members found this post helpful.