The "parser.lockfile" is blocking POP3/IMAP fetching

[grindkore]

Message from staff: Patch available for this problem at the end and last page of this thread.



Original post:
Hi we use POP3 to fetch e-mail in to Kayako, up until last nigh everything worked fine. Then about 24 hours ago Kayako stopped connecting to the POP3 mailboxes.

I have verified all the setting, passwords, mail server logs and everything pointed to Kayako not connecting to POP3. After searching this forum, I stumbled on "/cron/index.php?_t=parser" trick. Sure enough when we access cron file using this URL we get following error:

[ERROR]: Lock file found! (./files/parser.lockfile). A lock file has been found preventing further execution, if it is from a stale instance of cron then please delete the file in order to continue. To remove the file manually click here

Once I have located the "parser.lockfile" and deleted it, the parser has executed and all pending e-mail messages that were queued up in POP3 were processed. The problem is that the "parser.lockfile" file is recreate every time parser runs, thus subsequent parser runs are blocked until we manually remove this file.

As a short term solution, we made a small script that deletes this file. But we would like to know why this is happening and how to solve this problem.

Our Kayako Environment:
WIN2003, II6, PHP 5.2.6 CGI, Kayako 3.20.00 CVS

[supportskins]

I believe the parser lock is created when Kayako fails to retrieve the emails from the mentioned POP3/IMAP account forcing the email parser not to retrieve emails. This usually happens when the parser fails to retrieve emails with large attachments. You might want to check your server settings making sure it is configured to accept large attachments.

[grindkore]

At this point we are not live with this kayako installation, the only e-mails we have in the POP3 mailboxes are test and are no more than 2KB in size. Furthermore the mail server installation is dedicated for kayako use only. We wanted to isolate our help-desk server from the rest of the network n order to avoid possible blacklisting or other issues that may prevent support tickets from reaching our customers.

I will attempt to reinstall kayako, hopefully clean installation will resolve this.

[craigbrass]

If not, I suggest you submit a ticket to Kayako (http://members.kayako.net -> "Get Support") so they can trace the issue.

[Jamie Edwards]

Hi grindkore,

In the latest version of our software, a link is provided in the administrator control panel to delete the lock file. However, this is not a complete solution to the issue so I have submitted a bug to the tracker, which we will attend to as soon as possible:

Kayako Bug Tracker - Viewing Issue #463 - parser.lock file should automatically expire

[Jamie Edwards]

Hi there,

This has actually already been fixed between 3.20.00 and 3.20.01. Please upgrade to the latest version and the lock file should no longer remain stale.

[webbcite]

We are running 3.20.02 and had this issue come up today. The lockfile was in place and POP3 was not being picked up since yesterday afternoon...

[Jamie Edwards]

I have reopened the bug tracker entry;

I have changed this back to investigating. As the user posted in the thread linked above, we cannot cater for every possible stoppage of the parser that might leave the lock file in place (i.e. a server crash).

So we need something to automatically delete the parser lock file; such as in an existing or a new pseudo-cron (scheduled task).

[Xaman]

A solution that worked for us, disable the autoresponder option.

We disabled it and it's working fine now. At least until Kayako can fix this bug.

[Jamie Edwards]

Hi Xaman,

Are you using an SMTP server?

[cyberneticos]

Hi Jamie,

Nice to see you again. I am having this very same issue also. Went 7 days without mail (sent via pop)

I also run 3.20.02 Manual link works. I guess the very same cron that runs the parser could check if it's locked and unlock it.

But I'll wait for a solution

[cyberneticos]

Meaning, I would like for some one to give me a solution.

Thanks.

[tparikka]

I am also encountering issues with the parser.lockfile. I have eSupport configured to fetch via POP3 (no outgoing mail configured yet). When I set the POP3/IMAP Fetching task to run and then trigger the cron manually, the ./files/parser.lockfile generates by itself. There are no log entries to speak of that I can see indicating the cause of the failure. I have tried deleting the parser.lockfile file but each time I trigger the cron the file is created. The mail server resides on the same network segment as the eSupport server and the two are connected via a gigabit switch. The only emails currently in the inbox are small text-only emails of one or two lines.

I am currently running a trial of eSupport on a dedicated server in preparation for a possible deployment using an Owned License.

[GoneShootin]

This is a right balls up. Lock file has been happening for the past few mornings. Which means that there is a delay in the emails being responded to due to the fact that our kayako users often get in earlier than the IT department can to clear the lock file.

I've mentioned this before

I see tha the last comment on the bug issue was

Ryan Lederman: Status changed from Confirmed to Fixed 02/04/2008 17:42

So if this is fixed do you know when it will be released?

I'm so anxious about this issue because we are looking to deliver Kayako to the rest of our company, but I cannot recommend that action until the parser lock file issue is resolved.

[tparikka]

Word over at Notice: Undefined offset: 1 in d:\Inetpub\HelpDesk\cli\index.php on line 22 is that the CVS breaks a few things, so although this particular issue is listed as resolved, it sounds like other bugs have been introduced that make upgrading a poor decision. Haven't found anything as far as expected release date for 3.20.03 yet.

I haven't yet purchased, and I won't be doing so until this bug is resolved. I'm currently on a trial Leased License.