Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
--------------------------------------------------------------------------------
Apache/1.3.39 Server at www.mapability.com Port 80
When I check in the Error Log, it says: '(24)Too many open files: couldn't spawn child process:'. How to determine what is causing this problem, and what is opening all these files? I have a number of active pages that access various databases - it could be any one of them. My server is running Apache. I also use MySQL and php pages. Maybe there is some script that is not working correctly, and is leaving open files - is there a way to find this out, and what would be the method of fixing it?
I never did determine a way to check which files were open, or if there was some way to close them again. Many search results suggested that I increase the limit of open files so that the error would go away, but that seemed rather a silly way to address the problem - I would rather find out what was causing it in the first place, and fix that. More searching, and I eventually found an interesting page on the Forum belonging to Gallery 2, the photo-gallery software that I use. It mentioned a problem that another user was having with the 'Too many open files: couldn't spawn child process' error, and suggested a simple fix. The pertinent answer read:
Our guess is that you used file / flock based locking ("site admin", bottom of the page has locking options).
If you used database based locking, an open file limit of ~100 should have been sufficient.
Of course, once I knew what the answer was, it was easy to find more occurrences, using a Search such as "too many open files" "gallery 2". I soon discovered that this was a 'Known Issue' for Gallery 2.
Tim Will Fix It
I made the change myself. Initially, the error still occurred, though not quite as much as before.
To change this yourself, login to your Gallery, and click on Site Admin >> General Settings. Down the bottom of the page is a section:
Locking System
Gallery uses a system of locks to prevent simultaneous changes from interfering with each other. There are two types of locking, each with its advantages and disadvantages. File based locking is fast and efficient, but won't work on NFS filesystems and will be unreliable on Windows. Database locking is slower but is more reliable. If you are unsure which to choose, we recommend using file locking. If you're getting many lock timeouts, you can try switching to database locking instead. It's ok to switch back and forth.
The default setting for 'Lock system ' is File, so change it to Database and click 'Save'. The problem started improving straight away, but took a few days before the system finally settled down again. No doubt a gradual improvement will be the same in your case, too.
How had this got there? After a lot of searching, and a lot of red-herrings, I finally tracked down the cause to my Blogging software, Movable Type. It turned out that when installed, its settings are such that all new entries to the Blog, plus all their indexes and archives, are stored in folders with permissions set to 777. All new files have their permissions set to 666. Is that a problem? Yes, because it allows ANYONE to write to those folders, as happened to me. This page: 'Securing your weblog - CGIWrap and SuEXEC' explains the problem in greater detail as well as describing the fix.
Basically, there are two things you need to do. First, you open your 'mt-check.cgi' page in a browser - you will find it in your 'mt' directory. If (and ONLY if) it tells you "(Probably) Running under cgiwrap or suexec" then you can add an extra layer of Security to your site, by adding some lines of text to your 'mt-config.cgi' file. All you do is to open the file with Notepad or similar (NOT a word processor) and add the following lines at the bottom:
#
#=ADDED TO SET CORRECT PERMISSIONS FOR FILES AND FOLDERS=
#
DBUmask 0022
DirUmask 0022
HTMLUmask 0022
UploadUmask 0022
Save the file, and try a new entry to your Blog. You will find that the new entry has its permissions set to 644, and the folder it is in has its permissions set to 755. SUCCESS !! Now all you have to do is to go through your site and set the permissions for all those older Movable Type entry-files and folders to the above value as well!
CAVEAT: The above worked fine for me. I make no guarantees it will work for you, so would suggest you alter things and test things one step at a time, and make sure you know how to recover if you have made a mistake.
]]>Upgrading a Gallery2 installation that has been installed with the Pre-Installer
If you are reading this before installing Gallery2, my advice would be NOT to use the Preinstaller. Just upload the files using an FTP program, and all will be well. However, my guess is that you are reading this after using the Preinstaller, are staring to panic, and have done a search for Help, just like I did. Here are some tips to help you. The answers ARE on the Gallery2 site, but they are not easy to find.
The Preinstaller is very good, and works well - there is no question about that. It makes uploading files very easy - no more worrying about FTP drop-outs, and wondering which files have been uploaded and which lost. But there's a sting in the tail. The problem comes from the fact that after it has done its job, all the files and folders that it used or installed, including the main Gallery2 folder, are now 'owned' by the System, not by you. This means that after your successful installation, when the Preinstaller recommends that you change the permissions (also called 'CHMOD') of the Gallery2 folder from 777 to 755, and you log in with your favourite FTP program or web interface (Cpanel, Vdeck etc) you will find that you get a message saying "/public_html/gallery2 chmod failed: Operation not permitted".
Oh my God - I can't access my own files?! A search of the Gallery 2 documents eventually located a page about the Gallery2:Preinstaller which tells me that I already have a tool on my site to help with this, at http://www.mysite.com/gallery2/lib/support/index.php?chmod But when you access it, you will be asked for your site password, so make sure that you have it handy. This password is not the one that you entered into the '$passPhrase = "";' line of the preinstall.php. It is not the line of text contained in the 'login.txt' file that you had to upload during the installation. If you lose your password, or forget it, or try the wrong one, the CHMOD Tool Page will then tell you 'Failed login attempts: 1 out of a total of 7', and so on, as in your panic, you keep trying to remember what you had originally entered. I have no idea what happens if you get to 7: maybe you will be locked out for good?? Best not to go there!
The CHMOD Tool Page trys to be helpful by telling you that your password can be found in your gallery/config.php file like this: $gallery->setConfig('setup.password', 'your password here'); BUT if the system is locked down as mine was, when you point your FTP program there, you will find that its permissions are set to 640, which means you can't view the file. It comes as no surprise to discover that you aren't allowed to change them either! Luckily, there is still one final option open - you must visit this page: Bharat's Cleanup Script. Unzip the file, and upload 'cleanup.php' to the same directory as your gallery2 folder i.e. if your folder is at www.mysite/gallery2 then you should upload the file to www.mysite/cleanup.php Point your browser at that page, and enter the path to your gallery2 folder i.e. /home/~you/public_html/gallery2 Press 'Go' and if you have the path set correctly, all the permissions will be opened up. You can then browse to your config.php file, and find out what your password is, which lets you access the Gallery Support. Use that to start the CHMOD Tool Page, and you will then be able to lock your Gallery down again, by making everything read-only. If you get Errors, use the Cache Maintenance Page, also from Gallery Support.
The Gallery will now work OK, even though you can't access it with an FTP program. Does this matter, I hear you ask? Well, no, I suppose it doesn't really matter. Those of us 'old-timers' from the days of 486's and 10MB hard drives will feel a little nervous that there are files on our servers that we can't access readily, but as long as the Gallery2 program works properly and doesn't introduce any security implications, then heck why not leave it alone?! The Gallery2:Preinstaller page does tell you how to upgrade a Gallery2 installation that has been installed with the Pre-Installer, so I guess its alright.
Deleting unwanted albums can be a bit of a nuisance, though, and it was that that prompted me to rip it out and start again. I was glad I did, before my Galleries got too complex. If your Gallery2 installation has only a few photos in it, I would suggest deleting it altogether too, then reinstalling by uploading the files with a standard FTP program. (I'm a big fan of SmartFTP, which is not only very capable, but is free for personal use.) It may take a couple of hours to get your Gallery2 installation back to where it was, but it will save you much more time than that in the long run, as well as a lot of hair-pulling.
]]>In the end, what prompted me to make the change was getting the whole site hacked. The hack took an evening to clean up. Actually, there were two hacks - one I hadn't even noticed before! I suspect that they got in through a loophole in the old blog software. Time to do something about this, and install something more secure. I chose to follow the safe route and do a completely new install of Movable Type 4, in a new folder. If this went wrong, I still had the existing setup to fall back on. It would also be easier to copy the entries from a working Blog.
Below are the Movable Type 4 Quick Start Instructions. I have added a few comments of my own...
If you are using a Linux or Unix Web server with all required components installed, follow these steps to install Movable Type:
Use a Web browser to connect to the Movable Type Download page and follow instructions there to download the Unix/Linux/Mac OS X (.tar.gz) release file to your personal computer.
I had a strange thing happen here: when I tried to download the file on my laptop, the 'Open File' dialog started, but the 'Save' button never appeared. When I tried on a computer at the office, all worked fine. I also tried to download the Windows .Zip file on my laptop, but it would only download a section of the file, never the full amount. Opening the file brought up a 'Corrupted Archive - Please Download This File Again' message. The .Zip file downloaded fine on the office computer. Just why I couldn't download properly on the laptop was something I never did work out. I wonder how many other people have encountered this?
Extract the Movable Type files from the release file into a new folder on your local computer. You will need a program that can uncompress and extracts tar files. If you don't have such a program, you can learn how to get one on the gzip home page, http://www.gzip.org.
Start your FTP program and connect to your Web server using your server login name and password.
Copy the mt-static directory from your local computer to the Web root directory on the Web server.
I'm a big fan of actual examples in instructions like this. Authors often forget that newbies don't have the same basic background information that they do.
If your website is called http://www.mysite.com, then you should upload the folder 'mt-static' to http://www.mysite.com/mt-static
Open the cgi-bin directory on your Web server. Make a new directory within it named mt. Copy all of the other Movable Type installation folders and files to the mt directory.
This means that you create a folder called 'mt' here: http://www.mysite.com/cgi-bin/mt and copy everything to it from the downloaded archive except the 'mt-static' folder.
A note about folder-names in Movable Type 4: It is easy to make an assumption that the 'mt-static' or the 'cgi-bin/mt' folders wil be the access point to your new Blog, and be tempted to change the names to something that suits you. This is not the case. During the installation of the Movable Type 4 software, you will be prompted to enter the name of your required base directory - a name you chose for yourself. For instance, say you would like your Blog to start from the address: 'http://www.mysite.com/myblog/' then you can just enter that value when specifying your new blog. Movable Type4 will suggest a folder name when you enter the Blog name, but it can easily be changed. One word of warning: say you wish your blog to be in a sub-directory, such as 'http://www.mysite.com/blogs/myblog/'. When you create the 'myblog' blog, you will find that Movable Type has placed the new folder in the root directory (i.e. 'http://www.mysite.com/myblog/'), not under the 'blogs' folder. You will need to move the 'myblog' folder to its proper location, and then point Movable Type to where it now is, by clicking 'Preferences >> Blog Settings >> Publishing', and altering the values in the 'Site URL' and Site Root' boxes, not forgetting to click the tiny padlock on the right that allows you to unlock the values.
Make sure all the Movable Type cgi files (files ending with .cgi) in the mt directory on the Web server have execute permission. You should be able to select these files and check their properties with your FTP program.
This means that you should set their permissions (also called CHMOD) to 755.
Start a Web browser and run the installation wizard by connecting to the following Web address: http://domainname/cgi-bin/mt/mt.cgi where "domainname" is the domain name for your blog.
Follow the instructions provided by the installation wizard, to complete the installation and set up your Movable Type user name, password, and blog name. If you encounter problems during the installation, see Troubleshooting Installation Problems.
I'm impressed! The installation went very smoothly, and I acheived a working Blog in just a few minutes. 10 out of 10 to Movable Type. On the downside, though, their documentation is nothing short of attrocious. To make the most minor of changes I had to spend hours searching around the internet for clues. The Movable Type documentation is split over several sites, and its not always clear which notes apply to MT3 and which to MT4. The Forum is of more help, but I quickly noticed that MANY questions are going un-answered. MT, with all its customers, doesn't seem willing to assign a company man to monitoring their feedback. I will certainly be posting a few how-tos here on this Blog from time to time: lets hope others do the same.