Jump to content

Problem with PHP 8.0.15


Recommended Posts

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?

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 weeks later...

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

Link to comment
Share on other sites

  • 1 month later...

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.

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...