Ramblings from MostlyChris

If you run into semaphore issues….

First, determine the number of semaphores in use.

Then determine the current settings in the kernel for the number of semaphores.

Look at the 4th field. It shows the maximum number of shared memory segments for the entire system. If your number of semaphores in use is higher than this number, you will need to increase it. You do this in increments of 128. For example, if your ipcs output is 267 and your kernel settings are '384 64000 64 256' then you have exceeded the number of available shared memory segments.

Add increments of 128 to each of the numbers to exceed what the system is currently using. In this case, you can just add 1×128 so your new values would be: '512 64128 192 384'.

Edit /etc/sysctl.conf and look for "kernel.sem=". Add your new values here, replacing what is here (or better yet, comment the line and add a new one with the new values).

Once you have added this, all you have to do (on a Redhat box) is to issue

in order to use the new values.

First of all, let me apologize for not having any pictures to go along with this article. I was in a hurry to get the MacBook to start up and had to just do it. This deals with a white MacBook in the 2007 vintage.

There have now been two occassions in which the MacBook would not turn on after shutting it down or if it did turn on it was only for a few seconds and then turning it off and back on again resulted in nothing.

It turns out that the fix for this is relatively simple. The first time it happened it took a lot of hunting and searching to find out what was going on. There were suggestions about the power control board and the motherboard and all sorts of other things. This is what I found (I will do my best to use word pictures).

I removed the battery. Inside the battery compartment is a silver strip of metal along the side of the compartment. This strip is "L" shaped and runs along two sides of the compartment. There are three tiny "phillips" screws along the long side of the metal strip. Remove those three screws. The strip then comes out, long side first.

Once you remove the strip, you will see two memory card release handles. Pull those sideways and the memory card comes out far enough to be removed. I pulled both cards out, paying attention to which way they belong on the slots.

Along the metal contacts was a white substance that looked like heat sink compound. It completely coated both of the cards along the connector edge. I have no idea what the substance is or if it is even supposed to be there. Thinking this was the problem with the MacBook, I used rubbing alcohol and cleaned the gunk off. I further cleaned the contacts with a standard pencil eraser. I did this for both memory cards and then inserted them back into the slots. It takes quite a bit of force to get them seated properly. Once I did this and put everything back together, the MacBook started up and has been running worry free for the last year or so… until two days ago. The MacBook was turned off and would not come back on. At all.

Once again, I pulled the memory cards. Both of them had a very fine layer of the white substance on them. It was almost invisible. I took an ordinary pencil eraser and cleaned the contacts. I turned on the MacBook and it's working again.

I have no idea what the substance is. I've heard rumors that it might be an anti-shorting compound or something. However, it definately interferes with the correct operation of the MacBook.

Remember, do these steps AT YOUR OWN RISK. I make no guarantee that this will solve your issues.

I was installing APC on a server and ran across this error:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 92160 bytes) in /usr/share/pear/PEAR/PackageFile/v2/Validator.php on line 1831

One would assume that fixing this would be to edit the php.ini file and change the memory settings. However, that is not the case here. In order to fix this, you would edit /usr/share/pear/pearcmd.php and add the following line to the very top of the file (after the opening PHP tag):

Adjust the memory limit to what you need. For good measure, I remove that line once I am done installing whatever it is I need to install.

Recently, I ran into an error while attempting to install a PECL package on a Redhat 5.3 64bit server.

—-
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 23040 bytes) in /usr/share/pear/PEAR/Builder.php on line 263
—-

I checked the memory limit setting in /etc/php.ini and it was set for 16M so that wasn't the problem. This is happening because PECL requires more memory on a 64bit box than a 32bit one. Incidentally, this works fine on 32bit OS's.

There are a couple of ways to get around this. The first would be to place the following at the top of the /usr/share/pear/pearcmd.php file:

Alternatively, you could could add the following to /usr/bin/pecl:

16M should be plenty. However, if you still don't have enough memory then up the number to 32M. If that isn't enough, something else is going on.