My forum suddenly now gives the
QuoteConnection Problems
Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later.
error. I didn't upgrade the database (Postgres), the webserver, or PHP. How can I debug what's going on?
repair_settings.php says:
QuoteSome settings are not being shown because the database connection information is incorrect.
Check your database login details, table prefix and that the database actually contains your SMF tables.
They do contain all these things.
I even changed my database password and updated Settings.php, to no avail.
In both cases, that error simply means your database can't be used for one reason or another.
So that's what I would turn my attention to, is the database and database server OK and reachable?
Quote from: Geremia16 on October 22, 2022, 11:26:40 PMConnection Problems
Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later.
If the database details are correct, the issue lies with the host. Have you contacted them? But seeing the other error quoted below, I think that the database info are not correct. Double check all the database info again to make really sure that everything is correct. Another thing to check for is the database user 's permissions to the database.
Quote from: Geremia16 on October 22, 2022, 11:26:40 PMSome settings are not being shown because the database connection information is incorrect.
Check your database login details, table prefix and that the database actually contains your SMF tables.
Quote from: Doug Heffernan on October 23, 2022, 08:21:05 AMIf the database details are correct, the issue lies with the host. Have you contacted them?
I am the DB host.
Quote from: Doug Heffernan on October 23, 2022, 08:21:05 AMBut seeing the other error quoted below, I think that the database info are not correct. Double check all the database info again to make really sure that everything is correct.
I'm at a loss about what changed. It was working just fine.
After I ran into the connection issues problem, I changed the database password and updated Settings.php, but I'm still getting the same issue.
Quote from: Doug Heffernan on October 23, 2022, 08:21:05 AMAnother thing to check for is the database user 's permissions to the database.
I can run
sudo -u postgres psql just fine.
Quote from: Aleksi "Lex" Kilpinen on October 23, 2022, 01:19:26 AMSo that's what I would turn my attention to, is the database and database server OK and reachable?
Yes, the DB runs locally, and runs just fine. The issue is the connection to the database.
pg_hba.conf:# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trustShould the method be something different? I tried scram-sha-256, too, but to no avail.
🆗, so there was an issue with
; Enable pgsql extension module
extension=pgsql.soof /etc/php.d/pgsql.ini not being commented out. Now,
<?php
$connection = pg_connect ("host=localhost dbname=smf user=postgres password=<redacted>");
if($connection) {
echo 'connected';
} else {
echo 'there has been an error connecting';
}
?>returns "connected", but the SMF forum still says
QuoteConnection Problems
Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later.
I'm still getting "Connection Problems". How can I find out why?
Talk to your host
Quote from: Kindred on October 25, 2022, 07:59:38 PMTalk to your host
As I mentioned above, I am the database host, and PHP's pg_connect() function connects to it just fine. It's an SMF issue.
What version of SMF?
What version of PHP?
What version of pg?
Something must have changed... You cannot think of any updates made around the time this started?
Quote from: Geremia16 on October 25, 2022, 11:45:50 PMIt's an SMF issue.
If the database details have been entered correctly to the Settings.php file, then it is not a Smf issue at all.
In your op you say:
Quote from: Geremia16 on October 22, 2022, 11:26:40 PMMy forum suddenly now gives the
Quote from: Geremia16 on October 22, 2022, 11:26:40 PMMy forum suddenly now gives the
QuoteConnection Problems
Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later.
That never happens suddenly, just out of blue. Something must have triggered it. What was the latest change/nodification made prior to that happening.
Note there was a similar error for mysql users, caused by a PHP issue where it did not fully support more recent DB versions (e.g., mysql 8.0) on old (< 7.4) versions of PHP. The fix there was to alter the user to use a more old school authentication plugin. My initial suspicion is we are seeing something similar on the pg side.
Reference: https://www.simplemachines.org/community/index.php?topic=574573.0
But the examples we saw earlier were triggered by php/db upgrades.
My second suspicion is PHP 8.1 - which has big problems with pg on SMF 2.0.x.
This is why knowing the SMF version, PHP version, and pg version would help.
Are you seeing the errors permanently or intermittently?
Which OS and release are you using?
Did you install
any updates, added IP addresses, changed
anything?
If you compare Settings.php and Settings_bak.php, does everything look ok? Do you have backups (of files and the db) that you can compare to?
Quote from: Geremia16 on October 23, 2022, 06:26:21 PMQuote from: Doug Heffernan on October 23, 2022, 08:21:05 AMAnother thing to check for is the database user 's permissions to the database.
I can run
sudo -u postgres psql just fine.
Surely your SMF uses a different user? Can you login with that user?
Quote from: Geremia16 on October 23, 2022, 06:33:39 PMpg_hba.conf:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
[...]Should the method be something different? I tried scram-sha-256, too, but to no avail.
I've never tested with "trust" and don't know how it works (I guess you don't need a password on login?), might not work with SMF. Reading the docs (https://www.postgresql.org/docs/current/auth-trust.html) ("anyone who can connect to the server is authorized to access the database with whatever database user name they specify (even superuser names)") I think you'd want a different method just to have more security.
Quote from: Geremia16 on October 23, 2022, 06:51:00 PM$connection = pg_connect ("host=localhost dbname=smf user=postgres password=<redacted>");
Ugh, you really
are using the main postgres user. I hope at least SMF is the only software using the DB?
Quote from: shawnb61 on October 26, 2022, 01:27:20 PMSMF version, PHP version, and pg version
2.1.1
7.4.32
15.0,
respectively
Quote from: m4z on October 26, 2022, 02:22:47 PMyou really are using the main postgres user. I hope at least SMF is the only software using the DB?
Yes.
So the connection is erroring out for some reason.
Note that SMF won't display internal DB errors to an end user (just the generic 'connection issues') error. So, I think there are two ways to get it to give us the error:
(1) Create a new DB and perform a new install of 2.1.2. Since SMF knows the admins are doing installs, it will display detailed error info.
(2) Echo the error being produced. Early in Subs-Db-postgresql.php, ~line 97 or so, you will see $pg_connect_error and $pg_connect_errno getting populated. Display those.
I don't yet have a pg15 install. In my pg14 install, all the methods are scram-sha-256.
Quote from: shawnb61 on October 27, 2022, 12:16:06 AM(1) Create a new DB and perform a new install of 2.1.2. Since SMF knows the admins are doing installs, it will display detailed error info.
"install.php?step=2" is a blank page. I get lots of errors in error_log:
[Thu Oct 27 17:16:48.006075 2022] [php7:notice] [pid 21416:tid 140032570541760] [client ::1:48266] PHP Notice: Trying to access array offset on value of type null in /var/www/htdocs/smf/install.php on line 386, referer: https://<redacted>/smf/install.php?step=0
[Thu Oct 27 17:16:48.006165 2022] [php7:notice] [pid 21416:tid 140032570541760] [client ::1:48266] PHP Notice: Undefined index: in /var/www/htdocs/smf/install.php on line 818, referer: https://<redacted>/smf/install.php?step=0
[Thu Oct 27 17:16:48.006178 2022] [php7:notice] [pid 21416:tid 140032570541760] [client ::1:48266] PHP Notice: Trying to access array offset on value of type null in /var/www/htdocs/smf/install.php on line 818, referer: https://<redacted>/smf/install.php?step=0
[Thu Oct 27 17:16:48.006208 2022] [php7:error] [pid 21416:tid 140032570541760] [client ::1:48266] PHP Fatal error: Uncaught Error: Function name must be a string in /var/www/htdocs/smf/install.php:818\nStack trace:\n#0 /var/www/htdocs/smf/install.php(164): DatabaseSettings()\n#1 {main}\n thrown in /var/www/htdocs/smf/install.php on line 818, referer: https://<redacted>/smf/install.php?step=0Quote from: shawnb61 on October 27, 2022, 12:16:06 AM(2) Echo the error being produced. Early in Subs-Db-postgresql.php, ~line 97 or so, you will see $pg_connect_error and $pg_connect_errno getting populated. Display those.
Wow, those errors are all over the place. Feels more like an OS level issue.
This looks like you are missing all or part of critical files, e.g., Settings.php... Line 386 is trying to access your default language (from settings.php) and line 818 is accessing your db type (from settings.php).
I would start by re-copying all files from the install .zip, and triple checking file permissions throughout your file system.
I would confirm all files in the install .zip are in your file system. Count them. And that they are writeable.
And trying the install again.
Also, if you have mod security enabled, disable it...
I would also view settings.php. Make sure it looks good.
Quote from: shawnb61 on October 27, 2022, 09:37:33 PMtriple checking file permissions throughout your file system.
I see files are 644. Is that what they should be?
Quote from: shawnb61 on October 27, 2022, 11:34:35 PMI would also view settings.php. Make sure it looks good.
It's not being updated by install.php. I manually edited it, and I still get the same issue.
You need to figure out WHY it cannot be updated.
Quote from: m4z on October 26, 2022, 02:22:47 PMAre you seeing the errors permanently or intermittently?
Which OS and release are you using?
Did you install any updates, added IP addresses, changed anything?
If you compare Settings.php and Settings_bak.php, does everything look ok? Do you have backups (of files and the db) that you can compare to?
You didn't answer any of this. Help us help you.
Something must have changed for SMF to not work anymore.
Quote from: Geremia16 on October 28, 2022, 12:13:02 AMQuote from: shawnb61 on October 27, 2022, 09:37:33 PMtriple checking file permissions throughout your file system.
I see files are 644. Is that what they should be?
To answer that, we need to know more about your system. Based on the name "error_log" and the file format, I assume your webserver is apache. What user is it running as? (Answering the question which OS/distro you're using could already have helped answer that.) Which user (and group) do the SMF files belong to? What are the directory permissions (and, depending on the answer, user and group permissions) of your SMF folder and those leading up to it? Did you change permissions or umask recently? Are you using filesystem access control lists (ACLs) or advanced mandatory access controls (MACs) like SELinux or AppArmor?
For example / comparison, here's what I'm usually using currently:
- OS: Debian 11
- DB: Postgres 13.7 (d11 default)
- Webserver: nginx (with nginx or debian default user "www-data")
- PHP: 7.4 (php-fpm because nginx needs it)
- Separate user (usually named "${something}-smf") for SMF install (also works well with how Debian manages Postgres)
In my setup, all my files belong to the user "${something}-smf" and group "www-data". For my setup, I need to chown all SMF files to 775 (of course, technically that's only for the dirs, but I'm lazy and I don't see a big attack vector here).
Edit: When installing, did you follow the docs (https://wiki.simplemachines.org/smf/Installing)?
Edit 2: Based on sudo usage, I'm loosely assuming you're using Ubuntu or similar. Is your setup similar to this (https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-22-04#step-4-creating-a-virtual-host-for-your-website)?
Quote from: m4z on October 26, 2022, 02:22:47 PMAre you seeing the errors permanently or intermittently?
permanently
Quote from: m4z on October 26, 2022, 02:22:47 PMWhich OS and release are you using?
slackware64-current
Quote from: m4z on October 26, 2022, 02:22:47 PMDid you install any updates, added IP addresses, changed anything?
The web server, yes, but nothing that effects the forum virtual host.
Quote from: m4z on October 26, 2022, 02:22:47 PMIf you compare Settings.php and Settings_bak.php, does everything look ok? Do you have backups (of files and the db) that you can compare to?
No changes.
Quote from: Geremia16 on October 28, 2022, 08:44:17 PMQuote from: m4z on October 26, 2022, 02:22:47 PMDid you install any updates, added IP addresses, changed anything?
The web server, yes, but nothing that effects the forum virtual host.
What did you change and did SMF ever work after the change?
Quote from: m4z on October 29, 2022, 03:02:59 AMWhat did you change and did SMF ever work after the change?
Yes.
I'm not sure why, but it seems to be a PHP issue. "install.php?step=2" is always a blank page:
Quote from: Geremia16 on October 27, 2022, 08:19:41 PM"install.php?step=2" is a blank page. I get lots of errors in error_log:
[Thu Oct 27 17:16:48.006075 2022] [php7:notice] [pid 21416:tid 140032570541760] [client ::1:48266] PHP Notice: Trying to access array offset on value of type null in /var/www/htdocs/smf/install.php on line 386, referer: https://<redacted>/smf/install.php?step=0
[Thu Oct 27 17:16:48.006165 2022] [php7:notice] [pid 21416:tid 140032570541760] [client ::1:48266] PHP Notice: Undefined index: in /var/www/htdocs/smf/install.php on line 818, referer: https://<redacted>/smf/install.php?step=0
[Thu Oct 27 17:16:48.006178 2022] [php7:notice] [pid 21416:tid 140032570541760] [client ::1:48266] PHP Notice: Trying to access array offset on value of type null in /var/www/htdocs/smf/install.php on line 818, referer: https://<redacted>/smf/install.php?step=0
[Thu Oct 27 17:16:48.006208 2022] [php7:error] [pid 21416:tid 140032570541760] [client ::1:48266] PHP Fatal error: Uncaught Error: Function name must be a string in /var/www/htdocs/smf/install.php:818\nStack trace:\n#0 /var/www/htdocs/smf/install.php(164): DatabaseSettings()\n#1 {main}\n thrown in /var/www/htdocs/smf/install.php on line 818, referer: https://<redacted>/smf/install.php?step=0
All of those errors are due to something being undefined:
First one: $matches isn't defined or at least isn't an array.
Second one: $databases isn't defined
Third one: $db_type isn't defined
Fourth one: We try to call $databases[$db_type]['validate_prefix'] but because $databases[$db_type] isn't defined it doesn't have any function to call, so it gives up.
The first one seems to indicate that $_SESSION['installer_temp_lang'] isn't being set, which shouldn't happen but could if no "lang_file" parameter is specified in the query string.
The other two are weird because $databases is set early in install.php and specified as a global variable (so its value will be remembered between functions) and $db_type should be set on line 815.
This appears to be some weird PHP/server issue rather than a Postgres issue.
The issue was a PCRE version mismatch. It should've been 10.40 (2022-04-14), when really it was 10.35 (2020)! Deo gratias (https://www.merriam-webster.com/dictionary/Deo%20gratias) SMF works now!
Thanks for the update.