Stupid Coldfusion

At work we run a severly outdated version of Coldfusion. It was out programming language of choice until 3 years ago when we switched to ASP.net. Our Time and Leave accounting system run on Coldfusion, so it is important, particularly when timesheets are due. Which was yesterday, so of course the system decided to give up the ghost.

Not the whole system, to be honest, just the email part, which is not critical to the functioning of the system, but without the notification, some people lose their ever-loving mind.

Troubleshooting:

  1. What changed?
  2. Two weeks ago, I made a change to our unauthenticated mail server. Long story short, the server that was being used shouldn’t be, so it was corrected. DNS was changed to point to the correct server. No other issues related to this had been reported.
  3. Where is the problem initiated?
  4. I checked the mail spool in the Coldfusion directory and yep, there are the messages not being delivered. Checking the logs, it appears that the Coldfusion server is trying to talk to the mail server that is listening on port 25. Hmm.
  5. Why?
  6. After scratching my head, I check the resolv.conf file and see two entries. One, 127.0.0.1 and the other the correct DNS server. Weird.
  7. Oh… wait…
  8. The Coldfusion server used to be the primary DNS server, running Bind. Time to edit the /var/named/db.cnu.edu. Once I made the change, I tried moving a message from Undelivr to Spool, but still nothing. Then I modified a mail message, pointing it to the correct server and moved it to Spool. Success! But anything pointed to the old server, not so much. So, I edited the Coldfusion files that send the notification, hard coding the correct mail server, but that doesn’t solve all of my problems. A couple of nslookups later, and I have a sinking feeling that Coldfusion has it’s own DNS cache, and how ever ours is configured it is not updated, even after two weeks.
  9. Grr…
  10. I tried to restart the Coldfusion server by running sudo /opt/coldfusionmx7/bin/coldfusion restart, but it didn’t work. It couldn’t stop, so it just kept on running.
  11. Fine.
  12. We can do this the hard way. ps -ef|grep coldfusion and then pkill the process id. Luckily the daemon was set to -autorestart. It came back up like a charm. Again with the moving of the .cfmail message to the Spool.
  13. Success!
  14. Profit (?)
  15. I have to move all of the files from the Undelivr folder to the Spool, becuase it would be too much of a headache to have everyone resubmit their timesheet to kick off the notifications. I only want the undelivered messages from today, not all of them dating back to 2007.
  16. find . -type f -mtime 0 -exec sudo mv -i {} ../Spool ;
  17. Boom!