LMS 3.2 and Apache

[sbrox]

Hi

I have installed LMS 3.2 on a 64 bit Windows Server 2003 R2 Standard edition with Service pack 2

The main problem is that the apache service will not start.
It seems like all the other ciscoworks services starts, but not the apache services.
How do I solve this problem?

[Joel Monge]

So far, we know the problem only occurrs after a reboot.  This should mean something is changing during reboot (domain/security policy - 3rd party app).  Since the error.log is logging now, open httpd.conf and look for this line:

ErrorLog D:/PROGRA~1/CSCOpx/MDC/Apache/logs/error.log

Just a few lines below you will see:

LogLevel warn

Change this to:

LogLevel debug

Then restart daemons.  Wait till Apache is up and gather new:

- pdshow

- netstat -anob

Then reboot the server again and gather:

- pdshow - wait until pdshow results are complete before gathering logs below

- CSCOpx\MDC\Apache\logs

- CSCOpx\log\syslog.log

With this, I can compare outputs after reboot and after daemon restart and try to establish a difference.

Message was edited by: Joel Monge

[Martin Ermel · Accepted solution]

according to your netstat output, it seems that Tomcat (TCP/9009) takes more than 20 min to start. If that is the case, this is too long for TomcatMonitor to wait for and thus it will not be started -causing other dependent processes (like Apache) to fail also.

I guess your virus scanner is the culprit of this issue. Just for a short test disable it and try to stop and start LMS (in a DOS box: net stop crmdmgtdand when it has finished, net start crmdmgtd)

If LMS is working now, you should configure the virus scanner to not touch the CSCOpx directory (at least for online scans).

edit:

Joel, I dropped in and didn't read the whole thread in detail, sorry  - but you clearly put the finger on this before and I agree with you that this is the most likely cause

[Joel Monge · Accepted solution]

Yes, Apache depends on Tomcat.  As I mentioned before, AntiVirus/security software is the most likely culprit here.  Since you cannot disable it due to security reasons, you need to setup an exclusion in McAfee for on-access scanning of the CSCOpx folder and all its subfolders.

In fact, I was just about to update this thread since just finished working with another customer with same issues and McAfee was at fault.  After adding the exclusion daemons came back up fine.  You need to make sure this exclusion still exists just before you restart daemons since it can get removed without noticing.  You also need to make sure the exclusion remains throughout a reboot so the problem does not happen again after reboot.

This is documented here for your reference:

https://supportforums.cisco.com/docs/DOC-9132

Mermel:

No worries, your help and anyone elses is always appreciated and we both came to same conclusion.

[sbrox]

Yes, the problem was coused by McAfee On-Access scanning.

After removing ....\CSCOpx from the On-Access scanning, everything is working OK.

Thank you for your help