But as of a couple weeks ago, running by cron is broken.
If I drop the script URL directly into a browser, it works just as it should. But now when run by cron, I get passed Open() and Login() but ListMessages() throws me "connection is not in TRANSACTION state."
Like I mentioned, your pop3class has always worked just fine, for years. And it works just fine when I drop my URL directly into the browser. But it now breaks when run by cron.
I run my script directly in browser, works just as it has for years.
By cron, I get "connection is not in TRANSACTION state" when I uncomment "//print_r($result);" But directly in browser is shows the full array.
Output by cron, will show me "starting now" but it appears to break right after that, it never goes though the foreach loop. But only by when run by cron up until a couple weeks ago. Directly in browser with URL, works fine.
Paul - 2013-07-23 02:17:32 - In reply to message 1 from Paul
After 10 hours I finally found my own solution. It appears, possibly through a cPanel update, that security protocol changed.
I have many scripts that I run by cron that are held in a HTTP Authentication required folder. The scripts run perfectly fine without having to provide authentication to my crons, however, the bounce script I created, everything else in it runs fine, just the pop3 auth would not happen, so that part of my script would essentially just get skipped, while the rest of the script ran just fine.
So, I changed my cron to run by wget and provided user:pass auth, and bam! Pop3 connection now works in the script.
So if a script to run by cron is going to connect to pop3 using the your pop3 class, and the script happens to be in a HTTP Auth protected folder, the cron must have auth to gain access to pop3 now.
Manuel Lemos - 2013-07-23 07:21:14 - In reply to message 3 from Paul
This is odd. For cron scripts you should be using the PHP CLI command version. Anyway, the error that you show seems to reflect that the correct the POP3 login is failing and your script is not checking its success before proceeding to message retrieval.
Paul - 2013-07-23 08:00:45 - In reply to message 4 from Manuel Lemos
Yes it is odd. I have always run my crons with PHP command.
I have 3 servers. 2 servers with one host, and 1 with a different host.
The 1 with the different host, the crons still run fine with PHP command.
On the other 2 servers, I have 3 sites that use the same exact script using your pop3 class and they have been fine for years. I originally mentioned the HTTP Auth folder that contains the script I run, which is actually only on 1 of those 3 sites. The other 2 sites, the scripts are not in HTTP Auth folders, which created a dilemma for me. I was now confused, since I had no user:pass to pass with WGET. So, for those 2 sites, I simply used WGET without passing auth and they once again worked.
What made it even more confusing for was the fact of dropping the URLs to those scripts into a browser, they functioned just as they should. But by running them with PHP command, pop3 auth was completely skipped, even though the rest of the script would run.
Manuel Lemos - 2013-07-23 08:18:30 - In reply to message 5 from Paul
I suspect that something is preventing those scripts to run the same way, probably including files that are not in the path you expect.
Anyway, instead of guessing without further information, I suggest that you setup a PHP error log file in php.ini, enable error tracking and see what errors are appearing there that you may not be aware.
This article on the Log Watcher class may give you further insights.