BaliDave

The problem has "disappeared", tho for unknown reasons. 5.2.1 was still problematice with "nobody" processes running alongside those with my username, but this time (4th try), the upgrade worked. Gremlins gave me a reprieve.?

I'm still stuck and can't do the upgrade to 5.3.1, and 5.2.1 is still apparently invoking some code running as "nobody" instead of my username, and generating files in /var/cache directory. The upgrade attempts wind up with Composer seeing cPanel's 7.1 version of PHP instead of my 7.4 version. The mystery is how does RevAds invoke a "nobody" process, when PHP is running in CGI mode as my username. All ideas welcome, please.

When I upgraded to 5.3.1, a number of pages -- but not all -- with ads now show the message: "Composer detected issues in your platform. Your Composer dependencies require a PHP version ">=7.2.5" and that is the only thing that appears on the page. I recently upgraded to PHP 7.4.27 from 7.1 and simultaneously from running Apache as a php-module (user "nobody") to as a CGI module (using my username). I'm on a server using cPanel and the PHP 7.4 is effected by using their EasyApache selection for the site. All other parts are fine with 7.4 including WordPress and phpList. Note that cPanel itself is using PHP 7.1 and I cannot control that. Both phpinfo and php -version show 7.4.27. Any ideas on how to debug this? One other piece of information that MIGHT be relevant: the current 5.2.1 version is running fine, however I noticed in the var/cache directory about half of the delivery_xxx.php files are owned by nobody (600 perms) and the other half are owned by my username. And chown'ing and chmod'ing these "nobody" files is soon overwritten, and I'm back to previous state. I tried rebooting the server to see if these were just from some left-over process/thread running under Apache, but still get the same behavior. I don't understand how now with php running as a CGI module with my username, files with owner "nobody" can get created. Again note that this bit of info may NOT be relevant to my problem above.

OK, I found the problem -- one way out in left-field: the new RevAds no longer returns the same indication from my PHP call, that there are no more ads meeting my criteria. So an obscure page of mine wound up in an infinite loop! I found a new way now to detect a "no more ads" condition (not the same as previous RevAds) and changed the criteria, so that all works OK now. So no more timeouts in Rev Ads are occurring. I retrieve ad information via a PHP call to a RevAds fucntion, and all my ads are "local" ads. This gives me the html needed. which I display. This code came from many years ago when I first started using OpenX, as it was called then. There's a very brief mention of this I found now on https://documentation.revive-adserver.com/display/DOCS/Tag+Variables But I didn't find any more documentation on this now, and don't have access to the old OpenX one. If you know, please tell me where there's more documentation on this available now. Anyhow my basic invocation to retrieve ad data has a call to the view_local function defined in alocal.php: $ad[$i] = view_local('', $zoneNum, 0, 0, '', '', '0', $phpAds_context, ''); And I do this in a loop, bumping $phpAds_context each time I find a valid ad. Previously in RevAds (last version prior to 4.1.4 I used was 3.0.2) the 'html' array element of this would return an empty value if no more ads met the criteria, and I'd break out of the loop. My fix now is to check that this element has some sensible value (e.g. there's an 'href=' in it). It'd be nice to have something more definitive -- let me know if you know of such. Anyhow all seems to be working OK now. I'll report back later if something's still amiss. Thanks again Andrew for all your efforts here, and my apologies for not finding this sooner. I hope this saves someone else's time.

OK, I'll change to InnoDB. Since this RevAds upgrade was simultaneous with moving to PHP 7 and MySQLi (vs MySQL), that might account for the difference (this has never happened before). So maybe MySQLi calls are i One concern is that even when I turn off all DB maintenance in RevAds and stop serving ads, I still get Rev Ad code timing out for many hours afterwards -- my PHP error log file shows them occurring. Either there's a big queue or some processes have been spawned (I don't see them) tho. Perhaps shutting down Apache will stop these (???). So I'm not sure how to stop everything to make the change, or I just plow thru it after stopping the server. Any ideas/suggestions?

Thanks. I didn't change to InnoDB since slow-query logging showed no slow queries happening, so I don't think it's a DB issue (could be wrong). If you still think that's likely the problem, I'll change that for the Rev Ads DB -- just afraid of causing other problems (I'll make a backup first). Before I make such a change is there anything I should do with RevAds to "stop" it so as to prevent problems during the change over, e.g. stop serving ads, or ???

Does anyone have any ideas on how to overcome this? I'm now getting more of these timeouts happening (68 such yesterday). And that's eating my server time (68 * 150 secs CPU). Again note I'm willing to sacrifice statistics on all ads -- our customers never look at them anyhow.

I went back to a more normal set up with automatic maintenance on and my ads being served. I'm still getting 30-40 such errors/day (4 days after redoing the set up) I'd at least like to find a way to stop those -- I can sacrifice statistics if that'll help. Other than killing my present installation, and then recreating all clients, campaigns, banners, and channels -- if anyone knows a way to get past this, please speak up. I do need to get rid of these cpu hogs. Thanks.

At least some more info -- there are no slow queries causing this, so the problem's in the rev Ads code itself and not MySQL. I have slow_query_log set on and tho I keep getting these max execution time messages, there are NO slow queries (I set the threshold at 20 secs and these timeouts are occurring passing 150 seconds). It is totally unclear why these processes are running at all since (1) all ad serving is turned off and my code never accesses Rev Ads & (2) no maintenance operations are running since I turned off automatic maintenance and killed my cron job running it. One possible "clue" (pretty funky one at that) in this mystery is that now the errors are occurring at ~ one hour intervals and near the time that I previously had maintenance scheduled (i.e. scheduled at 1 min past the hour every hour, with errors now occurring at 3:05, 4:05, 5:06, 6:07, 7:08 ). So perhaps there's some leftover tasks that were spawned from the old maintenance runs and just waking up. If anyone who understands what's really going on with maintenance scripts, can give me directions, that'd help. So 2 main objectives now: what is causing this and how to fix? if #1 can't be resolved, how to limit the execution time? I set a lower time limit in the rev ads directory's htaccess (and verified with phpinfo that that is the true max), but the script uses my root folder's limit of 150 seconds. For #2, perhaps I put some ini_set's in the code to limit the time in some of the functions in alocal.php, but I don't know where they should go. Any ideas?

Now things are worse after I changed to running maintenance via a cron job every hour -- instead of getting those 6 or so of those execution time exceeded errors/day, I'm getting 40-50! So I killed maintenance running altogether (both internal and cron job), AND stopped all ad-serving (so no ads are appearing on my site), but still I'm getting these errors!?!?! Seems like NOTHING should be going on with the revAds at all now. And right now (for some reason???) I just had 5 of these in the last 7 minutes: [13-Aug-2018 02:58:57 UTC] PHP Fatal error: Maximum execution time of 150 seconds exceeded in /home/seabelow/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 3978 [13-Aug-2018 03:01:10 UTC] PHP Fatal error: Maximum execution time of 150 seconds exceeded in /home/seabelow/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 4239 [13-Aug-2018 03:03:23 UTC] PHP Fatal error: Maximum execution time of 150 seconds exceeded in /home/seabelow/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 3911 [13-Aug-2018 03:03:23 UTC] PHP Fatal error: Maximum execution time of 150 seconds exceeded in /home/seabelow/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 4238 [13-Aug-2018 03:05:35 UTC] PHP Fatal error: Maximum execution time of 150 seconds exceeded in /home/seabelow/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 4240 I've turned slow_query_log on mysql now and restarted it, but nothing yet. Suggestions/... welcomed.

Andrew, Thanks, I'll look into doing that. One thing I'd like to do is cut down the max time spent with these queries, but somehow the process is using the max_execution_time set in my home directory as opposed to that I set (via .htaccess) in the RevAds directory. Unclear to me how this is happening since the process should be spawned in the RevAds directory (I don't have any cron jobs running RevAds processes). I verified via phpinfo() that the one set in my RevAds directory is much lower. Anyhow do you know of a way to control that timeout option, so I can at least prevent the server from getting hammered by these queries? Thanks again, Dave

Andrew, Thanks, and yes the tables (and all my DB's for that matter) are MyISAM -- been that way for a long time. If that's a problem what would you suggest? Thanks, Dave

Andrew, Thanks. I'm reluctant to turn on MySQL logging for fear of slowing down other processes since I'd have to leave it on a full day in order to catch some errors. But you're right, it doesn't seem to be a big problem tho the multiple busting's of the 4-minute execution time limits are a concern. But before I abandon this quest, wondering if you have any thoughts on the the code that's breaking. It's getting these errors (according to the PHP error reporting system) in code that is very simple and not something likely to run away. For example it was reported for today's errors: [04-Aug-2018 06:00:32 UTC] PHP Fatal error: Maximum execution time of 250 seconds exceeded in /home/seabelow/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 4240 and also on lines 4239 and 4247, all in the function _adSelectBuildContextArray. And here's the code around there: for ($i=0; $i < $cContext; $i++) { reset($context[$i]); list ($key, $value) = each($context[$i]); # This is line 4239 $valueArray = explode(':', $value); # This is line 4240 if (count($valueArray) == 1) { list($value) = $valueArray; $type = ""; } else { list($type, $value) = $valueArray; } if (empty($value)) { # This is line 4247 continue; } I don't see how that's possible to be stuck executing at those lines. All other such I've looked at are similar innocuous code that should never exceed the time. Or maybe the reported lines are way off relative to what PHP is reporting??? I've seen a line or 2 diff in what's reported with reality but not many lines different. Anyhow let me know if you have any ideas on this. If not, I'll just live with this puzzling problem. Thanks, Dave Interestingly I tried to lower the max_execution_time to 100 in my .htaccess for the revive directory, so at least it wouldn't hammer my server so badly. But I'm still getting messages about exceeding 250 seconds. My .htaccess is just php_value max_execution_time 100 but it's being ignored. So is some process spawned by Rev Ads not honoring the .htacess? Or is there a way to lower that limit that will work just for the Rev Ads directory? Thanks, Dave

Thanks for getting back to me. There's nothing indicating problems in the PHP, webserver or RevAds debug.log. My MySQL DB does not have logging turned on and there are no indications of server performance problems at any times. All other DB operations (non-RevAds) are running smoothly. I get about ~6 of these messages in my PHP logs every day (this is day 3, so not lots of data points here) and the timing has them about 1/hour for a few hours until the next day. From the debug.log, these do not happen during maintenance times. Note that I have only 10 or so html ads running on the server and our traffic is low volume, and the server pretty beefy for what we're doing. Any other ideas? Thanks,Dave

I just upgraded my server to PHP 7.1 from 5.4 so was now required to upgrade Revive (I'd tried previously but couldn't do this upgrade due to my PHP version being too low). So I upgraded from 3.0.2 to 4.1.4. All seemed to go OK in the upgrade and my ads are appearing. But now I see that I'm seeing a few errors daily about exceeding max execution times (my max set at 250 seconds) in www/delivery/alocal.php The lines where this occurs seems to vary, here are the messages from yesterday that i see in my PHP error log: [01-Aug-2018 21:46:06 UTC] PHP Fatal error: Maximum execution time of 250 seconds exceeded in /home/xyz/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 3911 [01-Aug-2018 21:48:28 UTC] PHP Fatal error: Maximum execution time of 250 seconds exceeded in /home/xyz/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 4241 [01-Aug-2018 22:13:01 UTC] PHP Fatal error: Maximum execution time of 250 seconds exceeded in /home/xyz/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 4238 [01-Aug-2018 22:36:46 UTC] PHP Fatal error: Maximum execution time of 250 seconds exceeded in /home/xyz/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 3911 [01-Aug-2018 22:37:20 UTC] PHP Fatal error: Maximum execution time of 250 seconds exceeded in /home/xyz/public_html/revive-adserver-4.1.4/www/delivery/alocal.php on line 4240 Any ideas as to how to fix this or at least debug it?

When I upgraded from OpenX 2.6.5 to RA 3.0.2, I ran into a problem concerning using www.example.com vs example.com. Previously I had my config file named like example.com.conf.php. Renaming it to www.example.com.conf.php seemed to fix the problem, since the upgrade was able to finish. HOWEVER, the ad links no longer work (I allow RA to modify links for tracking) -- they give me a 404 Not Found. The generated links all begin with example.com/. But if the generated links were to have www.example.com at the front, they work. So I changed several lines in my config file (admin=, delivery=, deliverySSL=, images=, and imagesSSL=) to now start with www.example.com instead of example.com. Before it wasn't clear I needed to do such. Well that change made my links now "work" -- they take you to the right place. BUT now all my targeting channels are broken. So links intended only for a few pages are being shown on ALL pages where they possibly might, i.e. the targeting channels I'm using for them are being ignored. So I went to Targeting Channels section and get the message "WARNING: The delivery engine limitations DO NOT AGREE with the limitations shown below Please hit save changes to update the delivery engine's rules" for all my channels. And now there are NO options available in the "Add delivery limitations" drop-down. So I can't individually fix the channels. Any suggestions on what I can do to recover from this? I guess I could redo the upgrade, but then lose not only stats, but all changes I made to RA since (new and changed ads). I tried a few things, but either get one problem or the other.

If your DB user password has special characters in it, e.g. =& you must put quotes around the whole password. That burned me. Good luck.

I just completed (I think) an upgrade from OpenX 2.6.5 to Rev Ad 3.0.2 and hit a couple snags that others might run into as well as a final error message that "recompiling ACL's timed out". The problems I got around that might help some others were: naming of the config file to include "www." instead of just the basic domain name, i.e. www.example.com.conf.php instead of example.com.conf.php. Without doing that, the wizard didn't find the config, so was trying to do an install rather than an upgrade. Apparently OpenX 2.6.5 didn't care as the config file did NOT have the www. in front. I see someone else also hit that http://forum.revive-adserver.com/topic/190-revive-upgrade-showing-install-screen/?hl=upgrade After that in checking requirements, the upgrade couldn't open the DB. The problem there turned out that the password had special characters in it, so when I enclosed that in quotes and reuploaded it, all went fine. After that the upgrade appeared to go OK tho I was bothered by the time-out message at the end, but everything seems to be working fine. And the install log shows that part went fine and I didn't find that error message in it: "attempting to include file /.../public_html/revive-adserver-3.0.2/etc/changes/tasks/openads_upgrade_task_Recompile_Acls.php Recompiling Acls OK Starting Acls Recompilation Acls Recompilation: Complete" Spot checking the installation (I already switched over) doesn't show any problems, but I'm wondering if something's likely to bite me later, or if there's anything I need to do. -------------------------------- ps -- Previously I was in somewhat of a panic since when I Google'd Revive Adserver there are a bunch of virus postings with that name that come up, so initially I was scared off of Revive Adserver. I suspect these were from the old security hole that also was in OpenX. Anyhow I was very glad to see there's a viable OpenSource follow-up to OpenX -- thanks, all!