splaestro

OK, it looks like things are now working well enough. In the dashboard, posts are still ending up with a “scheduled” status/”Missed Schedule” label. I think this may have to do with a two-minute lag between the timestamp of the e-mails and the server’s time (messages are ahead of server).

But I was forgetting that I have to refresh a page on the site itself in order for the cron process to run Postie’s hook. Once I do that, the missed posts get published. It’s a bit weird, but it works.

I’m working on some similar issues, and while I can’t promise a fix (and I know nothing about the SetCronJob service), here are some thoughts:

1) Do either running wget or php from the commandline as above work? That should tell you something. If you don’t redirect wget’s output to null, and don’t use the -O switch, you’ll get a little info on stdout and in the output get_mail.php. Using php should echo everything to stdout that Postie normally writes to the browser inside WP (i.e., when you use the button on the dashboard).

2) Logging: according to this page, cron logs its jobs in /var/log/cron or similar. That should at least tell you whether your jobs ran.

You can turn on Postie’s own logging, as described in the FAQ, second item from the bottom. It’s quite verbose, so you probably don’t want to keep it turned on long-term, and you have to troll through a lot of stuff to find useful info.

You could also have wget log its output with
wget -a mylog -O - [URL]
(-a appends, -o mylog will recreate the file every time)

And with php, you could just redirect the stdout and stderr to a log with something like:

php [URL] >> mylog 2>&1
(again, >> appends, > will recreate)

3) You do realize that you don’t need both the wget call and the php call in your crontab, yes?

HTH.

Are you all still having this problem? If so, my guess is that you need to pass an additional option to wget (or perhaps get rd of one, depends). Can you post the wget commands you are putting in your .cron files?

The default action of wget is to download the output of whatever it is told to retrieve and write it to a file in the working directory, which are here your users’ home directories (/home/$username). The default file name is the document name that you tell wget to retrieve, hence ‘wp-cron.php?doing_wp_cron&691…’. Wget will append a number to each output file’s name to avoid overwriting previous downloads.

There are at least a couple of ways to avoid this behavior, one being to use the option -O - (that’s a capital o); this will instead write whatever wget retrieves to the standard output. Now, this may put a lot of extraneous stuff into your server’s cron logs, so it may not be desirable; I don’t know enough about how cron logging works. Your sysadmin should be able to tell you more.

Another approach would be to investigate the -nc (–no-clobber) option.
Try man wget and see what it says about this one. (In general, RTFM is good advice.)

Update: wget from the command line will publish a post with no problem. However, when I initiate the call from procmail, I get the same result as when calling php from procmail: the post is created, but its status is “scheduled” as opposed to “published,” and the Date column reads “Missed Schedule”. So perhaps the problem is with how procmail invocations work??? I can’t imagine why that would make a difference, but maybe it does.

FWIW, this is the relevant action in my .procmailrc:

:0 hW
  |wget -a $LOGFILE -O - https://mydomain.org/dev/wp-content/plugins/postie/get_mail.php

Thanks for your response.

Why aren’t you using wget or curl?

The site is protected with .htaccess for the time being, and I’m always nervous about putting credentials in plain text files. Also, there’s a nice side effect to procmail’s logging, in that it will capture what Postie writes to stdout when I invoke the page from the command line.

Still, I’ll try wget and if it yields better results, I can do the additional work to secure the credentials and maybe capture the output as well.

I’m not sure WordPress will work if you call it through the command line.

Just to be clear, everything seems to “work”, as I described in my initial post, except that the posts don’t get published. But perhaps you mean that calling the page from the command line won’t fully configure the WP environment and therefore the posts get the wrong status?