josephs8

Thanks Jim for the response. I’m sorry I wasn’t more clear I didn’t assume the percentage in the archiving was the process rather the amount of posts that would be archived. Meaning I would expect my forums_posts table to shrink significantly. The site has not been offline the entire time so the tasks are running. I also went and verified that the archive posts task is running every 5 minutes and ran several minutes before the last time I checked it. Yet no progress has been made, the size of the table forums_archive_posts has not changed at all.

I enabled archiving to offload some of the posts in our forums_posts table as it has gotten quite large and these topics are not actively used anymore. Before enabling archiving, I ran a query to check the size of the tables, and after letting a few hours go by the size has not changed and none of the posts appear to have been archived even though it shows that 90% of the posts should be archived. I looked at the scheduled task and it is running every 5 minutes and no errors are being reported in the log. What do I need to do to get archiving working or any other ideas on what could be going wrong? Thanks!

No errors are reported in the cronlog (and it is showing it is being executed every minute), the messages log, or the PHP log. I also was able to execute the command that crontab runs manually and it did not produce any errors. I've also set up a log on the cronjob output and checked for output errors from that and nothing. Finally, I also switched it to traffic based and it didn't seem to impact it.

We are using a cronjob and yes it is using the same version of php. We've always used a cronjob and it has not gotten any better just appears to be increasing.

I am not getting an error that scheduled tasks are not running, but I have a very large number of background tasks that appear on the widget on the dashboard. It shows I can run them manually, but I am afraid of what that could do to the board's performance with that many. What are my possible options here to fix this?

@Jim M thanks for the image. But I must still be doing something wrong. I search for Task click on the Tasks item that pops up. Then find the queue task (its usually at the top and running), I remove the running lock and then click run now and I get a 404 error not a 500 error. Are you doing anything differently? Or would you be able to provide a video of what you are doing as I feel like I am missing something here.

@Jim M I updated the credentials. Please let me know if those work or not. Thank you.

@Jim M you mean allowing it to talk with the internet from the server? If thats the case no we have no restrictions on outgoing traffic from the server.

@Jim M I am not seeing any 500 error. I do see an error, but it is not generating a 500 error in the logs and seems really unclear what it means. RuntimeException: (0) #0 /var/www/atrl.net/html/applications/core/tasks/queue.php(43): IPS\_Task::runQueue() #1 /var/www/atrl.net/html/system/Task/Task.php(375): IPS\core\tasks\_queue->IPS\core\tasks\{closure}() #2 /var/www/atrl.net/html/applications/core/tasks/queue.php(55): IPS\_Task->runUntilTimeout() #3 /var/www/atrl.net/html/system/Task/Task.php(274): IPS\core\tasks\_queue->execute() #4 /var/www/atrl.net/html/applications/core/modules/admin/settings/advanced.php(751): IPS\_Task->run() #5 /var/www/atrl.net/html/system/Dispatcher/Controller.php(107): IPS\core\modules\admin\settings\_advanced->runTask() #6 /var/www/atrl.net/html/applications/core/modules/admin/settings/advanced.php(38): IPS\Dispatcher\_Controller->execute() #7 /var/www/atrl.net/html/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\settings\_advanced->execute() #8 /var/www/atrl.net/html/admin/index.php(13): IPS\_Dispatcher->run() #9 {main}

When I try to access the Dashboard of the Admin CP it is timing out. I've checked my server logs and the only response I am getting is that the connection timed out. This happens after about 30 seconds. What would be causing this and how can I fix it? 2022/12/24 13:35:17 [error] 1288#1288: *228311 upstream timed out (110: Connection timed out) while reading response header from upstream, client: xxx.xx.xx.xxx, server: demo.com, request: "GET /admin/?app=core&module=overview&controller=dashboard HTTP/2.0", upstream: "fastcgi://unix:/run/php-fpm/www.sock", host: "demo.com", referrer: "https://demo.com/admin/?app=core&module=members&controller=members&do=view&id=36247

@Jim M We officially launched with our new server as I thought that may just be an issue on the test server as you mentioned but no such luck. The issue seems to still be there. I removed all the plugins/apps except 1 app and 2 plugins that failed to remove not sure if that is part of the issue or not and not sure how to get rid of those. Where do you find the 500 errors? I was looking through my NGINX logs and I do not see any 500 errors being reported so if you can tell me where to find them I may have a better idea what is causing them. Thanks for your assistance!

@Jim M this will be our new production site. So you are saying I have launch a website that is broken for you to be able to help with it?

@Jim M I re-added them. Also please make sure you read the notes as this is the test site that we are currently having issues with so if you are trying to login to our production site that will not work.

@Jim M I just updated those credentials earlier today. Can you please elaborate on what isn't working as I verified all the login information worked before I added it.

Yes, I am using cron. The crontask does point to /usr/bin/php but I've verified that as root the /usr/bin/php returns version 8.0.26 (which the con task runs as root) and PHP7 has never been installed on this server. Also other tasks appear to be running just fine, this is the only task that is stuck.