I was editing /etc/crontab when things turned south. I have no idea why, and I rolled back my changes on the /etc/crontab file but apache is still messed up and I can't access local development websites hosted on this machine. When I run systemctl status apache2.service this is what I get:
apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2020-10-04 11:27:33 MDT; 6min ago
Docs: https://httpd.apache.org/docs/2.4/
Process: 2413 ExecStart=/usr/sbin/apachectl start (code=exited, status=203/EXEC)
Oct 04 11:27:33 pidev.local systemd[1]: Starting The Apache HTTP Server...
Oct 04 11:27:33 pidev.local systemd[2413]: apache2.service: Failed to execute command: No such file or directory
Oct 04 11:27:33 pidev.local systemd[2413]: apache2.service: Failed at step EXEC spawning /usr/sbin/apachectl: No such file or directory
Oct 04 11:27:33 pidev.local systemd[1]: apache2.service: Control process exited, code=exited, status=203/EXEC
Oct 04 11:27:33 pidev.local systemd[1]: apache2.service: Failed with result 'exit-code'.
Oct 04 11:27:33 pidev.local systemd[1]: Failed to start The Apache HTTP Server.
Any ideas? I can't seem to trace what's wrong here.
I have Debian 10 virtual machine.
And I want to be able to connect to the docker API from another host.
I can connect to docker from other host if I start docker deamon from console
dockerd -H unix:///var/run/docker.sock -H tcp://192.168.3.157
If I try to configure /etc/docker/daemon.json like
{
"hosts": ["unix:///var/run/docker.sock", "tcp://192.168.3.157"]
}
The command systemctl start docker fails. The command systemctl status docker have next output
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2019-11-02 11:32:26 MSK; 1min 10s ago
Docs: https://docs.docker.com
Process: 868 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE)
Main PID: 868 (code=exited, status=1/FAILURE)
Nov 02 11:32:24 debian-for-docker systemd[1]: Failed to start Docker Application Container Engine.
Nov 02 11:32:26 debian-for-docker systemd[1]: docker.service: Service RestartSec=2s expired, scheduling restart.
Nov 02 11:32:26 debian-for-docker systemd[1]: docker.service: Scheduled restart job, restart counter is at 3.
Nov 02 11:32:26 debian-for-docker systemd[1]: Stopped Docker Application Container Engine.
Nov 02 11:32:26 debian-for-docker systemd[1]: docker.service: Start request repeated too quickly.
Nov 02 11:32:26 debian-for-docker systemd[1]: docker.service: Failed with result 'exit-code'.
Nov 02 11:32:26 debian-for-docker systemd[1]: Failed to start Docker Application Container Engine.
Nov 02 11:32:53 debian-for-docker systemd[1]: docker.service: Start request repeated too quickly.
Nov 02 11:32:53 debian-for-docker systemd[1]: docker.service: Failed with result 'exit-code'.
Nov 02 11:32:53 debian-for-docker systemd[1]: Failed to start Docker Application Container Engine.
How should I configure the /etc/docker/daemon.json to make my deamon start properly?
I have found the answer.
It's here Unable to start docker after configuring hosts in daemon.json
I have created the file /etc/systemd/system/docker.service.d/override.conf with content
# Disable flags to dockerd, all settings are done in /etc/docker/daemon.json
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd
And then I restarted the service systemctl daemon-reload; systemctl restart docker
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
I installed the Elastic Search by downloading the .deb package from this link.
After installing I tried to browse to http://localhost:9200/ where I'm getting connection refused error, so I checked the status of elastic search service by running the following command sudo service elasticsearch status and I'm getting the below logs :
● elasticsearch.service - Elasticsearch
Loaded: loaded (/usr/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2017-08-04 18:15:59 IST; 3s ago
Docs: http://www.elastic.co
Process: 23168 ExecStart=/usr/share/elasticsearch/bin/elasticsearch -p ${PID_DIR}/elasticsearch.pid --
Process: 23163 ExecStartPre=/usr/share/elasticsearch/bin/elasticsearch-systemd-pre-exec (code=exited,
Main PID: 23168 (code=exited, status=1/FAILURE)
Aug 04 18:15:59 mrrobot-Inspiron-N5110 systemd[1]: Starting Elasticsearch...
Aug 04 18:15:59 mrrobot-Inspiron-N5110 systemd[1]: Started Elasticsearch.
Aug 04 18:15:59 mrrobot-Inspiron-N5110 systemd[1]: elasticsearch.service: Main process exited, code=exit
Aug 04 18:15:59 mrrobot-Inspiron-N5110 systemd[1]: elasticsearch.service: Unit entered failed state.
Aug 04 18:15:59 mrrobot-Inspiron-N5110 systemd[1]: elasticsearch.service: Failed with result 'exit-code'
lines 1-13/13 (END)
Can some one tell me how to start the service?
I finished to install Openstack Magnum service on CentOS 7, using this guide: http://docs.openstack.org/developer/magnum/install-guide-from-source.html
Checking the magnum-api and magnum-conductor services after reboot shows that the services are active, but few seconds later they are in failed state. The selinux is disabled, and the services are enabled.
Restarting the magnum api service:
[root#controller01 magnum]# systemctl restart magnum-api
magnum-api status OK:
[root#controller01 magnum]# systemctl status magnum-api
● magnum-api.service - OpenStack Magnum API Service
Loaded: loaded (/etc/systemd/system/magnum-api.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2016-11-08 09:50:01 IST; 1s ago
Main PID: 21705 (magnum-api)
CGroup: /system.slice/magnum-api.service
└─21705 /var/lib/magnum/env/bin/python /var/lib/magnum/env/bin/magnum-api
Nov 08 09:50:01 controller01 systemd[1]: Started OpenStack Magnum API Service.
Nov 08 09:50:01 controller01 systemd[1]: Starting OpenStack Magnum API Service...
magnum-api service is failed after few seconds:
[root#controller01 magnum]# systemctl status magnum-api
● magnum-api.service - OpenStack Magnum API Service
Loaded: loaded (/etc/systemd/system/magnum-api.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit) since Tue 2016-11-08 09:50:03 IST; 6s ago
Process: 21705 ExecStart=/var/lib/magnum/env/bin/magnum-api (code=exited, status=1/FAILURE)
Main PID: 21705 (code=exited, status=1/FAILURE)
Nov 08 09:50:02 controller01 systemd[1]: magnum-api.service: main process exited, code=exited, status=1/FAILURE
Nov 08 09:50:02 controller01 systemd[1]: Unit magnum-api.service entered failed state.
Nov 08 09:50:02 controller01 systemd[1]: magnum-api.service failed.
Nov 08 09:50:03 controller01 systemd[1]: magnum-api.service holdoff time over, scheduling restart.
Nov 08 09:50:03 controller01 systemd[1]: start request repeated too quickly for magnum-api.service
Nov 08 09:50:03 controller01 systemd[1]: Failed to start OpenStack Magnum API Service.
Nov 08 09:50:03 controller01 systemd[1]: Unit magnum-api.service entered failed state.
Nov 08 09:50:03 controller01 systemd[1]: magnum-api.service failed.
Happens the same for the magnum-conductor service.
How can I fix this?
Thanks,
Dedi
Thanks #Petesh. I just figure it out. The issue was because I set in the magnum.conf file:
host = controller.
Once I replaced the "controller" with the ip, it works. In other words, set:
host = <controller_IP>.