I've been pulling my hair out trying to get things to work completely and don't know if I'm doing something wrong or there is still some bug in the identification of updated content, http://drupal.org/node/150109 or some other problem with why cron doesn't send reliably, http://drupal.org/node/314689

I'm using the latest notify 6.x-1.x-dev release which is the same as 6.x-1.1

admin/settings/notify has updated check box ticked

Tests updating content and looking for emails being sent are not consistent.

Sometimes with updating content, followed by flush queue, emails are sent. But sometimes the message no emails to send comes up.

Updating content and then running cron manually sends emails as long as the minimum $send_interval, 15 minutes has passed.

Updating content and waiting for timed cron to run does not show email being sent and flushing the queue gives message "no emails to send".

Is anyone else having this problem?
Is there something I can do to fix this or determine where the problem might be?

Thanks,

Izzy

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

matt2000’s picture

A few questions:

- Are you running any node access control modules?
- Are you certain your timed cron job is running? Do you see appropriate log entries for cron completing?
- How are you determining whether or not emails are being sent? Again, the Drupal log is the most effective tool. (i.e., if that says mails are being sent, but you're just not receiving them, the problem is most likely with your mail server, not notify module.)

There are few things that are important to realize that might help you test your set-up more effectively.

First, the 'Flush queue' button is a bit misleading. Notify module doesn't have a queue of mailings. All that button basically means is 'Right now, send any content that has been created (or updated) since the last time we sent a mailing.'

The second thing to realize is how the send interval works with cron. That is, when cron is triggered, the first thing the module asks 'Have I sent any mailings in the last 15 minutes?' (Assuming your interval is 15 minutes.) It it has, then it does nothing, and it will wait for the next cron run. If you then use the Flush Queue button, you start the interval over again, preventing mailings from being sent on the next cron again.

So if you use the 'Flush Queue' button, and the next cron happens in less than 15 minutes, it is expected that no emails will be sent. You need to wait a full 15 minute cycle before a cron will do the job.

izmeez’s picture

@matt2000 Thanks for the details.

I think I have been taking those things into consideration with my testing.

Yes, the test bed is using node access control in the form of organic groups and I have been impressed with how well things are working.

I have checked watchdog and the server logs and cron is running and nothing unusual is showing up here. The sending of emails is being determined by the receiving of email and the watchdog entries.

I have very methodically used a post for tests.
The post has been updated and then the queue flushed.
The post updated. Minimum time interval definitely passed and manually run cron.
The post updated and waiting for timed cron to run.

The first two of these pretty much works but not all the time, suggesting the node is not reflecting it is updated to the notify module.

I wondered if there might not be a queue as such because I could not see a specific table for the notifications queue in the database.

Yes, it certainly is possible that something else is causing a conflict. There are a number of other modules.
Is there some way that I can insert and display a variable or a flag that might help?

I haven't fully grasped how notify is determining what content to send as the user may have some old content that they have not read that is new to them but predates the enabling of the Notify module and those items are not included in the email, only items that are updated since.

I really hate to have to strip everything down to a bare bones installation to resolve this and was hoping I might be able to get to the root of it some other way.

Thanks,

Izzy

izmeez’s picture

I have spent a lot of time over the past two days looking into this. I sure wish I knew more about coding.

I still have not sorted out the problem but it looks like the flush queue works, run cron manually works, but the timed cron fails. Timed cron does not send out emails and after a timed cron has run, the updated posts are not sent out by email with a subsequent flush queue or run cron manually. It is as if the queue has been reset.

Any suggestions?

Thanks,

Izzy

matt2000’s picture

What method do you use for running cron?

izmeez’s picture

Thanks for hanging in there. I'm using wget,
*/5 * * * * wget -O - -q -t 1 http://example.com/cron.php

cron is definitely running. The function notify_cron is executing, I have watchdog showing the send_start and send_last variables several times to confirm the conditional component is executing. But the emails are not going out.

[edit] I wondered if it has to do with timed cron being a visitor and needing to have some privilege. I tested with setting anonymous permission to access notify and cron still runs and does not send emails. [/edit]

izmeez’s picture

Title: Notify updated content and cron not working consistently » Notify updated content emails not sent on timed cron

I have changed the title, hoping to make it a little clearer.

I'm beginning to think the problem is just related to timed cron runs.

I came across this post that might be helpful,

Safely Impersonating Another User

This might help explain why flush queue and manually run cron work as they are done by a user with admin privileges including administer notify. Whereas timed cron is a visitor.

izmeez’s picture

Yes, this is the fix that was needed.

I have added the code from Safely Impersonating Another User to notify_cron and everything works.

I will post a patch shortly.

izmeez’s picture

Patch attached.

It includes a few lines that may be unnecessary. For testing includes 1 & 5 minute intervals. The lines in notify_cron have been reordered for clarity. And some comments have been added.

izmeez’s picture

Status: Active » Needs review

Sorry, I forgot to change the status to needs review.

matt2000’s picture

Ah ha, thanks for seeing this through. We actually do safely impersonate users elsewhere in the code; the problem is that our query for available nodes happens before we switch users, and the newly added support for allowing other modules to rewrite queries is causing your access control module to prevent your content from being selected. I'll work up a fix to the root issue and roll a new release ASAP.

matt2000’s picture

FileSize
723 bytes

izmeez,

Would you be so kind as to reverse your own patch and test this simpler one? Thanks.

izmeez’s picture

@matt2000

I have looked at the new patch in #11

I am concerned that if during the _notify_send the process aborts, the user will now be privileged as user1.

I think the fix needs to include attention to the session_save.

matt2000’s picture

This is already accounted for in the function _notify_switch_user().

izmeez’s picture

@matt2000 Sorry for not getting back sooner.

I have been pouring through the module and various issues.

I think you are right, your patch in #11 looks like a good solution. I would be inclined to keep the comments on the changes in D7 just as a reminder. I will be testing it shortly in conjunction with several other patches and report back.

KAP10’s picture

FileSize
25.24 KB

Matt,

Can you please help me? I am a business man that also created my own website using Drupal. I too have found that notify does not work with the automated cron jobs run. This string addresses my problem perfectly.

However, I am not a programmer or developer and the discussions about applying patches is way over my head. I looked at the utilities discussed that help apply the patches, but I cannot figure out how to use them.

Can you please give me instruction on how to apply this patch to this module file?

Thank you,
Andrew Polyak

izmeez’s picture

@kap10 The patch in #11 is just one line. If you edit the notify.module file and add this line, you are done. That's called manually applying a patch.

matt2000’s picture

@Kap10

Documentation on applying patches is here:

http://drupal.org/patch/apply

You could also downgrade to version 6.x-1.0 for now, and wait for the 1.2 release which will come very, very soon, I suspect...

izmeez’s picture

Status: Needs review » Reviewed & tested by the community

I have tested the patch in #11 and it works as expected for timed cron.

I have changed the status to RTBC.

matt2000’s picture

Status: Reviewed & tested by the community » Fixed

Committed. A new release (6.x-1.2) has been created.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kriskd’s picture

Status: Closed (fixed) » Active

I am still experiencing a problem.

I have my cron set to run at the top of the hour and notifications set to go out at 9am. When that hour arrived I got "Cron run exceeded the time limit and was aborted" in my logs and cron was not run. When I tried to run cron manually, I got a PHP error with Call to undefined function drupal_mail_wrapper(). It wasn't until I flushed the notifications manually that they sent out and cron was able to run successfully at the top of every hour again.

izmeez’s picture

According to comment #19, the patch in #11 was fixed but the status has since been changed. However, it does appear to be committed http://drupalcode.org/project/notify.git/commit/fbdb9e8 and I believe it is in the 1.2 release and the dev release. Is anything else required here?

Thanks.

izmeez’s picture

@kriskd In comment #21 your need to manually flush notifications to restore cron might need to be the subject of a new issue since the the patch in this queue was already committed to 6.x-1.2 and this was marked as fixed.

I am not the module maintainer, just looking for some direction from the community.

izmeez’s picture

Status: Active » Fixed

I am restoring the status to fixed as shown in comment #19 and because no further followup posted on comment #21.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.