Я создал init.d сценарий, названный rmCluster, который, как предполагается, выполняет простой сценарий Python на завершении работы, которое использует boto для завершения работу конкретного кластера серверов, с 755 перманентом, расположенным в /etc/init.d/rmCluster записанный как:

#!/bin/sh
#
# chkconfig: 0 1 1
# description: My service
#
# Author: Me
#
#
### BEGIN INIT INFO
# Provides: rmCluster
# Required-Start:
# Required-Stop:
# Default-Start:  0
# Default-Stop:  0
# Short-Description: My service
# Description: My service
### END INIT INFO

case $1 in
start)
python /usr/local/sbin/instanceStopper.py &
touch /tmp/theScriptWorks
;;
esac
exit 0

Я также создал символьную ссылку в /etc/rc0.d/S00rmCluster который указывает на вышеупомянутое. Обратите внимание, что я касаюсь файла в/tmp, который успешно происходит.

Сценарий Python также имеет 755 полномочий и записан как:

#!/usr/bin/env python

import boto.ec2
import subprocess

conn=boto.ec2.connect_to_region("us-west-2")
reservations = conn.get_all_instances()
cluster = []
inst_id = subprocess.Popen(["wget", "-q", "-O", "-", "http://169.254.169.254/latest/meta-data/instance-id"], stdout=subprocess.PIPE).communicate()[0]

for res in reservations:
    for inst in res.instances:
        if inst_id in inst.tags["Name"] and "cloudformation" not in inst.tags:
            cluster.append( "%s" %(inst.id) )

conn.terminate_instances(cluster)

Обратите внимание, что работы сценария Python, превосходные при прямом вызове и это также, хорошо работают при запущении init.d скрипт непосредственно. Я также попытался удалить хижину в сценарии Python и определении пути к Python в вызове init.d, и это все еще не работает.

Моя начальная буква, хотя то, что, возможно, библиотеки Python не длиннее доступный во время этого времени выполнения так сбои сценария, но я не уверен, как проверить это. Кроме того, я рассмотрел это, возможно, это должно в настоящее время помещаться где-то в другом месте в rc.x директорах, я установил на в S00, и это - единственный S00. Killall, который я переместил в S01 и останов, который я переместил в S02; это только три "S" сценария в дистанционном управлении 0/

Я делаю ценил справку

Решение

Решением была комбинация входа от ответа @Jayan и @Kjetil Joergensen.

Заключительная рабочая версия init.d сценария следующие:

#!/bin/bash
#
# chkconfig: 2345 99 1
# description: My service
#
# Author: me
#
#
### BEGIN INIT INFO
# Provides: rmCluster
# Required-Start:
# Required-Stop:
# Default-Start:  0
# Default-Stop:  0
# Short-Description: My service
# Description: My service
### END INIT INFO


case "$1" in
start)
touch /var/lock/subsys/rmCluster
;;
stop)
/usr/bin/python /usr/local/sbin/instanceStopper.py
;;
esac
exit 0

Существенные изменения были:

1. Перемещение 'запускается)' часть в 'остановку)', часть
2. Касание файла блокировки в 'запускается)', часть
3. Изменение 'chkconfig': параметр так, чтобы это 'запустилось' с нормальных сервисов и добралось, уничтожил с ними также, таким образом препятствуя тому, чтобы сценарий пытался выполнить сообщение, 'объединяющее завершение работы в сеть', как замечено @Kjetil Joergensen

Примечание: Сценарий Python не был изменен.

Два протеста, каждый - то, что это требует для выполнения service start rmCluster для него, чтобы быть завершением работы во время runlevel 0 и 6. Для меня это было приемлемо, так как это будит набор во время cloudformation, настраивающего, таким образом, это тривиально для добавления этого шага в Пользовательские Данные EC2. Второе - то, что сценарий выполняется во время перезагрузок также, которые не могут быть идеальными для каждого варианта использования. Я должен буду сделать дальнейшее расследование, чтобы видеть, как сделать таким образом, что только runlevel 0 на самом деле выполнения 'останавливаются' на этом сценарии.

Спасибо вам обоим за справку.