View Issue Details

IDProjectCategoryView StatusLast Update
0015288phpList 3 applicationCommand Linepublic09-04-10 19:30
Reporterh2b2 Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version2.10.10 
Target Version2.10.11Fixed in Version2.10.11 
Summary0015288: v2.10.10: Commandline cron not working
DescriptionFollowing issue was reported by jfm5440:
==== Start Quote ====
My command line processqueue cron jobs worked fine under 2.10.4 but after upgrade to 2.10.10 they stopped.

It looks like the parameters are not getting passed. I have the "$commandline_users = array();" set so no user id is needed.


Well it appears to be a PHP register_globals problem.

If i stub out

require_once dirname(__FILE__) .'/commonlib/lib/unregister_globals.php';

from index.php the cli works.

I know there are security implications in leaving register_globals on (which is my php.ini default because I want to for some old scripts).

but index.php should work without global registration right?

anyway if I edit .htaccess and add

php_flag register_globals off

the cli continues to work fine.

==== End Quote ====
TagsNo tags attached.



07-09-09 18:19

reporter   ~0050736

Confirmed above

Clean install of 2.10.10 undergoing initial config and test on a LAMP hosted server - mails refused to go out even though cron emailed correct action complete.

Mails stayed queued whether sent to the test list or direct to the test user.

commenting out the require_once dirname(__FILE__) .'/commonlib/lib/unregister_globals.php'; from index.php released the mails ....

.... however ....

My hosting company has "register_globals = on" set at a server level, and I had to perform 2 bug fixes before the above one worked -
- in lists/.htaccess => knock out the globals line reported as a fix for the 500 error during install (I had to do this to get phpLIST to install)
- in lists/config/config.php => set the $commandline_users = array();
to read => $commandline_users = array("admin","server_user_name"); before cron would run.
(Replace "server_user_name" with your actual server login name => is this a security risk? plain text server user name in the config file?)

.... also ....

I'd also had to apply the updated files - (attributes order listing not saving on subscription page)
and (lists/admin/connect.php patched file)

That last one, the patched connect.php file, was critical
.... because ....
even after applying all of the above, mails created BEFORE patching connect.php still will not go (cron reports an error within the email that is the same as why connect.php was patched).

It therefore appears that the _globals issue has potential to be masking other bugs for which patches are already available.



09-04-10 19:30

administrator   ~0050872

this has probably been resolved by fixing other register globals related issues. I tried on the latest code and it works ok on commandline.,