Quantcast
Channel: [English] – Mind of Matt
Viewing all articles
Browse latest Browse all 92

How to fix that ISPConfig 3 does no longer process its job queue?

$
0
0

There are two main reasons for this: the next job causing an error, or a stale lock.

How to fix a job queue stuck with a job that causes an error

  1. Check for errors. Go to "Monitor -> Show System Log" and check if there is a message of loglevel "Error". If yes, proceed below; if no, it is more likely that you have the stale lock file issue – see next session.
  2. Fix the error. Fix the cause for the error and then click "Remove" in the ISPConfig system log view. This will cause ISPConfig to reprocess the job it got stuck with next time when its cron job runs (which is every minute in a default setup).
  3. If needed, use Debug log level. If it is not clear what causes the error, enable the Debug log level (in System -> Server Config -> Server -> Loglevel), wait a minute and revisit "Monitor -> Show System Log". Since ISPConfig continuously tries to re-process the failing job, now you should at least see more detailed error messages.
  4. If needed, use direct cron output. If it is still not clear what causes the error, you can look at the direct output of the cron job by executing /usr/local/ispconfig/server/server.sh in a console. If you see "There is already an instance of server.php running.", wait a few seconds and re-try – your execution accidentally intersected with the cron job. If you keep getting this however, it is more probable that you have the "stale lock file" issue, see below.
  5. Or let ISPConfig ignore the failing job. If you don't know how to fix the error, you can let ISPConfig jump over this job and proceed with the next one. For that, increment database column server.updated by one for your server's record in the ISPConfig database (usually dbispconfig). If you want to jump over several jobs: this number corresponds to the last job record (table sys_datalog, referring to the IDs in sys_datalog.datalog_id) which ISPConfig should consider "done".

Sources:

  1. "Delete ISPconfig job queue" thread
  2. ISPConfig 3 Manual 1.4, chapter 7.1 "How Do I Find Out What Is Wrong If ISPConfig Does Not Work?"

How to fix a stale lock file

This reason is most likely if you see this when enabling the debug log level in System -> Server Config -> Server -> Loglevel and then trying to start the cron job manually on the console:

user@host:~ $ /usr/local/ispconfig/server/server.sh
user@host:~ $ 15.11.2013-19:56 – DEBUG – There is already an instance of server.php running. Exiting.

It means that the  ISPConfig cron job crashed (or you killed it) when it was running the last time, leaving a stale lock file behind.

Fix this by executing:

rm -f /usr/local/ispconfig/server/temp/.ispconfig_lock

[source]


Viewing all articles
Browse latest Browse all 92

Trending Articles