詳細検索

Responding to failures that do not stop while stopping in AWS maintenance

Avatar
by komi

Responding to failures that do not stop while stopping in AWS maintenance
Translated from 日本語 • View original

Hello. This is Komiya.

As the title suggests, there is a disability, and I would like to record it for the future.

When I stopped the instance where the AWS maintenance notification came, it ended up being stopped for just over 6 hours.
This instance was not built by myself, and the construction notes remain but are not maintained.
It was a pattern that was difficult to grasp the situation.
I stopped after refraining from uploading the process and port, but I didn't take a snapshot and didn't make an AMI.

When I posted it on the Japanese forum, there was no response.
According to what I heard, if you use an English forum, you can get a response in about 15 minutes.

In the meantime, I took a snapshot of the stopping instance, created an AMI, and started a new instance from it.
I couldn't connect due to a problem with the NIC configuration or something.
I started the micro instance, put only Apache in it, and set up a simple sorry page.

I waited for about 6 hours with stopping, but there was no progress at all.
Moreover, I was not subscribed to support, so I applied for support and made the following inquiries.
(When I applied, it was reflected in about 10 minutes).
--------------------------------- 1st time:
I stopped the server from the EC2 Management Console, but it doesn't go from Stopping.
http://aws.amazon.com/jp/instance-help/
I tried to force stop several times, but I would like to ask for a forced stop because it is the same.

Zone: ap-northeast-1a
Instance: i-4a42a348

Instance ID: i-4a42a348
--------------------------------- 2nd time:

I stopped earlier. Did you respond to anything?
I want to start the same instance, but it stops even after starting twice.
If possible, can you start it?
--------------------------------- Since I was short on time, it seems that after I got home, I was able to connect to it by creating an AMI with the CreateImage that I could choose after it was stopped, and starting a new instance.

The next morning, I received a reply from support.
--------------------------------- From support:
Thank you very much for your inquiry.

When I looked up the i-4a42a348, it took a long time to stop the instance because there was a problem with the virtual server host.
EC2 has a system that automatically cleans up instances that have been in a state of stopping or shuttingdown for a long time.
This time, the instance was stopped by this mechanism.
We apologize for any inconvenience this may cause.

Regarding the instance not being able to start, it seems that there is a problem with the association between the instance and the EBS volume, and the instance is not starting as a result.
We apologize for the inconvenience, but could you detach/attach the volume attached to the instance and try to start the instance again?
If normal detach doesn't work, try Force Detach.

If the instance does not start after detaching/attaching a volume, we apologize for the inconvenience, but could you please contact us again?

Please let us know if you have any questions.
Thank you.
---------------------------------

So I did the following work.

First of all, refrain from mounting points
Attachment:
i-4a42a348 (devlab):/dev/sda1 (attached)

Select the instance and run force detach, attach it to the same mount point again, and
I tried to start the instance and it started.

I couldn't cross the security group's default because it wasn't included, so I put it in.
So, I was able to cross it with SSH. That's all for AWS.

When I entered, the port that went up seemed to be different from before, so I corrected it.

[shell]# netstat -lnpt Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1275/ mysqld tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1374/httpd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 901/sshd tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1356/php-fpm[/shell]
Compared to what I had saved in advance, NGINX must be up, not Apache.
Also, node and mongod are not up.

[shell]# chkconfig --list|grep 3:on abrt-ccpp 0:off 1:off 2:off 3:on 4:off 5:on 6:off abrt-oops 0:off 1:off 2:off 3:on 4:off 5:on 6:off abrtd 0:off 1:off 2:off 3:on 4: off 5:on 6:off atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off getsshkey 0:off 1:off 2:off 3:on 4:on 5: off 6:off haldaemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off irqbalance 0:off 1:off 2:off 3:on 4:on 5:on 6: off kdump 0:off 1:off 2:off 3:on 4:on 5:on 6:off libvirt-guests 0:off 1:off 2:on 3:on 4:on 5:on 6:off messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off mongod 0: off 1:off 2:on 3:on 4:on 5:on 6:off mysqld 0:off 1:off 2:on 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off nginx 0:off 1: off 2:on 3:on 4:on 5:on 6:off php-fpm 0:off 1:off 2:on 3:on 4:on 5:on 6:off postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off rsyslog 0:off 1:off 2: on 3:on 4:on 5:on 6:off sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off sysstat 0:off 1:on 2:on 3:on 4:on 5:on 6:off udev-post 0:off 1:on 2:on 3: on 4:on 5:on 6:off

# service nginx start nginx: Setting option from ("on") Setting option from ("RewriteLevel", "CoreFilters") Setting option from ("FileCachePath", "/var/cache/ngx_pagespeed") Setting option from ("EnableFilters", "collapse_whitespace,add_instrumentation,remove_comments") nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [ emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx: [emerg] still could not bind() [0905/105718:INFO:google_message_handler.cc(33 )] Shutting down ngx_pagespeed root [Failure][/shell]
Apache started first and the port I was using was NGINX and did not start.

[shell]# chkconfig httpd off # service httpd stop httpd: [ OK ] # service nginx start nginx: Setting option from ("on") Setting option from ("RewriteLevel", "CoreFilters") option from ("FileCachePath", "/var/cache/ngx_pagespeed") Setting option from ("EnableFilters", "collapse_whitespace,add_instrumentation,remove_comments") [ OK ] # netstat - lnpt Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1275/mysqld tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1570/nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1570/nginx tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 901/sshd tcp 0 0 0.0.0.0:10080 0.0.0.0:* LISTEN 1570/nginx tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1356/php-fpm

# chkconfig --list|grep 3:on abrt-ccpp 0:off 1:off 2:off 3:on 4:off 5:on 6:off abrt-oops 0:off 1:off 2:off 3:on 4:off 5:on 6:off abrtd 0:off 1:off 2:off 3:on 4:off 5: on 6:off atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off getsshkey 0:off 1:off 2:off 3:on 4:on 5:off 6: off haldaemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off irqbalance 0:off 1:off 2:off 3:on 4:on 5:on 6:off kdump 0:off 1:off 2:off 3:on 4:on 5:on 6:off libvirt-guests 0: off 1:off 2:on 3:on 4:on 5:on 6:off messagebus 0:off 1:off 2:on 3:on 4:on 5:on 6:off mongod 0:off 1:off 2:on 3:on 4:on 5:on 6:off mysqld 0:off 1: off 2:on 3:on 4:on 5:on 6:off network 0:off 1:off 2:on 3:on 4:on 5:on 6:off nginx 0:off 1:off 2:on 3:on 4:on 5:on 6:off php-fpm 0:off 1:off 2: on 3:on 4:on 5:on 6:off postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off sshd 0:off 1:off 2:on 3: on 4:on 5:on 6:off sysstat 0:off 1:on 2:on 3:on 4:on 5:on 6:off udev-post 0:off 1:on 2:on 3:on 4:on 5:on 6:off[/shell]
nginx was started and the launch script was adjusted.

It seems that the process of forever has not improved.
It seems that you have perpetuated the process of node.js in forever, but I looked at the history because I couldn't find any particular procedure.

[shell]# forever list info: No forever processes running

# grep forever /root/.bash_history npm install -g forever npm install -g forever forever start app.js forever --minUptime 1000ms --spinSleepTime 1000ms start app.js forever stop app.js forever --minUptime 1000ms --spinSleepTime 1000ms start app.js forever list forever list forever stop forever list forever config forever stopall forever list forever start app & forever start app.js & forever stop forever stop app.js forever start app.js & forever stop app.js forever start app.js & forever app & forever app.js forever start app.js forever list which forever forever list\ [/shell]
I didn't know where the app.js was, so I looked for it.
When I looked at the cd command before starting with forever, I moved to a place called g**** (probably the product name).

[shell]# find / -name "g****" /usr/local/lib/src/g**** # ls /usr/local/lib/src/g**** app.js index.html package.json routes web.config iisnode.yml node_modules public views[/shell]
I'll start it because it looks like this.
[shell]# cd /usr/local/lib/src/g**** # forever --minUptime 1000ms --spinSleepTime 1000ms start app.js info: Forever processing file: app.js # forever list info: Forever processes running data: uid command script forever pid logfile uptime data: [0] WlVc /usr/local/bin/node app.js 3717 3719 /root/.forever/WlVc.log 0:0:0:23.169

# netstat -lnpt Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1234/mysqld tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3619/nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3619/nginx tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 860/sshd tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 3719/node tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1361/master tcp 0 0 0.0.0.0:10080 0.0.0.0:* LISTEN 3619/nginx tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1415/php-fpm[/shell]

node.

Next up is mongod.

[shell]# service mongod start mongod: bash: /var/log/mongodb/mongodb.log: no permissions [ OK ] # netstat -lnpt Active Internet connections (only servers) proto recv-q send-q local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1275/mysqld tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1570/nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1570/ nginx tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 901/sshd tcp 0 0 0.0.0.0:10080 0.0.0.0:* LISTEN 1570/nginx tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1356/php-fpm # ls -lh /var/log/mongodb/ mongodb.log -rw-r--r-- 1 root root 0 May 5, 2013 03:40 2013 /var/log/mongodb/mongodb.log # ls -lh /var/log/mongodb total 176K -rw-r--r-- 1 root root 0 May 5 03:40, 2013 mongodb.log -rw-r--r-- 1 mongodb mongodb 485 April 7 03:08, 2013 mongodb.log-20130331.gz -rw-r--r-- 1 mongodb mongodb 90 Apr 14 03:07, 2013 mongodb.log-20130407.gz -rw-r--r-- 1 mongodb mongodb 1.6K April 21 03:18, 2013 mongodb.log-20130414.gz -rw-r--r-- 1 mongodb mongodb 327 April 28 03:46, 2013 mongodb.log-20130421.gz -rw-r--r-- 1 mongodb mongodb 24K 5 May 2013 03:40 mongodb.log-20130428.gz -rw-r--r-- 1 root root 1.4K May 5 03:40 2013 mongodb.log-20130505 -rw-r--r-- 1 mongodb mongodb 0 March 31 03:10 2013 mongodb.log.2013-03-30T18-10-01 -rw-r--r-- 1 mongodb mongodb 0 Apr 7 03:08 2013 mongodb.log.2013-04-06T18-08-01 -rw-r--r-- 1 mongodb mongodb 0 Apr 14 03:07 2013 mongodb.log.2013-04-13T18-07-01 -rw-r--r-- 1 mongodb mongodb 0 Apr 21 03:18 2013 mongodb.log.2013-04-20T18-18-01 -rw-r--r-- 1 mongodb mongodb 0 Apr 28 03:46 2013 mongodb.log.2013-04-27T18-46-01 -rw-r--r-- 1 mongodb mongodb 38K May 2 10:10, 2013 mongodb.log.2013-05-02T01-10-07 -rw-r--r-- 1 mongodb mongodb 2.4K 2 May 2013 10:10 2013 mongodb.log.2013-05-02T01-10-54 -rw-r--r-- 1 mongodb mongodb 15K 14:48, 2 May 2013 mongodb.log.2013-05-02T05-48-24 -rw-r--r-- 1 mongodb mongodb 64K 18:04, 17 July 2013 mongodb.log.2013-05-02T05-53-38[/shell]

It seems that it is not uploaded because the log cannot be written in terms of permission.

[shell]# chown -R mongodb. /var/log/mongodb # service mongod start mongod: [ OK ] # netstat -lnpt Active Internet connections (only servers) Proto recv-q send-q local address foreign address state PID/program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1275/mysqld tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1570/nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1570/nginx tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 901/ sshd tcp 0 0 0.0.0.0:10080 0.0.0.0:* LISTEN 1570/nginx tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1356/php-fpm[/shell]

I fixed the log permissions, but it doesn't start. The logs are now coming out.

[shell]Thu Sep 5 11:07:06 [initandlisten] options: { bind_ip: "127.0.0.1", command: [ "run" ], config: "/etc/mongodb.conf", dbpath: "/var/lib/mongodb", fork: "true", logpath: "/ var/log/mongodb/mongodb.log", nohttpinterface: "true", nojournal: "true", pidfilepath: "/var/run/mongodb/mongodb.pid", port: 27017, quiet: true } ************** Unclean shutdown detected. Please visit http://dochub.mongodb.org/core/repair for recovery instructions. ************* Thu Sep 5 11:07:06 [initandlisten] exception in initAndListen: 12596 old lock file, terminating Thu Sep 5 11:07:06 dbexit: Thu Sep 5 11:07:06 [initandlisten] shutdown: going to close listening sockets... Thu Sep 5 11:07:06 [initandlisten] shutdown: going to flush diaglog... Thu Sep 5 11:07:06 [initandlisten] shutdown: going to close sockets... Thu Sep 5 11:07:06 [initandlisten] shutdown: waiting for fs preallocator... Thu Sep 5 11:07:06 [initandlisten] shutdown: closing all files... Thu Sep 5 11:07:06 [initandlisten] closeAllFiles() finished Thu Sep 5 11:07:06 dbexit: really exiting now

rm -f /var/run/mongodb/mongodb.pid[/shell] Even if you delete the pid file, it doesn't go up.
It is a message that a data file inconsistency is occurring and must be recovered.

I've never repaired mongod, so I'll try to deal with it by looking at the pages and logs that appeared in the logs.
http://docs.mongodb.org/manual/tutorial/recover-data-following-unexpected-shutdown/ [shell]Thu Sep 5 11:07:06 [initandlisten] options: { bind_ip: "127.0.0.1", command: [ " run" ], config: "/etc/mongodb.conf", dbpath: "/var/lib/mongodb", fork: "true", logpath: "/var/log/mongodb/mongodb.log", nohttpinterface: "true", nojournal: "true", pidfilepath: "/ var/run/mongodb/mongodb.pid", port: 27017, quiet: true }[/shell]

If my English interpretation was different, it would be a big problem, so I searched for Japanese articles.
http://kaworu.jpn.org/kaworu/2012-12-26-1.php

Check the data directory.

[shell]# ll /var/lib/mongodb/ total 688152 drwxr-xr-x 2 mongodb mongodb 4096 May 31 10:57, 2013 _tmp -rw------- 1 mongodb mongodb 67108864 17 July 2013 18:04 devlab_db.0 -rw------- 1 mongodb mongodb 134217728 Apr 9 16:26, 2013 devlab_db.1 -rw------- 1 mongodb mongodb 16777216 17 Jul 2013 18:04 devlab_db.ns drwxr-xr-x 2 mongodb mongodb 4096 May 2 15:50 2013 journal -rwxr-xr-x 1 mongodb mongodb 6 May 2 14:48 2013 mongod.lock -rw------- 1 mongodb mongodb 67108864 30 Apr 2013 14:33 2013 sugatest.0 -rw------- 1 mongodb mongodb 134217728 30 Apr 2013 14:33 2013 sugatest.1 -rw------- 1 mongodb mongodb 268435456 17:47, 24 April 2013 -rw------- 1 mongodb mongodb 16777216 30 April 2013 14:33 sugatest.ns[/shell]

Perform the repair command.
[shell]# mongod --dbpath /var/lib/mongodb --repair Thu Sep 5 14:25:47 [initandlisten] MongoDB starting : pid=3941 port=27017 dbpath=/var/lib/mongodb 64-bit host=devlab Thu Sep 5 14:25:47 [initandlisten] db version v2.2.3, pdfile version 4.5 Thu Sep 5 14:25:47 [initandlisten] git version: nogitversion Thu Sep 5 14:25:47 [initandlisten] build info: Linux buildvm-09.phx2.fedoraproject.org 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Feb 20 12:17:37 EST 2013 x86_64 BOOST_LIB_VERSION=1_41 Thu Sep 5 14:25:47 [initandlisten] options: { dbpath : "/var/lib/mongodb", repair: true } Thu Sep 5 14:25:47 [initandlisten] **** Thu Sep 5 14:25:47 [initandlisten] **** Thu Sep 5 14:25:47 [initandlisten] need to upgrade database sugatest with pdfile version 4.5, new version: 4.5 Thu Sep 5 14:25:47 [initandlisten] starting upgrade Thu Sep 5 14:25:47 [initandlisten] sugatest repairDatabase sugatest Thu Sep 5 14:25:48 [FileAllocator] allocating new datafile /var/lib/mongodb/_tmp_repairDatabase_0/sugatest.ns, filling with zeroes... Omitted Thu Sep 5 14:25:50 [initandlisten] build index done. scanned 34 total records. 0 secs Thu Sep 5 14:25:50 [initandlisten] build index devlab_db.lanternKeywordStats { keyword: 1 } Thu Sep 5 14:25:50 [initandlisten] fastBuildIndex dupsToDrop:0 Thu Sep 5 14:25:50 [ initandlisten] build index done. scanned 2 total records. 0 secs Thu Sep 5 14:25:50 [initandlisten] finished checking dbs Thu Sep 5 14:25:50 dbexit: Thu Sep 5 14:25:50 [initandlisten] shutdown: going to close listening sockets... Thu Sep 5 14:25:50 [initandlisten] shutdown: going to flush diaglog... Thu Sep 5 14:25:50 [initandlisten] shutdown: going to close sockets... Thu Sep 5 14:25:50 [initandlisten] shutdown: waiting for fs preallocator... Thu Sep 5 14:25:50 [initandlisten] shutdown: closing all files... Thu Sep 5 14:25:50 [initandlisten] closeAllFiles() finished Thu Sep 5 14:25:50 [initandlisten] shutdown: removing fs lock... Thu Sep 5 14:25:50 dbexit: really exiting now[/shell]

Repairs were carried out like the above,
I tried to start it, but it still doesn't come up, so I looked at the logs and found a description that there was a problem with permissions.

[shell]Thu Sep 5 14:31:35 [initandlisten] couldn't open /var/lib/mongodb/sugatest.ns errno:13 Permission denied Thu Sep 5 14:31:35 [initandlisten] error couldn't open file /var/lib/ mongodb/sugatest.ns terminating[/shell]

When I checked, the permissions were different from before the repair was performed, so I corrected the permissions.
[shell]# ll total 688160 drwxr-xr-x 2 root root 4096 Sep 5 14:25 2013 devlab_db -rw------- 1 root root 67108864 Sep 5 14:25 2013 devlab_db.0 -rw------- 1 root root 134217728 Sep 5 14:25 2013 devlab_db .1 -rw------- 1 root root 16777216 Sep 5 14:25 2013 devlab_db.ns drwxr-xr-x 2 mongodb mongodb 4096 May 2 15:50 2013 journal -rwxr-xr-x 1 mongodb mongodb 0 Sep 5 14:31 2013 mongod.lock drwxr-xr-x 2 root root 4096 14:25, 5 Sep 2013 sugatest -rw------- 1 root root 67108864 5 Sep 2013 14:25 sugatest.0 -rw------- 1 root root 134217728 14:25, 5 Sep 2013 sugatest.1 -rw------- 1 root root 268435456 5 Sep 2013 14:25 sugatest.2 -rw------- 1 root root 16777216 14:25, 5 September 2013 sugatest.ns #chown -R mongodb. /var/lib/mongodb # service mongod start mongod: [ OK ] # netstat -lnpt Active Internet connections (only servers) proto recv-q send-q local address foreign address state PID/program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1234/mysqld tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 3619/nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 3619/nginx tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 860/ sshd tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 3719/node tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1361/master tcp 0 0 0.0.0.0:10080 0.0.0.0:* LISTEN 3619/nginx tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1415/php-fpm tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 3989/mongod[/shell]

It looks like mongod has started as well.
That's it for now.

Regarding the start and stop in forever, you can deal with it by creating a startup script or preparing the startup procedure.
It has been pointed out that it is necessary, and I think so.

If you just write a startup command in rc.local, it won't stop well, and it won't stop while stopping like this time.
There is a possibility that an incident will occur.
Also, if it is forcibly stopped, the pid file remains undeleted and cannot be started next time.
It is desirable to create a startup script that properly writes the startup stop process.
I think it is relatively easy to do it by writing the start and stop sections in the case statement.

The person in charge won't be back until October, so I'll try it myself.

[shell]# ps -ef|grep forever root 3717 1 0 11:55 ? 00:00:00 /usr/local/bin/node /usr/local/lib/node_modules/forever/bin/monitor app.js root 4046 3495 0 15:08 pts/1 00:00:00 grep forever

vi /etc/init.d/forever ------------- #!/bin/bash # # chkconfig: 345 99 01 # description: start/stop script for node.js # processname: /usr/local/bin/forever # config:

# We require the /etc/delegeted.conf file, but supply it in the package, so it # should always be there. progname=forever lockfile=/var/lock/subsys/forever prog=/usr/local/bin/forever appdir=/usr/local/lib/src/g**** conffile=app.js export PATH=/usr/local/bin:$PATH

RETVAL=0

start() { echo -n $"Starting $progname: " cd $appdir && $prog --minUptime 1000ms --spinSleepTime 1000ms start $conffile RETVAL=$? echo [ $RETVAL = 0 ] && touch $lockfile return $RETVAL }

stop() { echo -n $"Stopping $progname: " cd $appdir && $prog stop $conffile RETVAL=$? echo [ $RETVAL = 0 ] && rm -f $lockfile return $RETVAL }

# See how we were called. case "$1" in start) start ;; stop) stop ;; status) $prog list RETVAL=$? ;; restart) stop start ;; condrestart) if [ -f $lockfile ]; then stop start fi ;; *) echo $"Usage: $0 {start|stop|restart|condrestart|status}" exit 1 esac

exit $RETVAL -------------------------------- # chmod +x /etc/init.d/forever # chkconfig --add forever # chkconfig --list forever forever 0:off 1:off 2:off 3:on 4:on 5:on 6: off[/shell]

It looks like I can now start it with a launch script. (I feel like the person in charge needs to check whether the location of the app to be launched is correct.)

[shell]# service forever start Starting forever: info: Forever processing file: app.js

# forever list info: Forever processes running data: uid command script forever pid logfile uptime data: [0] 9XwM /usr/local/bin/node app.js 3816 3818 /root/.forever/9XwM.log 0:0:0:7. 578[/shell]

I'm worried about a lot of things that stayed in stopping, so I'll try to reboot on a trial basis.
I feel like it would have been better to hit the shutdown command instead of from the browser.

[shell]# reboot[/shell]

Log in again

[shell]# uptime 15:55:26 up 0 min, 1 user, load average: 0.41, 0.11, 0.03

# netstat -lnpt Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1227/mysqld tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 1423/nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1423/nginx tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 853/sshd tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 1459/node tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1347/master tcp 0 0 0.0.0.0:10080 0.0.0.0:* LISTEN 1423/nginx tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1401/php-fpm tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 783/mongod[/shell]

It seems that it started to start normally even after rebooting.
It seems that you can check the troubleshooting method when the status check fails after startup from the link below.
http://docs.aws.amazon.com/ja\_jp/AWSEC2/latest/UserGuide/TroubleshootingInstances.html

・Lessons learned this time:
 I thought that force dettach was the trump card when you didn't start.
 While stopping, you will be waiting for AWS to clean up, so make sure to AMI it.
 After adding something additional, it is better to set up an automatic startup mechanism and test the OS restart (or manage it with Chef or test it with Serverspec).
 Before AWS maintenance, it is better to create an AMI and make it replicable, and to shutdown -h now instead of stop from the browser.
 The AWS forum seems to be more responsive when using English.

Personally, I don't think it's particularly uncommon for the same demon not to come up properly.
 It was the first time that an AWS instance did not stop, so I learned that it doesn't always stop well.

Thank you for watching the above.

Related Articles