motowebmaster Posted February 7, 2022 Report Share Posted February 7, 2022 Attempted to switch from php 7.4.27 to php 8.0.15, and things appeared to be running fine. Came back to my site a few hours later and ads weren't working. Did some tests on my primary site, because I thought I had broken something after a minor update, then switched my revive adserver back to php 7.4.27 and ads started working again. Should I enable debugging in revive, or is php 8.0.15 a problem? Quote Link to comment Share on other sites More sharing options...
motowebmaster Posted February 12, 2022 Author Report Share Posted February 12, 2022 Switched back to 8.0.15 again and things were running ok. So I manually-ran the maintenance items, checked the plugins, cleared everything in /var/cache, and restarted stuff. It's been running good for 12 hours. Thinking that clearing /var/cache helped the most. Some of the files in it were too old. Makes me wonder if I should setup a cron to clear the cache weekly. Cleared the cache again because one of the recent files had the wrong ownership/permissions. Quote Link to comment Share on other sites More sharing options...
motowebmaster Posted February 12, 2022 Author Report Share Posted February 12, 2022 Ok, had to clear the cache again because: Files were being written with the wrong permissions they were being given root ownership, which shouldn't be happening An error message was displaying within the admin interface, stating there was a problem with file permissions. I enabled debug log and it listed one file in /var/cache I'm going to move the file cache out of the document root, something I should have done already. Quote Link to comment Share on other sites More sharing options...
motowebmaster Posted February 12, 2022 Author Report Share Posted February 12, 2022 Ok, learned something; Moving the banner delivery file cache out of the document root works Changed the banner cache update interval from 1200 to 300 seconds, it is updating properly The files in the banner delivery cache are being given the proper ownership and permissions The admin file cache is still being written to the default /var/cache directory Shouldn't all of the cache files be written to the custom location I've set for the banner delivery file cache? If it isn't supported, can there be a config option added where I can set a custom location for the admin file cache that also supports a permission validation and update interval? I've made a couple "restrictive" PHP parameter changes, but it caused problems. When I put the php settings back, and restarted the webserver, the admin interface was still displaying errors. Changing back to php 7.4.27 fixed the issue, then I was able to switch back to php 8.0.15 again. During that experience a file with root ownership was written into the banner delivery cache directory, so I cleared all off the cache files again. Initially was thinking that someone/something was attacking my file cache, but now think that it's a bug. The banner delivery cache now appears clean, being written outside the document root, and updating every five minutes. Disabled GZIP content compression on the user interface settings. Cleared the cache files again in /var/cache but wish they weren't there at all. Quote Link to comment Share on other sites More sharing options...
motowebmaster Posted February 13, 2022 Author Report Share Posted February 13, 2022 So after 20+ Hours: The delivery cache looks clean. Just one file being written with root user ownership, group ownership is correct. Appears to be a php file associated with the maintenance routine, but since the entire delivery cache is now being written outside the document root I suppose it isn't critical. It is being updated every five minutes. The files in /var/cache are being written with the correct user/group ownership. Even with me navigating the admin interface they aren't being updated. I put an empty index.php file in that directory and gave it the proper ownership/permissions. No files are being given root ownership for unrestricted permissions. I still have GZIP disabled in the user interface settings, but am thinking that my webserver (Litespeed) may be doing some compression anyway. I have LSCache disabled, revivie started exhibiting issues with LSCache a couple versions ago, but haven't disabled any Litespeed compression settings. I am running AlmaLinux, migrated from CentOS8 using AlmaLinux' migration script, but don't think it is relevant. Hope this is helpful. I still don't know why ads failed to work on the first day. I'm assuming that php 8.1 isn't supported yet, but am able to switch to it if my assumption is wrong. Thanks for your efforts ? Quote Link to comment Share on other sites More sharing options...
motowebmaster Posted February 15, 2022 Author Report Share Posted February 15, 2022 Guess I spoke too soon, had to switch my revive adserver back to php 7.4.27 in order to restore normal operation. It's like the server wasn't responding to the single page call at all, after it had been working for a day. I noticed something the night before, but it was happening only on my desktop PC ads weren't working - but they were on my mobile - from the same network. Wanted to see if it would resolve itself, but ads ended up not running for anyone. It will likely work if I switched back to php8, but don't know what to look for. A response would be appreciated. Quote Link to comment Share on other sites More sharing options...
qeepcologne Posted March 4, 2022 Report Share Posted March 4, 2022 i tried to run revive 5.3.1 on php 8.0.16 and finally give up and run on 7.4.28. zones are broken. This is not related to the data in zones table, i truncated the table. Then add one new entry via ui, after that the view is broken (entry is not shown, add new zone is not shown anymore). php error log says: [03-Mar-2022 11:57:03] WARNING: [pool www] child 196800 said into stderr: "Stack trace:" [03-Mar-2022 11:57:03] WARNING: [pool www] child 196800 said into stderr: "#0 {main}" [03-Mar-2022 11:57:03] WARNING: [pool www] child 196800 said into stderr: " thrown in /projects/local/revive-adserver-5.3.1/www/admin/affiliate-zones.php on line 123" [03-Mar-2022 11:57:18] WARNING: [pool www] child 196800 said into stderr: "NOTICE: PHP message: PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /projects/local/revive-adserver-5.3.1/www/admin/affiliate-zones.php:123" there is similar error on ad delivery motowebmaster 1 Quote Link to comment Share on other sites More sharing options...
motowebmaster Posted April 16, 2022 Author Report Share Posted April 16, 2022 An update. Upgraded to 5.4.0 and switched to php 8.1.4 earlier today. Seems to be running well with php8, ads don't dissapear. Regarding the file cache, there is still one file being written with root permissions and full write/execute (chmod 777). It is being placed outside the normal document root and being replaced at the configured cache interval with the other cache files, so it should be safe, but would prefer that it be written with the same user/group ownership of the other files in the cache directory. Quote Link to comment Share on other sites More sharing options...
motowebmaster Posted April 17, 2022 Author Report Share Posted April 17, 2022 (edited) Ads went away again. Had to switch back, to php 7.4.28, in order to restore them ? Edited April 17, 2022 by motowebmaster Quote Link to comment Share on other sites More sharing options...
motowebmaster Posted April 24, 2022 Author Report Share Posted April 24, 2022 Was running on php 8.1 for a couple days, after re-linking zones to a website, and thought I'd had it solved - until it broke again. Ads disappeared from my desktop, but we're still showing on my mobile. Resovled it by going back to php 7.4 So I thought I'd check out the innvocation code, to see if I needed to update something, and went down a rabbit-hole involving the deprecation of single-page-call. Someone could have said something ? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.