vanish cache not starting up due to file storage parameter - varnish

I have varnish 4.0 installed on my centos 7 box my params file looks like:
RELOAD_VCL=1
VARNISH_VCL_CONF=/etc/varnish/default.vcl
VARNISH_LISTEN_PORT=80
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
VARNISH_ADMIN_LISTEN_PORT=6082
VARNISH_SECRET_FILE=/etc/varnish/secret
VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin
VARNISH_STORAGE_SIZE=5G
VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}"
VARNISH_TTL=120
VARNISH_USER=varnish
VARNISH_GROUP=varnish
When I start up my varnish I get the following error:
Unit varnish.service has begun starting up.
varnishd[14888]: Error: (-sfile) "${VARNISH_STORAGE_FILE}" does not exist and could not be created
systemd[1]: varnish.service: control process exited, code=exited status=2
systemd[1]: Failed to start Varnish Cache, a high-performance HTTP accelerator.
The owner of the files is varnish, I have run out of ideas how can I get this working.

Related

Elastisearch Enabling Remote Connection - Crashes AFTER Change*

I just installed filebeat, logstash, kibana and elasticsearch all running smoothly just to trial this product out for additional monthly reports/monitoring and noticed every time I try to change the "/etc/elasticsearch/elasticsearch.yml" config file for remote web access it'll basically crash the service every time I make the change.
Just want to say I'm new to the forum and this product, and my end goal for this question is to figure out how to allow remote connections to access elastisearch as I guinea pig and test without crashing elasticsearch.
For reference here is the error code when I run the 'sudo systemctl status elasticsearch' query:
Dec 30 07:27:37 ubuntu systemd[1]: Starting Elasticsearch...
Dec 30 07:27:52 ubuntu systemd-entrypoint[4067]: ERROR: [1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch.
Dec 30 07:27:52 ubuntu systemd-entrypoint[4067]: bootstrap check failure [1] of [1]: the default discovery settings are unsuitable for production use; at least one of [discovery.seed_hosts, discovery.se>
Dec 30 07:27:52 ubuntu systemd-entrypoint[4067]: ERROR: Elasticsearch did not exit normally - check the logs at /var/log/elasticsearch/elasticsearch.log
Dec 30 07:27:53 ubuntu systemd[1]: elasticsearch.service: Main process exited, code=exited, status=78/CONFIG
Dec 30 07:27:53 ubuntu systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
Dec 30 07:27:53 ubuntu systemd[1]: Failed to start Elasticsearch.
Any help on this is greatly appreciated!

couchdb.service: Failed with result 'start-limit-hit'

After I installed couchdb, I could get the welcome information
$ curl localhost:5984
{"couchdb":"Welcome","version":"2.1.2","features":["scheduler"],"vendor":{"name":"The Apache Software Foundation"}}
But I can't check the status by systemctl
$ systemctl status couchdb.service
● couchdb.service
Loaded: not-found (Reason: No such file or directory)
Active: failed (Result: start-limit-hit) since 一 2018-12-03 14:52:14 CST; 6min ago
Main PID: 30946 (code=killed, signal=USR2)
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Unit entered failed state.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Failed with result 'signal'.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Service hold-off time over, scheduling restart.
12月 03 14:52:14 gpuhuawei systemd[1]: Stopped Apache CouchDB.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Start request repeated too quickly.
12月 03 14:52:14 gpuhuawei systemd[1]: Failed to start Apache CouchDB.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Unit entered failed state.
12月 03 14:52:14 gpuhuawei systemd[1]: couchdb.service: Failed with result 'start-limit-hit'.
12月 03 14:53:53 gpuhuawei systemd[1]: Stopped Apache CouchDB.
12月 03 14:53:53 gpuhuawei systemd[1]: Stopped Apache CouchDB.
When I run couchdb by command line, I got
$ couchdb
{"init terminating in do_boot",{{badmatch,{error,{bad_return,{{couch_app,start,[normal,["/etc/couchdb/default.ini","/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,{error,eacces}}},[{couch_server_sup,start_server,1,[{file,"couch_server_sup.erl"},{line,56}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,273}]}]}}}}}},[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
[1] 2288 user-defined signal 2 couchdb
My work enviroment
$ uname -a
Linux gpuhuawei 4.15.0-34-generic #37~16.04.1-Ubuntu SMP Tue Aug 28 10:44:06 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
This is a bit late, but the "start-limit-hit" message is a red herring. I have seen something very similar with a Moodle installation using MySQL and it's actually saying that you (or the service start process) have tried to restart the database too many times or too soon after a failed attempt to start. Basically, this start-limit-hit message is saying "stop trying to do the same thing and expecting different results".
The actual issue will be further up in the syslog. Unhelpfully, service status does not return enough lines of the error messages to actually see what is wrong. Try a service start, and go and look in the actual syslog, and you will see the series of start attempts and a line just above each one hopefully will tell you the actual issue. In my case here, you can see that the problem is the mount point containing the database is missing - thanks, Azure. For one attempt of service start, it tries to start 5 times in quick succession, failing each time because the data dir was not mounted, and on the sixth it fails with the start-limit-hit.
Always back up your data/ and etc/ directories prior to upgrading CouchDB.
We recommend that you overwrite your etc/default.ini file with the version provided by the new release. New defaults sometimes contain mandatory changes to enable default functionality. Always places your customization in etc/local.ini or any etc/local.d/*.ini file.
(I was followed this and it worked)
https://docs.couchdb.org/en/3.0.0/install/upgrading.html

Jboss 7.0 Fails to start in Red Hat

Hi, i'm trying to run Jboss EAP 7.0.0 in Red Hat Enterprise Linux 7, the installation goes well until i need to start the service.
sudo service jboss-eap-rhel start
Redirecting to /bin/systemctl start jboss-eap-rhel.service
Job for jboss-eap-rhel.service failed. See 'systemctl status jboss-eap-rhel.service' and 'journalctl -xn' for details.
After reach for the service log, it shows that the JBoss EAP startup script has failed to start.
localhost.localdomain systemd1: Failed to start SYSV: JBoss EAP startup script.
systemctl status jboss-eap-rhel.service
jboss-eap-rhel.service - SYSV: JBoss EAP startup script
Loaded: loaded (/etc/rc.d/init.d/jboss-eap-rhel.sh)
Active: failed (Result: resources) since Wed 2017-05-17 05:35:37 EDT; 6min ago
Process: 16673 ExecStart=/etc/rc.d/init.d/jboss-eap-rhel.sh start (code=exited, status=0/SUCCESS)
Main PID: 6979
May 17 05:35:06 localhost.localdomain systemd[1]: Starting SYSV: JBoss EAP startup script...
May 17 05:35:06 localhost.localdomain jboss-eap-rhel.sh[16673]: Starting jboss-eap: chown: missing operand after ‘/var/run/jboss-eap’
May 17 05:35:06 localhost.localdomain jboss-eap-rhel.sh[16673]: Try 'chown --help' for more information.
May 17 05:35:37 localhost.localdomain jboss-eap-rhel.sh[16673]: jboss-eap started with errors, please see server log for details
May 17 05:35:37 localhost.localdomain jboss-eap-rhel.sh[16673]: [ OK ]
May 17 05:35:37 localhost.localdomain systemd[1]: PID file /var/run/jboss-eap/jboss-eap.pid not readable (yet?) after start.
May 17 05:35:37 localhost.localdomain systemd[1]: Failed to start SYSV: JBoss EAP startup script.
May 17 05:35:37 localhost.localdomain systemd[1]: Unit jboss-eap-rhel.service entered failed state.
i checked the jboss conf and the eap-rhel.sh looking for something wrong, including the standalone.xml and the standalone-full.xml, but everything looks to be ok.
the files of the jboss are in /usr/share right now (i have installed and unstalled several times in different folders trying to solve it, yes i have deleted remaining files before each installation).
just to be sure, i mention the steps i done after every installation:
the jboss-eap.conf was succefully edited. the user and the path of the jboss were changed to the right ones.
jboss-eap.conf copied to /etc/default
jboss-eap-rhel copied to /etc/init.d
I also opened it using
./standalone.sh -c standalone-full.xml
it throws this warning:
03:56:23,735 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX00 13: Node identifier property is set to the default value. Please make sure it is unique.
and doesn't work (because the service is still not active).
¿how can I start the service?
03:56:23,735 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 60) WFLYTX0013: Node identifier property is set to the default value. Please make sure it unique.
You dont have to worry about it unless you have enabled JTA. You can set unique value of node identifier in standalone-full.xml file like :
<subsystem xmlns="urn:jboss:domain:transactions:1.4">
<core-environment node-identifier="${jboss.tx.node.id}">
...
Regarding service, please verify steps you have followed http://www.dmartin.es/2014/07/jboss-eap-6-as-rhel-7-service/
If you're using JBoss 7.x, you can use the following CLI commands:
/host=master/server-config=server-one/system-property=jboss.tx.node.id:add(boot-time=true,value=master)
/host={slave-host}/server-config=server-one/system-property=jboss.tx.node.id:add(boot-time=true,value=slave2)
/profile={some-profile}/subsystem=transactions:write-attribute(name=node-identifier,value="${jboss.tx.node.id}")
:reload-servers(blocking=true)
This will add the following lines:
<subsystem xmlns="urn:jboss:domain:transactions:4.0">
<core-environment node-identifier="${jboss.tx.node.id}">
<process-id>
<uuid/>
</process-id>
</core-environment>
<recovery-environment socket-binding="txn-recovery-environment" status-socket-binding="txn-status-manager"/>
<object-store path="tx-object-store" relative-to="jboss.server.data.dir"/>
</subsystem>
In each profile section of the domain.xml configuration file (in domain controller), and:
<servers>
<server name="server-one" group="x-server-group" auto-start="true">
<system-properties>
<property name="jboss.tx.node.id" value="slave1" boot-time="true"/>
</system-properties>
</server>
</servers>
under each server definition in the host-slave.xml configuration file (in host controller).
External references:
https://access.redhat.com/solutions/748323
https://access.redhat.com/solutions/260023
https://issues.jboss.org/browse/JBEAP-11208

Elasticsearch connection error in Ubuntu 16.4

In my ubuntu machine when I run the command curl -X GET 'http://localhost:9200' to test connection it show following message.
curl: (7) Failed to connect to localhost port 9200: Connection refused
When i check server status with sudo systemctl start elasticsearch it show following message.
● elasticsearch.service - Elasticsearch
Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2016-11-20 16:32:30 BDT; 44s ago
Docs: http://www.elastic.co
Process: 8653 ExecStart=/usr/share/elasticsearch/bin/elasticsearch -p ${PID_DIR}/elasticsearch.pid --quiet -Edefault.path.logs=${LOG_DIR} -Edefa
Process: 8649 ExecStartPre=/usr/share/elasticsearch/bin/elasticsearch-systemd-pre-exec (code=exited, status=0/SUCCESS)
Main PID: 8653 (code=exited, status=1/FAILURE)
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,579 main ERROR Null object returned for RollingFile in Appenders.
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,579 main ERROR Null object returned for RollingFile in Appenders.
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,580 main ERROR Unable to locate appender "rolling" for logger config "root"
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,580 main ERROR Unable to locate appender "index_indexing_slowlog_rolling" for logge
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,581 main ERROR Unable to locate appender "index_search_slowlog_rolling" for logger
Nov 20 16:32:29 bahar elasticsearch[8653]: 2016-11-20 16:32:25,581 main ERROR Unable to locate appender "deprecation_rolling" for logger config "o
Nov 20 16:32:29 bahar elasticsearch[8653]: [2016-11-20T16:32:25,592][WARN ][o.e.c.l.LogConfigurator ] ignoring unsupported logging configuration
Nov 20 16:32:30 bahar systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE
Nov 20 16:32:30 bahar systemd[1]: elasticsearch.service: Unit entered failed state.
Nov 20 16:32:30 bahar systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
This is the error for the PATH and LOgs in the elasticsearch.yml (etc/elasticsearch/elasticsearch.yml)
Uncheck these path and your error will be removed.
That means elasticsearch is not running. And from what I see, there is a problem with starting it. Check your elasticsearch configuration.
check if Elasticsearch is running,run the follwing command:
$ ps aux|grep elasticsearch
if Elasticsearch is not started,check your JAVA Environment,download a new Elasticsearch and install it again:
1.check if JAVA is correctly installed:
$ java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
if your JAVA version is lower 1.7,change a new one.
2.download Elasticsearch install package,unzip it:
$ tar -zxvf elasticsearch-2.3.3.gz
3. run Elasticsearch
$ cd elasticsearch-2.3.3
$ ./bin/elasticsearch
Usually it's the write permission issue for the log directory (default as /var/log/elasticsearch), use ls -l to check the permission and change mode to 777 for the log directory and files if necessary.
Long story short: a system reboot might get it OK.
It has been a while since the question is asked. Anyway, I ran into a similar problem recently.
The elasticsearch service on one of my nodes died, with error saying similar to those posted in the question when restart the service. It says the log folder to write is read-only file system. But these files and directories are indeed owned by user elasticsearch (version 5.5, deployed on Cent OS 6.5), there should not be a read-only problem.
I checked and didn't find a clue. So, I just reboot the system. After rebooting, everything goes all right without any further tuning: elasticsearch service starts on boot as configured, it finds the cluster and all the other nodes, and the cluster health status turns green after a little while.
I guess, the root reason might be some hardware failure in my case. All data and logs managed by elasticsearch cluster are stored in a 2TB SSD driver mounted on each node. And our hardware team just managed to recover from an external storage failure recently. All the nodes restarted during that recovery. Chances are there are some lagged issues caused the problem.

CentOS 7 - boot order needs to be changed in order for sge to start automatically

It seems like sge tries start before lustre is mounted when the server boots, which brings an error to start automatically when it reboots.
Can somebody tell me how to change the order when it boots, so sge starts after lustre is mounted?
Error message from the log:
Aug 12 11:46:21 dragen1 systemd: Configuration file /usr/lib/systemd/system/sge_execd.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Aug 12 11:46:40 dragen1 sge_execd: error: SGE_ROOT directory "/cm/shared/apps/sge/2011.11p1" doesn't exist
Aug 12 11:46:40 dragen1 systemd: sge_execd.service: control process exited, code=exited status=1
Aug 12 11:46:40 dragen1 systemd: Unit sge_execd.service entered failed state.
Aug 12 11:46:40 dragen1 systemd: sge_execd.service failed
I added in the following under [Unit] from the sge service
RequiresMountsFor=(Mount Point)
This fixed the problem.

Resources