一、问题原因

    该问题可能是数据库服务没有启动或数据库没有初始化。




二、解决办法

1、检查数据库服务启动情况
      如果数据库服务未启动,请先启动。 

      如果数据库启动报错,请查看系统和数据库日志,对应排查服务启动失败原因,直至成功启动。
      如下是一个数据库启动失败的例子。

      查看数据库日志(Linux默认日志路径在/var/i2data/pgsql/data/log/)后,判定为pg_wal误删,引起启动报错checkpoint(检查点)找不到
      这种情况的解决办法是:
su - postgres
postgres pg_resetwal -f /var/lib/postgresql/data/



2、检查数据库是否初始化
      如果数据库服务已经启动,但仍然还出现该报告,则需要进行数据库初始化。
      可手动进行数据库初始化,或采用如下介绍的方式,来完成该工作。





如得到如上弹窗反馈,则说明已初始化数据库成功,可尝试重新登录。


Windows的控制机,如果点击后得到如下反馈“Oh no! A problem with the Ajax request!”,请检查数据库监听是否被修改。
(Linux的排查方法见后文)


Windows查看数据库监听的方法如下:
可查看 C:\Program Files (x86)\info2soft\ctrlcenter\pgsql\data\postgresql.conf 文件中的port配置,或根据下述步骤查看当前监听端口。

(1)进程管理器,找到postgres.exe的PID;


(2)查看主机端口监听情况,根据PID找到postgres数据库的当前监听端口;
    本例中,默认的监听端口(58083)已经被改过,所以当前数据库监听的是38083端口。此时,需要查看database.php文件,检查DB连接部分的端口配置是否也做了对应修改,如没有做修改,需要同步进行修改。


(3)检查和修改database.php
    该文件的默认存储路径是:
C:\Program Files (x86)\info2soft\ctrlcenter\wwwroot\default\application\config\database.php
    如DB监听端口做了修改,则上述文件中所有的58083部分都需要做对应修改。



  将该文件中所有旧的端口改成新的端口,再尝试登录即可。



如果是Linux的控制机,遇到“Oh no! A problem with the Ajax request!”,也是类似的操作,需要检查数据库监听是否被修改,请进行如下操作。

1、查看数据库监听端口
netstat -anp|grep PGSQ
本例中,默认的58086端口被修改过,因此此处看到的是监听了38086、


2、检查database.php
vim /var/i2data/www/default/application/config/database.php
检查该文件中的'port' =>对应的值是否与当前数据库监听端口对应,如不相同,请全部进行修改(三处都需要对应修改)。


  将该文件中所有旧的端口改成新的端口,再尝试登录即可。