8.5.1 fails to install on Virtualmin Virtual Server - Ubuntu 22.04 PHP 8.3

Hello, before you shoot me down and suggest noddy answers to what is clearly a complex problem. Please read this post fully.

I have a virtualmin host with a virtual server. The virtual server is already running a variety of applications perfectly well. There are no Apache or PHP issues. Wordpress runs perfectly as does Roundcube webmail.

The install target is a sub folder of the webroot with a redirect configured to send all domian.com/crm to the correct sub directory of the web root. The installer web page comes up. And all seems ok apart from the install fails with the following message.

I spent half a day trying to get to the bottom of it. Started again and tried the command line install. Failed! Tried creating the DB first just in case it was some kind of DB create problem. Fails!

This is what I get from the command line install:

SuiteCRM Silent Install
============

Running: check-install-lock
step: check-install-lock | status: done
Installer not locked. Proceeding with install
Running: check-db-connection
step: check-db-connection | status: done
DB credentials ok
Running: install-system-checks
step: install-system-checks | status: done
Running: create-config
step: create-config | status: done
Created silent install config: config_si.php
Running: create-env
step: create-env | status: done
Created .env.local
Running: run-legacy-install
18:03:29 CRITICAL  [php] Fatal Compile Error: Duplicate declaration of static variable $sfh ["exception" => Symfony\Component\ErrorHandler\Error\FatalError^ { …}]

In aow_utils.php line 645:
                                                                
  Compile Error: Duplicate declaration of static variable $sfh  
                                                                

suitecrm:app:install [-U|--db_username DB_USERNAME] [-P|--db_password DB_PASSWORD] [-H|--db_host DB_HOST] [-Z|--db_port DB_PORT] [-N|--db_name DB_NAME] [-u|--site_username SITE_USERNAME] [-p|--site_password SITE_PASSWORD] [-S|--site_host SITE_HOST] [-d|--demoData [DEMODATA]] [-W|--sys_check_option SYS_CHECK_OPTION]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!DOCTYPE HTML>
<html lang='en_us'>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <meta http-equiv="Content-Script-Type" content="text/javascript">
   <meta http-equiv="Content-Style-Type" content="text/css">
    <title> </title>
   <link REL="SHORTCUT ICON" HREF="include/images/sugar_icon.ico">
   <!-- <link rel="stylesheet" href="install/install.css" type="text/css" /> -->
   <script type="text/javascript" src="install/installCommon.js"></script>
   <link rel="stylesheet" href="install/install2.css" type="text/css" />
   <script type="text/javascript" src="install/installCommon.js"></script>
   <script type="text/javascript" src="install/siteConfig.js"></script>
<link rel='stylesheet' type='text/css' href='include/javascript/yui/build/container/assets/container.css' />
<link rel="stylesheet" href="themes/suite8/css/fontello.css">
    <link rel="stylesheet" href="themes/suite8/css/animation.css"><!--[if IE 7]><link rel="stylesheet" href="css/fontello-ie7.css"><![endif]-->
</head>
<body onload="javascript:document.getElementById('button_next2').focus();">
<!--SuiteCRM installer-->
<div id="install_container">
<div id="install_box">
<header id="install_header">
                    <div id="steps">
                        <p></p>
                        <i class="icon-progress-0" id="complete"></i>
                        <i class="icon-progress-1" id="complete"></i>
                        <i class="icon-progress-2"></i>
                    </div>
            <div class="install_img"><a href="https://suitecrm.com" target="_blank"><img src="include/images/sugar_md_open.png" alt="SuiteCRM"></a></div>
</header><b> (config.php)</b><br><br><b></b><br> assdb_suitecrm  localhost...<br>.

I have no idea how to debug this or where to start.

If anyone can assist in getting this up and running that would be greatly appreciated.

Nothing in the virtual server apache error log or the php error log.

CheersS
Tony

Please use PHP 8.1 or PHP 8.2 version.

SuiteCRM 8 Upgrade Tutorial Walkthrough Step by Step video

with 8.1.27 set for this virtual server then I get exactly the same error.

php -v
PHP 8.1.27 (cli) (built: Dec 21 2023 20:19:54) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.27, Copyright (c) Zend Technologies
with Zend OPcache v8.1.27, Copyright (c), by Zend Technologies

18:54:39 CRITICAL [php] Fatal Compile Error: Duplicate declaration of static variable $sfh [“exception” => Symfony\Component\ErrorHandler\Error\FatalError^ { …}]

In aow_utils.php line 645:

Compile Error: Duplicate declaration of static variable $sfh

On checking this file there are indeed 2 static variable declarations for $sfh

I am not a php developer but this look slike a bug.

Cheers
Tony

Can you tell me what logs or give logs for your attempt via the installer route? Am familiar with webmin for suite install but without any concrete logs it could be a myriad of things? And I’m most familiar with the gui install :smiley:

Nothing shows up in the virtual server php error logs or the apache logs. Also now I am running 8.1.27 for this virtual server the server meets all compatibility.

The thing that jumps out at me is there are indeed 2 static declarations in that php file!

Cheers
Tony

The suitecrm.log from the public dir is ok if it’s populated anything and install.log too same directory

Thanks for the replies. Timed out toady. Will have another go tomorrow on a staging server.

Cheers
Tony

I’ve seen that sfh error recently, I’m not sure is it was here in the forums, or on GitHub. I can’t go search for it right now, but you can try and hopefully there will be some help there.

I also suggest clearing the symfony cache.

I fear that getting everything installed on an unsupported PHP 8.3, and then changing it, might not be enough to get a working installation. We don’t know which parts of the installer had problems with the unsupported PHP…

Yes we deleted the entire sub directory containing the installation. Dropped all the tables from the DB and started from scratch after dropping the virtual server down to php 8.1.27.

The install then worked via the ui (didn’t try via command line)

But there are still php issues which seem to be stopping us using it! Need to solve as need this inproduction.

Any more log messages from the “two logs” linked above?

Any errors in the browser’s developer console? Any errored requests on the Network tab there?

There is nothing apart from what I already reported. The latest version 8.5.1. we cannot add images to products but can add images to user records.

Again I can find nothing in the logs. The product image fine name is never seen by the browser dev console or in the logs.

Cheers
Tony

I’m running both ubuntu dedicated server v8,5 and also Virtualmin for the comparison tests. I had similar issue with the CLI version of PHP not being the same version as Suitecrm runs during install. You can check what SuiteCRM is seeing by going to the Admin page and running diagnostics for the phpinfo and check the PHP version. It might not be what you saw in CLI. That is an easy fix if not PHP 8.2 or 8.1,

My work reveals the ubuntu clean server acts differently than the same ubuntu in Virtualmin.
Vanilla ubuntu server will install files and directories as crm:crm [whatever your user is] for ownership state. Virtualmin will do the same with some root ownerships tossed in. Virtualmin requires the correct owner to operate but it will be running under apache (my previous Centos7 test server) or www-data in the case of current ubuntu servers.

You will find the ownerships when you run the FIND commands post-install and I recommend piping the output to log files to compare what changes as you run SuiteCRM. They will change. I found I needed different attention to the Crontab permissions, directory and file ownerships compared to the version not running on Virtualmin. I believe this is because SuiteCRM is not self-aware of its ownership status or the server it is running on (it should be). The fact it didn’t flag an unapproved PHP version is symptomatic of the issues you will be seeing. IMO you cannot possibly run production v8.5 on Virtualmin today unless you are doing daily backups and can afford to lose a day’s transactions. Also, if you are running v8.51 think twice about going to the next version. It will be another mess as we’ve experienced from each version since v8 beta. Upgrades tend to wipe fixes you have made so just stick with v8.51 it if you get it working on Virtualmin.

My understanding from the server guys is that virtualmin will want the “crm” owner to own files and directories. Virtualmin will balk because it will be running as apache or www-data.

if you wish to share findings I think the Virtualmin fix is the way to go because of the features for casual users (like me). The bottom line is same installation on Linode servers acts differently for a virtualmin server. They don’t work equally and this adds confusion to an already troubled v8x.

Not sure. By default, Virtualmin runs PHP applications with PHP-FPM mode, the best mode of running PHP for web applications. The user account’s username and group, is the one Suite is installed on. So when you install Suite under the account mycompany, then the default directory is /home/mycompany/public_html/ or optionally a subdirectory under /home/mycompany/homes/username/. You probably should install under a subdomain (in Virtualmin, a “virtual server” for your subdomain) to keep the CRM application at crm.myorganization.tld and its database, separate from your organization website at www.myorganization.tld and its database.

We have been using Virtualmin for well over a decade. Modern versions use PHP-FPM and the process owner and group are the same as the virtual server. mydomain:mydomain

Running find across the installation folder does not show up any inconsistencies in owner and group permissions. Although my process is to install via the gui and then before logging in run the fix permissions commands.

It is always installed in a subdirectory under the /public_html webroot.

Also redirection complexity is also annoying. The only way I have found to make it work is to setup a web redirection in the virtual server for mydomain using an explicit folder like /home/mydomain/public_html/suitecrm/public/

Seems to work but it would be great to have all of that inside the installation root.

We are just coming back to this after a good few years away.

Cheers
Spart