I installed sphinx-2.2.11 on my CentOS 7
yum install -y postgresql-libs unixODBC wget
http://sphinxsearch.com/files/sphinx-2.2.11-1.rhel7.x86_64.rpm yum
install sphinx-2.2.11-1.rhel7.x86_64.rpm
Installation went without any errors and then I created sphinx config and installed php extension (also all without error)
I restart apache (httpd) and
I tried to START sphinx service
systemctl start searchd
I got this message
Job for searchd.service failed because a configured resource limit was > exceeded. See "systemctl status searchd.service" and "journalctl -xe" for details.
after launch command - systemctl status searchd.service
May 02 20:28:57 kvmde43-10657.fornex.org systemd[1]: Failed to read
PID from file /var/run/sphinx/searchd.pid: Invalid argument May 02
20:28:57 kvmde43-10657.fornex.org systemd[1]: Failed to start
SphinxSearch Search Engine.
In fact I havn't "searchd.pid" anywhere at system though installation went good) How should I fix it ?
Thanks in advance
I have just resolved this issue.
I took a look at sphinx log /var/log/sphinx/searchd.log
and noted that some data files under folder /var/log/sphinx/data/ are Permission denied;
I set chown sphinx:sphinx on /var/log/sphinx/data/ folder and It started to work as charm )
Thanks
Same symptom with a slightly different cause...
/var/log/sphinx/searchd.log shows
FATAL: failed to open '/var/data/binlog.lock': 13 'Permission denied'
Fixed by adding binlog_path = to the searchd section of sphinx.conf. Empty path disables binary logging which by default tries to open files in /var/data owned by root. Alternatively, you can supply a valid path writeable by sphinx.
The Sphinx search index is a database distributed over several files in the /var/lib/sphinx/ folder. Those file names start with the doc prefix which is the index name as configured in /etc/sphinx/sphinx.conf.
The searchd service also stores the binlog files in that folder to be able to restore the Sphinx functionality in case of the system crash. If you cannot start the searchd service because it cannot create a binlog file, try to move or delete all binlog.* files from this folder and then start the service.
Related
so I just started upgrading all of our centos 8 servers to centos stream and the first one seemed to go pretty smoothly with just these commands:
dnf install centos-release-stream
dnf swap centos-{linux,stream}-repos
dnf distro-sync
but then when I tried to log in with my AD creds it wouldn't let me in. I already tried rejoining the domain and making sure my creds are still good. The only error is in the messages log which says:
Credentials cache I/O operation failed I found something that says it's because the cache files don't exist in /tmp so I copied them over from one of my other servers but still no luck. No other errors or anything useful in other log files just incorrect password logs in secure. I was just wondering if anyone else has run into this issue.
systemctl stop sssd-kcm
rm /var/lib/sss/secrets/*
systemctl start sssd-kcm
I have been racking my brain on this issue, and probably have tried every possible solution ( fix, purge, reinstall), but postgresql doesn't start
rupin#linuxbox:~$ sudo /etc/init.d/postgresql restart
[sudo] password for rupin:
Restarting PostgreSQL 10 database server
Failed to issue method call: Unit postgresql#10-main.service failed to load: No such file or directory. See system logs and 'systemctl status postgresql#10-main.service' for details.
The Log file is empty. There is no postmaster.pid file that could be to blame.
My Ubuntu Laptop crashed and the DB was active when the system crashed.
Can someone advise what I can do to fix this issue and start the server again?
**Update **
rupin#linuxbox:~$ systemctl status postgresql#10-main.service
Failed to issue method call: No such interface 'org.freedesktop.DBus.Properties' on object at path /org/freedesktop/systemd1/unit/postgresql_4010_2dmain_2eservice
Become OS user postgres.
Try to start PostgreSQL with
pg_ctl start -D /etc/postgres/10/main
(Use the path where postgresql.conf resides.)
Then you will see the error and you will know what to do about it.
I followed the instructions of the answer from https://askubuntu.com/questions/873091/postgresql-fails-to-reinstall-after-upgrading-ubuntu-12-04-to-14-04
I ended up removing systemd
sudo apt-get purge systemd && sudo apt-get autoremove
And I was able to reinstall postgres. Unfortunately, I lost my data/cant trace it. It is okay for me, because it is my local DB
Our postgres database (version 9.4 instaled on Debian) stopted working (it has been working for several month withouth problem). When I try to connect using psql I get:
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
When I check status it seems ok:
service postgresql status
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: active (exited) since Mon 2018-11-05 17:04:58 CET; 31s ago
Process: 1367 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 1367 (code=exited, status=0/SUCCESS)
I tried to restart server
service postgresql restart
and in log file I have got
FATAL: could not access file "pg_stat_statements": No such file or directory
I have tried to find a solution. Mostly the answers are that there is a problem with pg_stat_statements module. I checked the /etc/postgresql/9.4/main/postgres.conf file but the line was commented:
#shared_preload_libraries = '' # (change requires restart)
As I know we haven't change any postgres configuration files and we haven't done any upgrade or update recently. Thank you in advance for your help.
I fixed the problem with installing
postgresql11-contrib-11.7-1PGDG.rhel8
pay attention that official (pgdg11 repo) RPM for RHEL8/CentOS/Fedora has version (i.e. 11) in packet name:
postgresql11-contrib
P.S Yum also installed dependencies: perl-Carp-1.42-396.el8.noarch perl-Exporter-5.72-396.el8.noarch perl-libs-4:5.26.3-416.el8
I had ever met with the same problem. But later found the cause is that I was running the psql command "alter system set shared_preload_libraries='pg_stat_statements';", which overwrite the PostgreSQL.auto.conf under the $PGDATA path. And, as a consequence, when restarting the postgesql instance again by issuing the "service postgresql start", the postmaster process will read the parameter "shared_preload_libraries" from the conf file "postgreSQL.auto.conf" under $PGDATA instead of from /etc/postgresql/10/main/postgres.conf. where the parameter = ''. So, please comment out the parameter shared_preload_libraries='pg_stat_statements' in postgresql.auto.conf if you want to solve the issue. Thanks.
At the end I have installed pg_stat_statements and then I was able to start postgresql.
Added to postgres.conf:
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all
pg_stat_statements.max = 10000
track_activity_query_size = 2048
Installed package postgresql-contrib-9.4:
apt-get install postgresql-contrib-9.4
Restarted postgresql service:
service postgresql restart
I met this issue today, and there are 2 problems I found which blocked me:
The version of the postgresql-contrib must match the postgresql-server version, however the official repo may provide different versions. In my case, following repo https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-7-x86_64/pgdg-centos95-9.5-3.noarch.rpm
provided
postgresql-contrib.x86_64 9.2.24-1.el7_5 base
with
postgresql95-server.x86_64 9.5.16-1PGDG.rhel7 #pgdg95
and as you can see the version doesn't match. I found the postgresql-contrib:9.5.16 which is the right version at https://download.postgresql.org/pub/repos/yum/9.5/redhat/rhel-7-x86_64/
If you cannot find the right version, you may build it by yourself:
https://www.postgresql.org/docs/current/contrib.html
I have to install the postgresql-contrib before install postgresql95-server. There is a defect reported at https://github.com/sous-chefs/postgresql/pull/241
I cannot find a better workaround for the 2nd issue.
I've updated jdk from 1.8_131 to 1.8_151 for CDH5. So i need to restart the cluster to make it take affect. In the begining i use cloudrea manager web page to restart, but it failed when zookeeper started which is the first step. Then I made a bad choice which is close cloudrea manager in terminal including kill -9 postgresql process. After that, i could't open the cloudrea manager web page.
I use following instructions to start the cluster.
service cloudera-scm-server-db start
service cloudera-scm-server start
service cloudera-scm-agent start
All of them are failed, because /var/log/cloudera-scm-server and /var/log/cloudera-scm-agent disappear.
So I creat these two files manually also include dg.log and cloudera-scm-agent.log
At this time, the server and agent could start. But server-db still can not. The next is some details.
Starting cloudera-scm-server-db (via systemctl): Job for
cloudera-scm-server-db.service failed because the control process
exited with error code. See "systemctl status
cloudera-scm-server-db.service" and "journalctl -xe" for details
journalctl -xe
The CM is using external DB. Failed to start embedded DB service, giving up
service --status-all
What i've done:
So, what should i do now? thank you thank you very much!!!
The above problem had been sovled.
If you open this /etc/cloudera-scm-server/db.properties file, which shown as below.
# cat /etc/cloudera-scm-server/db.properties
Auto-generated by scm_prepare_database.sh
#
Sat Oct 1 12:19:15 PDT 201
#
com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=TXqEESuhj5
com.cloudera.cmf.db.setupType=EXTERNAL
EXTERNAL is the crux.
In my CDH service, I use embedded postgresql as my server database. But it's not recommended to use by cloudera offical. I'm a new man on Cloudera, so I made a mistake.
I wrongly use a command which only prepared for Cloudera Manager Server external database.
/usr/share/cmf/schema/scm_prepare_database.sh postgresql scm scm scm_password
The above command can config db.properties
As long as you run above command, com.cloudera.cmf.db.setupType will be set to EXTERNAL(For more details about this, you can find in Cloudera docs)
The most direct and effective way is to reset password of scm.
Then
update the password
set Type as EMBEDDED
make port 7432 listening(you can use netstat -nltp to check)
in db.properties.
#vim cat /etc/cloudera-scm-server/db.properties
Auto-generated by scm_prepare_database.sh
Sat Oct 1 12:19:15 PDT 201
com.cloudera.cmf.db.type=postgresql
com.cloudera.cmf.db.host=localhost:7432
com.cloudera.cmf.db.name=scm
com.cloudera.cmf.db.user=scm
com.cloudera.cmf.db.password=new_password
com.cloudera.cmf.db.setupType=EMBEDDED
Now close all cloudera-scm service and restart in order server-db,server,agent.
If /var/log was cleared wrongly.
You can creat these files such as /var/log/cloudera-scm-server and /var/log/cloudera-scm-agent manually.
It is noteworthy that you should creat these file by user cloudera-scm, otherwise the log can not be written, and you won't find what error happened from log file.
I am starting with a clean install of Fedora 15 on a VirtualBox VM and trying to install Zend Server CE. To install, I adding the Zend repo to yum and ran:
sudo yum install zend-server-ce-php-5.3
The installation itself seemed to go very well. I opened the browser at http://localhost:10081/ZendServer as directed. After clicking through the license page and entering an administative password I get the error:
Failed to access Web server. Please make sure that the Web server is running and listening to the correct port
The Applications, Rules Management and Administration tabs function properly but the Monitor and Server Setup tabs both display the above error. It is a fact that the web server is not running, but when I try to rectify that I get another error:
$ sudo service httpd start
[sudo] Password for XXXXX:
Starting httpd (via systemctl): Job failed. See system logs and 'systemctl status' for details.
[FAILED]
For what it's worth (not much, I'm guessing) here are the details the message refers to:
$ sudo tail /var/log/messages
....
Jan 17 17:24:18 M5 systemd[1]: httpd.service: control process exited, code=exited status=1
Jan 17 17:24:18 M5 systemd[1]: Unit httpd.service entered failed state.
$ systemctl status httpd.service
httpd.service - LSB: start and stop Apache HTTP Server
Loaded: loaded (/etc/rc.d/init.d/httpd)
Active: failed since Tue, 17 Jan 2012 17:24:18 -0500; 3min 44s ago
Process: 19500 ExecStart=/etc/rc.d/init.d/httpd start (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/httpd.service
The diagnostics don't seem very helpful. I've tried various things, such as installing and starting httpd before installing Zend Server CE, reinstalling httpd (no good: unistalling it caused Zend to uninstall too). The httpd config isn't causing the problem as the following output demonstrates:
$ /usr/sbin/apachectl configtest
Syntax OK
Is this a know problem? What's my next move? Do I start putting debug statements in the control script to see what's failing? I can do that, but I'm hoping someone out there has dealt with this problem and can give me a quick solution.
I was able to get better information on the cause of the problem by invoking the apachectl script directly rather than using the service:
$ sudo /usr/sbin/apachectl start
httpd: Syntax error on line 220 of /etc/httpd/conf/httpd.conf: Syntax error on line 6 of /etc/httpd/conf.d/zendserver_php.conf: Cannot load /usr/local/zend/lib/apache2/libphp5.so into server: /usr/local/zend/lib/apache2/libphp5.so: cannot enable executable stack as shared object requires: Permission denied
The syntax check on httpd.conf didn't catch this because it's not really a syntax error and it's not in httpd.conf either, but in the included zendserver_php.conf. A quick search shows that this error is the result of libphp5.so violating one of the constraints that SELinux enforces. SELinux is enabled by default in Fedora 15.
I don't like to reduce security, but that the only way I've seen this issue addressed. So I disabled SELinux temporarily with the command
$ sudo setenforce 0
I also edited /etc/selinux/config and changed SELINUX=enforced to SELINUX=disabled so SELinux would stay disabled on reboot. Now my web server starts without a hitch:
[mike#M5 ~]$ sudo service httpd start
Starting httpd (via systemctl): [ OK ]
I would like to think someone in the Zend development community is working on this shared library issue. Reducing security is not an acceptable work-around in a lot of cases. If anybody has a better solution, I'd still like to know it.