I am having an issue with running emqx.
When I run emqx start, It shows:
emqx v3.2.7 is started successfully!
When I run emx_ctl status:
Node 'emqx#127.0.0.1' not responding to pings.
When I run emqx console:
MacBook-Pro:bin apple$ emqx console
!!!!
!!!! WARNING: ulimit -n is 256; 1024 is the recommended minimum.
!!!!
Exec: /usr/local/Cellar/emqx/3.2.7/erts-10.3.5/bin/erlexec -boot /usr/local/Cellar/emqx/3.2.7/releases/v3.2.7/emqx -mode embedded -boot_var ERTS_LIB_DIR /usr/local/Cellar/emqx/3.2.7/erts-10.3.5/../lib -mnesia dir "/usr/local/Cellar/emqx/3.2.7/data/mnesia/emqx#127.0.0.1" -config /usr/local/Cellar/emqx/3.2.7/data/configs/app.2019.12.13.02.35.23.config -args_file /usr/local/Cellar/emqx/3.2.7/data/configs/vm.2019.12.13.02.35.23.args -vm_args /usr/local/Cellar/emqx/3.2.7/data/configs/vm.2019.12.13.02.35.23.args -- console
Root: /usr/local/Cellar/emqx/3.2.7
/usr/local/Cellar/emqx/3.2.7
Erlang/OTP 21 [erts-10.3.5] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:32] [hipe] [dtrace]
{"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{{shutdown,{failed_to_start_child,kernel_safe_sup,{on_load_function_failed,crypto}}},{kernel,start,[normal,[]]}}}"}
Kernel pid terminated (application_controller) ({application_start_failure,kernel,{{shutdown,{failed_to_start_child,kernel_safe_sup,{on_load_function_failed,crypto}}},{kernel,start,[normal,[]]}}})
Crash dump is being written to: log/crash.dump...done
Related
I have an AWS Linux 2 AMI EC2 instance.
When running systemctl --user status I get the message:
Failed to get D-Bus connection: No such file or directory
I then ran systemctl start dbus.socket, which gave me this message:
Failed to start dbus.socket: The name org.freedesktop.PolicyKit1 was not provided by any .service files See system logs and 'systemctl status dbus.socket' for details.
I then ran systemctl status dbus.socket -l which returned this:
dbus.socket - D-Bus System Message Bus Socket
Loaded: loaded (/usr/lib/systemd/system/dbus.socket; static; vendor preset: disabled)
Active: active (running) since Thu 2022-03-31 21:26:42 UTC; 14h ago
Listen: /run/dbus/system_bus_socket (Stream)
Mar 31 21:26:42 ip-10-0-0-193.ec2.internal systemd[1]: Listening on D-Bus System Message Bus Socket.
Mar 31 21:26:42 ip-10-0-0-193.ec2.internal systemd[1]: Starting D-Bus System Message Bus Socket.
Running sudo systemctl --user status gives a different error:
Failed to get D-Bus connection: Connection refused
I'm unsure of what to investigate next or what steps to take to resolve the issue.
I have a go web app which is on the path /home/me/go/src/myapp.
When I run the executable using ./myapp on bash terminal, it works fine.
However this requires an open terminal to continue running, which is not practial so I tried to make a systemd daemon on my Debian server's /etc/systemd/system/myapp.service like this:
[Unit]
Description=MyApp Daemon
StartLimitIntervalSec=0
[Service]
Type=simple
User= me
Group=www-data
ExecStart=/home/me/go/src/myapp/myapp
TimeoutStopSec=300
[Install]
WantedBy=multi-user.target
I have enabled and started the daemon:
systemctl enable myapp
Start it:
systemctl start myapp
However it fails to run the daemn, and I get this error:
# systemctl status myapp
● myapp.service - MyApp Daemon
Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2020-07-17 05:42:18 CDT; 4s ago
Process: 19058 ExecStart=/home/me/go/src/myapp/myapp (code=exited, status=127)
Main PID: 19058 (code=exited, status=127)
CPU: 2ms
Jul 17 05:42:18 front systemd[1]: Started Myapp Daemon.
Jul 17 05:42:18 front systemd[1]: myapp.service: Main process exited, code=exited, status=127/n/a
Jul 17 05:42:18 front systemd[1]: myapp.service: Unit entered failed state.
Jul 17 05:42:18 front systemd[1]: myapp.service: Failed with result 'exit-code'.
I'm wondering what could be wrong and how should I fix it?
After lots of trial and error this config worked for me:
[Unit]
Description=Sai Go webapp Daemon
#After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
User= me
Group=www-data
WorkingDirectory=/home/me/go/src/myapp/
ExecStart=/home/me/go/src/myapp/myapp
TimeoutStopSec=300
[Install]
WantedBy=multi-user.target
Apparently WorkingDirectory was necessary.
Attempting to use / startup HDFS NFS following the docs (ignoring the instructions to stop the rpcbind service and did not start the hadoop portmap service given that the OS is not SLES 11 and RHEL 6.2), but running into error when trying to set up the NFS service starting the hdfs nfs3 service:
[root#HW02 ~]#
[root#HW02 ~]#
[root#HW02 ~]# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
[root#HW02 ~]#
[root#HW02 ~]#
[root#HW02 ~]# service nfs status
Redirecting to /bin/systemctl status nfs.service
Unit nfs.service could not be found.
[root#HW02 ~]#
[root#HW02 ~]#
[root#HW02 ~]# service nfs stop
Redirecting to /bin/systemctl stop nfs.service
Failed to stop nfs.service: Unit nfs.service not loaded.
[root#HW02 ~]#
[root#HW02 ~]#
[root#HW02 ~]# service rpcbind status
Redirecting to /bin/systemctl status rpcbind.service
● rpcbind.service - RPC bind service
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-07-23 13:48:54 HST; 28s ago
Process: 27337 ExecStart=/sbin/rpcbind -w $RPCBIND_ARGS (code=exited, status=0/SUCCESS)
Main PID: 27338 (rpcbind)
CGroup: /system.slice/rpcbind.service
└─27338 /sbin/rpcbind -w
Jul 23 13:48:54 HW02.ucera.local systemd[1]: Starting RPC bind service...
Jul 23 13:48:54 HW02.ucera.local systemd[1]: Started RPC bind service.
[root#HW02 ~]#
[root#HW02 ~]#
[root#HW02 ~]# hdfs nfs3
19/07/23 13:49:33 INFO nfs3.Nfs3Base: STARTUP_MSG:
/************************************************************
STARTUP_MSG: Starting Nfs3
STARTUP_MSG: host = HW02.ucera.local/172.18.4.47
STARTUP_MSG: args = []
STARTUP_MSG: version = 3.1.1.3.1.0.0-78
STARTUP_MSG: classpath = /usr/hdp/3.1.0.0-78/hadoop/conf:/usr/hdp/3.1.0.0-78/hadoop/lib/jersey-server-1.19.jar:/usr/hdp/3.1.0.0-78/hadoop/lib/ranger-hdfs-plugin-shim-1.2.0.3.1.0.0-78.jar:
...
<a bunch of other jars>
...
STARTUP_MSG: build = git#github.com:hortonworks/hadoop.git -r e4f82af51faec922b4804d0232a637422ec29e64; compiled by 'jenkins' on 2018-12-06T12:26Z
STARTUP_MSG: java = 1.8.0_112
************************************************************/
19/07/23 13:49:33 INFO nfs3.Nfs3Base: registered UNIX signal handlers for [TERM, HUP, INT]
19/07/23 13:49:33 INFO impl.MetricsConfig: Loaded properties from hadoop-metrics2.properties
19/07/23 13:49:33 INFO impl.MetricsSystemImpl: Scheduled Metric snapshot period at 10 second(s).
19/07/23 13:49:33 INFO impl.MetricsSystemImpl: Nfs3 metrics system started
19/07/23 13:49:33 INFO oncrpc.RpcProgram: Will accept client connections from unprivileged ports
19/07/23 13:49:33 INFO security.ShellBasedIdMapping: Not doing static UID/GID mapping because '/etc/nfs.map' does not exist.
19/07/23 13:49:33 INFO nfs3.WriteManager: Stream timeout is 600000ms.
19/07/23 13:49:33 INFO nfs3.WriteManager: Maximum open streams is 256
19/07/23 13:49:33 INFO nfs3.OpenFileCtxCache: Maximum open streams is 256
19/07/23 13:49:34 INFO nfs3.DFSClientCache: Added export: / FileSystem URI: / with namenodeId: -1408097406
19/07/23 13:49:34 INFO nfs3.RpcProgramNfs3: Configured HDFS superuser is
19/07/23 13:49:34 INFO nfs3.RpcProgramNfs3: Delete current dump directory /tmp/.hdfs-nfs
19/07/23 13:49:34 INFO nfs3.RpcProgramNfs3: Create new dump directory /tmp/.hdfs-nfs
19/07/23 13:49:34 INFO nfs3.Nfs3Base: NFS server port set to: 2049
19/07/23 13:49:34 INFO oncrpc.RpcProgram: Will accept client connections from unprivileged ports
19/07/23 13:49:34 INFO mount.RpcProgramMountd: FS:hdfs adding export Path:/ with URI: hdfs://hw01.ucera.local:8020/
19/07/23 13:49:34 INFO oncrpc.SimpleUdpServer: Started listening to UDP requests at port 4242 for Rpc program: mountd at localhost:4242 with workerCount 1
19/07/23 13:49:34 ERROR mount.MountdBase: Failed to start the TCP server.
org.jboss.netty.channel.ChannelException: Failed to bind to: 0.0.0.0/0.0.0.0:4242
at org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:272)
at org.apache.hadoop.oncrpc.SimpleTcpServer.run(SimpleTcpServer.java:89)
at org.apache.hadoop.mount.MountdBase.startTCPServer(MountdBase.java:83)
at org.apache.hadoop.mount.MountdBase.start(MountdBase.java:98)
at org.apache.hadoop.hdfs.nfs.nfs3.Nfs3.startServiceInternal(Nfs3.java:56)
at org.apache.hadoop.hdfs.nfs.nfs3.Nfs3.startService(Nfs3.java:69)
at org.apache.hadoop.hdfs.nfs.nfs3.Nfs3.main(Nfs3.java:79)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
...
...
19/07/23 13:49:34 INFO util.ExitUtil: Exiting with status 1: org.jboss.netty.channel.ChannelException: Failed to bind to: 0.0.0.0/0.0.0.0:4242
19/07/23 13:49:34 INFO nfs3.Nfs3Base: SHUTDOWN_MSG:
/************************************************************
SHUTDOWN_MSG: Shutting down Nfs3 at HW02.ucera.local/172.18.4.47
************************************************************/
Not sure how to interpret any of the errors seen here (and have not installed any packages like nfs-utils, assuming that Ambari would have installed all needed packages when cluster was initially installed).
Any debugging suggestions or solutions for what to do about this?
** UPDATE:
After looking at the error, I can see
Caused by: java.net.BindException: Address already in use
and looking into what is already using it, we see...
[root#HW02 ~]# netstat -ltnp | grep 4242
tcp 0 0 0.0.0.0:4242 0.0.0.0:* LISTEN 98067/jsvc.exec
The process jsvc.exec appears to be related to running java applications. Given that hadoop runs on java, I assume it would be bad to just kill the process. Is it not supposed to be on this port (since interferes with NFS Gateway)? Not sure what to do about this.
TLDR: nfs gateway service was already running (by default, apparently) and the service that I thought was blocking the hadoop nfs3 service (jsvc.exec) from starting was (I'm assuming) part of that service already running.
What made me suspect this was that when shutting down the cluster, the service also stopped plus the fact that it was using the port I needed for nfs. The way that I confirmed this was just from following the verification steps in the docs and seeing that my output was similar to what should be expected.
[root#HW02 ~]# rpcinfo -p hw02
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 4242 mountd
100005 2 udp 4242 mountd
100005 3 udp 4242 mountd
100005 1 tcp 4242 mountd
100005 2 tcp 4242 mountd
100005 3 tcp 4242 mountd
100003 3 tcp 2049 nfs
[root#HW02 ~]# showmount -e hw02
Export list for hw02:
/ *
Another thing that could told me that the jsvc process was part of an already running hdfs nfs service would have been checking the process info...
[root#HW02 ~]# ps -feww | grep jsvc
root 61106 59083 0 14:27 pts/2 00:00:00 grep --color=auto jsvc
root 163179 1 0 12:14 ? 00:00:00 jsvc.exec -Dproc_nfs3 -outfile /var/log/hadoop/root/hadoop-hdfs-root-nfs3-HW02.ucera.local.out -errfile /var/log/hadoop/root/privileged-root-nfs3-HW02.ucera.local.err -pidfile /var/run/hadoop/root/hadoop-hdfs-root-nfs3.pid -nodetach -user hdfs -cp /usr/hdp/3.1.0.0-78/hadoop/conf:...
...
hdfs 163193 163179 0 12:14 ? 00:00:17 jsvc.exec -Dproc_nfs3 -outfile /var/log/hadoop/root/hadoop-hdfs-root-nfs3-HW02.ucera.local.out -errfile /var/log/hadoop/root/privileged-root-nfs3-HW02.ucera.local.err -pidfile /var/run/hadoop/root/hadoop-hdfs-root-nfs3.pid -nodetach -user hdfs -cp /usr/hdp/3.1.0.0-78/hadoop/conf:...
and seeing jsvc.exec -Dproc_nfs3 ... to get the hint that jsvc (which apparently is for running java apps on linux) was being used to run the very nfs3 service I was trying to start.
And for anyone else with this problem, note that I did not stop all the services that the docs want you to stop (since using centos7)
[root#HW01 /]# service nfs status
Redirecting to /bin/systemctl status nfs.service
● nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; disabled; vendor preset: disabled)
Active: inactive (dead)
[root#HW01 /]# service rpcbind status
Redirecting to /bin/systemctl status rpcbind.service
● rpcbind.service - RPC bind service
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2019-07-19 15:17:02 HST; 6 days ago
Main PID: 2155 (rpcbind)
CGroup: /system.slice/rpcbind.service
└─2155 /sbin/rpcbind -w
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
Also note that I did not follow any of the config file settings recommended in the docs (and that some of the properties instructed in the docs could not even be found in the Ambari-managed HDFS configs (so if anyone can explain why this is still working for me despite that, please do)).
** Update:
After talking with some people more experienced with using HDP (v3.1) than me, the docs that I linked to for setting up NFS for HDFS may not be totally up to date (when setting up NFS via Ambari mgnt. in any case)...
Can have a cluster node act as an NFS gateway by checking it off as a NFS node in the Ambari host management UI:
Needed configs can be set like so in the HDFS mgnt. UI...
Can confirm that HDFS NFS gateway is running by looking at the Host > Summary > Components section in Ambari...
I am trying Docker on CoreOS on EC2.
What I want to do is:
Run Docker private registry container
Run other containers after pulling image from private registry
Initial Configuration
My cloud-config.yml is like this:
#cloud-config
coreos:
units:
- name: etcd2.service
command: start
- name: fleet.service
command: start
- name: docker.service
command: start
drop-ins:
- name: 50-insecure-registry.conf
content: |
[Service]
Environment=DOCKER_OPTS='--insecure-registry="localhost:5000"'
- name: private-docker-registry.service
command: start
runtime: true
content: |
[Unit]
Description=Docker Private Registry
After=docker.service
Requires=docker.service
Requires=network-online.target
After=network-online.target
[Service]
ExecStartPre=/usr/bin/docker pull registry:latest
ExecStart=/usr/bin/docker run --name private-docker-registry --privileged -e SETTINGS_FLAVOR=s3 -e AWS_BUCKET=bucket -e AWS_KEY=awskey -e AWS_SECRET=awssecret -e SEARCH_BACKEND=sqlalchemy -p 5000:5000 registry:latest
- name: myservice.service
command: start
runtime: true
content: |
[Unit]
Description=My Service
After=private-docker-registry.service
Requires=private-docker-registry.service
Requires=network-online.target
After=network-online.target
[Service]
ExecStartPre=/usr/bin/docker pull localhost:5000/myservice:latest
ExecStart=/usr/bin/docker run --name myservice localhost:5000/myservice:latest
myservice.service fails
Problem here is:
myservice.service fails though private registry container is successfully running
As I login to the machine, it shows following message.
Failed Units: 1
myservice.service
Command journalctl -u private-docker-registry.service shows this:
Jul 24 07:30:25 docker[830]: [2015-07-24 07:30:25 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000 (1)
Command journalctl -u myservice.service shows following log.
Jul 24 07:30:25 systemd[1]: Starting My Service...
Jul 24 07:30:25 docker[836]: time="2015-07-24T07:30:25Z" level=fatal msg="Error response from daemon: v1 ping attempt failed with error: Get http://localhost:5000/v1/_ping: dial tcp 127.0.0.1:5000: connection refused"
Jul 24 07:30:25 systemd[1]: myservice.service: Control process exited, code=exited status=1
Jul 24 07:30:25 systemd[1]: Failed to start My Service.
Jul 24 07:30:25 systemd[1]: myservice.service: Unit entered failed state.
Jul 24 07:30:25 systemd[1]: myservice.service: Failed with result 'exit-code'.
However, I can run myservice container manually (after few minutes).
docker run --name myservice localhost:5000/myservice:latest
My assumption is:
Pulling myservice image fails because myservice.service tries to pull myservice image immediately after private registry starts listening.
Try & Error
Based on my assumption above, I added wait-for-registry.service which just wait 2 minutes after private registry starts.
#cloud-config
coreos:
units:
- name: etcd2.service
command: start
- name: fleet.service
command: start
- name: docker.service
command: start
drop-ins:
- name: 50-insecure-registry.conf
content: |
[Service]
Environment=DOCKER_OPTS='--insecure-registry="localhost:5000"'
- name: private-docker-registry.service
command: start
runtime: true
content: |
[Unit]
Description=Docker Private Registry
After=docker.service
Requires=docker.service
Requires=network-online.target
After=network-online.target
[Service]
ExecStartPre=/usr/bin/docker pull registry:latest
ExecStart=/usr/bin/docker run --name private-docker-registry --privileged -e SETTINGS_FLAVOR=s3 -e AWS_BUCKET=bucket -e AWS_KEY=awskey -e AWS_SECRET=awssecret -e SEARCH_BACKEND=sqlalchemy -p 5000:5000 registry:latest
- name: wait-for-registry.service
command: start
runtime: true
content: |
[Unit]
Description=Wait Until Private Registry is Ready
After=private-docker-registry.service
Requires=private-docker-registry.service
[Service]
ExecStart=/usr/bin/sleep 120
- name: myservice.service
command: start
runtime: true
content: |
[Unit]
Description=My Service
After=wait-for-registry.service
After=private-docker-registry.service
Requires=private-docker-registry.service
Requires=network-online.target
After=network-online.target
[Service]
ExecStartPre=/usr/bin/docker pull localhost:5000/myservice:latest
ExecStart=/usr/bin/docker run --name myservice localhost:5000/myservice:latest
But this causes same problem.
Command journalctl -u private-docker-registry.service shows this:
Jul 24 08:23:38 docker[838]: [2015-07-24 08:23:38 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000 (1)
Command journalctl -u wait-for-registry.service shows this:
Jul 24 08:23:37 systemd[1]: Started Wait Until Private Registry is Ready.
Jul 24 08:23:37 systemd[1]: Starting Wait Until Private Registry is Ready...
Command journalctl -u myservice.service shows this:
Jul 24 08:23:37 systemd[1]: Starting My Service...
Jul 24 08:23:37 docker[847]: time="2015-07-24T08:23:37Z" level=fatal msg="Error response from daemon: v1 ping attempt failed with error: Get http://localhost:5000/v1/_ping: dial tcp 127.0.0.1
Jul 24 08:23:37 systemd[1]: myservice.service: Control process exited, code=exited status=1
Jul 24 08:23:37 systemd[1]: Failed to start My Service.
Jul 24 08:23:37 systemd[1]: myservice.service: Unit entered failed state.
Jul 24 08:23:37 systemd[1]: myservice.service: Failed with result 'exit-code'.
It seems that sleep takes no effect.
Question
How can I make it wait until private registry will be available?
Any hints or suggestions welcome!
Thank you:)
systemd unit files are tricky :-)
I think you just about have it. I am no expert, but, I will try to explain what I think is happening.
First, I think you might want to add a :
- name: wait-for-registry.service
command: start
runtime: true
content: |
[Unit]
Description=Wait Until Private Registry is Ready
After=private-docker-registry.service
Requires=private-docker-registry.service
[Service]
ExecStart=/usr/bin/sleep 120
RemainAfterExit=true
Type=oneshot
The explaination would be that /usr/bin/sleep 120 is started. Since it is started, the next Unit in the chain is started (your myservice.service). By changing it to a oneshot you have to wait until it is finished. I am guessing here, though, because much of the unit stuff is trial and error for me.
I do have a similar construct in my unit files. I don't think you really want 'sleep', that is a hack. I think you really want to wait until port 5000 is answering, right? If that is the case, you can replace the sleep with:
ExecStart=/usr/bin/bash /opt/bin/waiter.sh
Then, towards the top of the cloud-config:
write_files:
- path: /opt/bin/waiter.sh
permissions: 0755
owner: root
content: |
#! /usr/bin/bash
until curl -s http://127.0.0.1:5000/; do echo waiting waiter.sh; sleep 2; done
Or something similar. Wait until there is something at that port before continuing.
-g
I am building a tomcat container in Docker with supervisord. If the default command in the Dockerfile is
CMD supervisord -c /etc/supervisord.conf
and when i dispatch docker stop command, the container exits successfully with the exit code 0.
But instead if i have
CMD ["/run"]
and in run.sh,
supervisord -c /etc/supervisord.conf
The docker stop command gives me a exit code -1. On viewing the logs, it seems that the supervisord did not receive the SIGTERM indicating the exit request.
2014-10-06 19:48:54,420 CRIT Supervisor running as root (no user in config file)
2014-10-06 19:48:54,450 INFO RPC interface 'supervisor' initialized
2014-10-06 19:48:54,451 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2014-10-06 19:48:54,451 INFO supervisord started with pid 6
2014-10-06 19:48:55,457 INFO spawned: 'tomcat' with pid 9
2014-10-06 19:48:56,503 INFO success: tomcat entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
as opposed to the previous logs where it receives a sigterm and gracefully exits.
2014-10-06 20:02:59,527 CRIT Supervisor running as root (no user in config file)
2014-10-06 20:02:59,556 INFO RPC interface 'supervisor' initialized
2014-10-06 20:02:59,556 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2014-10-06 20:02:59,557 INFO supervisord started with pid 1
2014-10-06 20:03:00,561 INFO spawned: 'tomcat' with pid 9
2014-10-06 20:03:01,602 INFO success: tomcat entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2014-10-06 20:05:11,690 WARN received SIGTERM indicating exit request
2014-10-06 20:05:11,690 INFO waiting for tomcat to die
2014-10-06 20:05:12,450 INFO stopped: tomcat (exit status 143)
Any help appreciated.
Thanks,
Karthik
UPDATE:
supervisord.conf file
[supervisord]
nodaemon=true
logfile=/var/log/supervisor/supervisord.log
[program:mysql]
command=/usr/bin/pidproxy /var/run/mysqld/mysqld.pid /usr/bin/mysqld_safe --pid-file=/var/run/mysqld/mysqld.pid
stdout_logfile=/tmp/mysql.log
stderr_logfile=/tmp/mysql_err.log
[supervisorctl]
serverurl=unix:///tmp/supervisor.sock
[unix_http_server]
file=/tmp/supervisor.sock ; path to your socket file
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface
When you run the process via run.sh, signals are only sent to that process. Unless you are
going out of your way to send signals to child processes, e.g. with trap
sending signals to the process group.
doing exec supervisord ... in run.sh
the child process won't get the signals.