Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I manage a web server that's running on Windows Server 2008 as a 64bit virtual host. All service software is running independently, and not as part of an AMP stack. The data drive has nearly filled up and my systems admin has provisioned a new virtual drive with more space. My task is to copy everything over from the old volume to the new volume.

When creating the volume, I ensured that it was created with the same volume type, file system, block size, etc. I stopped all the relevant services (Apache, MySQL, both of which run from C: but whose data is all located on D:, including logs), and copied all the files over.

From here, I've tried two different approaches to getting the services to depend on the new volume, and forget about the old. MySQL has no problems either way, but Apache can't start as a service using either method. Here's what shows up in the System event log:

The Apache2.2 service terminated with service-specific error Incorrect function

Nothing appears in error.log.

First, I tried simply changing the drive letters. I took the old D: and changed it to something arbitrary, and assigned D: to the new volume. This yielded the error above. I tried rebooting the server with the new drive designations, "just in case", but the same error occurred. Because I don't fully understand Windows mount points, I changed the drive letters back to what they were originally, and confirmed that the Apache service starts just fine.

Second, I tried simply updating all the Apache and MySQL configuration files. Every occurrence of "D:" (case-insensitive) was changed to F: (the new drive letter). I know the configuration files well, so I know I found every occurrence. The error above occurred again, exactly the same way. In order to get the web server back up and running, I reverted all the changes, and the services successfully started.

Some more information I gathered:

  • httpd.exe runs successfully when started not as a service, from the command line. There are no syntax errors.
  • Even if run from the command line, Apache will not start as a service (httpd.exe -k runservice).
  • The issue is probably not one of file access permissions. I spot-checked key locations (a couple of directories, log files), and the permissions were identical. However, I did not test this exhaustively.

One thing I have not tested is to try moving only one of the data and log locations to the new drive, while leaving the other as is. I didn't think that was likely to make a difference.

... That said, I don't actually know what's going on here. I can't think of any reason why Apache would be failing to run as a service just by changing the location of the log files and data.

I would very much appreciate any suggestions or advice on this matter. I'm happy to investigate further in response to suggestions. If any of you think it's worthwhile to try moving only one of the items (logs or data) as mentioned, I will try that. Likewise, if any of you think I've been too hasty discounting permissions, I will do a more thorough examination.

Any and all input is welcome! I've exhausted all my ideas.

share|improve this question
1  
Can you run the service with the new file locations using your test account instead of a system account? –  Keith Stokes Jul 17 '12 at 12:52
    
Keith, I was on my way to try your suggestion when another thought occurred to me, which appears to have resolved the issue! (I will post the answer.) I really appreciate your contribution, though -- thank you very much. –  nmjk Jul 18 '12 at 0:54
add comment

2 Answers

I just came across the same problem with mod_wsgi using WSGIPythonHome. From nmjk's answer, I decided to check the permissions and realized that the Apache user had no permissions for the WSGIPythonHome directory. After adding the proper permissions, Apache started normally.

Maybe it's worth double checking the permissions for all paths specified by the configuration and commenting out line by line any configurations which contain a path to figure out which one is causing the problem.

share|improve this answer
add comment
up vote 1 down vote accepted

The next day, within the allocated time slot for disabling the server's primary functionality, I went to try something new and had a new thought that ended up resolving the problem! The details are as follows, in the context of the steps I took.

I started out by repeating the second approach from the original question. I stopped the services, re-copied all the files (to catch modifications in the last day), and edited the Apache and MySQL configuration files to point to the new drive (F:). I confirmed that Apache was producing the same error. Since I already had the config files open, I decided to try what I didn't try initially (and really should have):

  • I reset the config files so they were back to original state, pointing to the old drive (D:).
  • I updated only the references to log files to the new drive (F:) and tested the Apache service -- same error as before.
  • I returned the log file references to D: and updated the data references to F: -- IT WORKED! Again, I really should have tried this yesterday. What I learned from this step was that it was the log files that were the problem.
  • Since there were only two files (access.log and error.log), I forced the permission changes: added/removed readonly (just in case), ensured the apache user had recursive write access through the directories, and to the files themselves.
  • Updated log file references to F: -- same error as before.
  • On a hunch, I renamed the two log files (a common technique for rotating log files) and attempt to start the service, expecting that new versions of the original file names would appear -- they did! The service started successfully! Victory!!

What I learned: actually, I'm not entirely sure. If I hadn't been so thorough with various steps of my investigation, I would suspect problematic file handles or something, but I can't see how that would be possible past a reboot. However, I have confirmed the value of not too quickly dismissing possibilities while troubleshooting a problem. As I mentioned in the question, I didn't think today's line of inquiry was likely to make a difference, and I still don't know why it did! But you can't argue with results.

Conclusion: my problem has been resolved but I don't know why. If anyone has a theory, please share it!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.