0

I have three tasks that run on a Microsoft Windows 2008 RS Standard Server using its Task Scheduler program. All three tasks' jobs are to trigger a PHP script that sends emails. Two run in the morning, while the other one runs at night.

One of the tasks that run in the morning times out randomly day to day, looks like dating from early January of this year, possibly more as this script has been in place on the server since 2018, created back in early 2010s (not by me - a previous developer).

enter image description here

I'm not sure if task's timing out results in missing data (from a MySQL database) on the sent emails.

I'm thinking maybe it's the PHP script that is associated with the task that may be the problem source. I saw this answer, here.

  • Where can I view the scripts' exceptions? and I don't have access to Powershell.
  • Could it be that the amount of data that is processed by the script, task scheduler times out before its finished?
  • Is it the age of the server?
  • Are there other reasons why this could be happening, or it could be a combination of things?

The other two tasks run just fine for the most part.

I'm not a system admin, I'm just a simple web developer trying to figure out what's going on with missing data on some emails.

hnewbie
  • 151
  • 1
  • 15
  • You can set a timeout in many places, from task scheduler itself to anywhere inside the PHP script. Also, some people think that PHP needs to run on top a web server so they add one or two extra layers (Apache, IIS, cgi-bin...) of potential time outs. – Álvaro González Jul 01 '20 at 15:06

1 Answers1

0

You can find the script's exceptions in the error log. You can find more info on how to locate it in this answer.

It definitely could be the amount of data the script has to process, especially in larger applications it is not uncommon for tasks to take hours to complete.

Personally, I would examine the age of the server (and other hardware parameters) after ensuring that everything is ok on the software side.

Also, I find it really useful for debugging to write execution logs to a file (other than the error log). So for example if there is a line I would expect to cause issues I put some logging info before it runs and some more after it runs, just to know that it ran without problems.

This way you end up with a file that contains a summary of everything that happened in each execution. If you go that way, proceed with caution because these files a) can take up a big amount of disk space and b) may end up containing sensitive information. Just keep the logging on until you find the issue and then remove both the logging code and the logs.

anpel
  • 931
  • 6
  • 16