A “supported service” in cloudformation-init::services

amazon-cloudformationamazon-web-services

I'm trying to launch a custom daemon from a cloudformation::init script. The /etc/init.d/myservice is fully functional; if I log in after cfn-init completes,

sudo service myservice start

behaves as expected.

There are two ways I can see to launch this directly from the cloudformation script, and I can't seem to get either of these to work:
(1) Using the cfn-init::services structure
(2) manually launching the script using a cfn-init::command.

(1) here is the relevent portion of the config.json as a service:

"Metadata": {
    "AWS::CloudFormation::Init": {
        "configSets": {
            "ascending": [
                "config5"
            ],
            "default": [
                "config5"
            ]
        },
        "config5": {
            "services": {
                "myservice": {
                    "enabled": "true",
                    "ensureRunning": "true"
                }
            }
        }
    }
}

Which produces the error:

2015-04-16 06:24:25,541 [INFO] -----------------------Starting build-----------------------
2015-04-16 06:24:25,856 [INFO] Running configSets: ascending
2015-04-16 06:24:25,856 [INFO] Running configSet ascending
2015-04-16 06:24:49,942 [INFO] Running config config5
2015-04-16 06:24:49,942 [WARNING] Unsupported service manager: myservice
2015-04-16 06:24:49,945 [INFO] ConfigSets completed
2015-04-16 06:24:49,949 [INFO] -----------------------Build complete-----------------------

This does /not/ produce a running service – it doesn't fail, it is just never kicked off. There seems to be an installation prerequisite here that I can't find documented. Yum-installed packages (nginx, tomcat, etc) launch with no warnings.

(2) Manually kicking off the service works, in the sense that the service starts. However, the service runs as its own user, and something seems to get lost in the cfn service, as that step in the configuation never completes, which keeps any further config sets from running. Mounting /opt in config1 is slightly irrelevent, I've included it to show what commands that do complete look like in the logs.
So the relevent config would be:

"Metadata": {
    "AWS::CloudFormation::Init": {
        "configSets": {
            "ascending": [
                "config1",
                "config5"
            ],
            "default": [
                "config5"
            ]
        },
        "config1": {
            "commands": {
                "mount1": {
                    "command": "umount /dev/xvdc"
                },
                "mount2": {
                    "command": "mount /dev/xvdc /opt"
                }
            }
        },
        "config5": {
            "commands": {
                "first_launch": {
                    "command": "/etc/init.d/myservice start"
                }
            }
        }
    }
}

Which produces the log:

2015-04-16 06:24:25,541 [INFO] -----------------------Starting build-----------------------
2015-04-16 06:24:25,856 [INFO] Running configSets: ascending
2015-04-16 06:24:25,856 [INFO] Running configSet ascending
2015-04-16 06:24:25,860 [INFO] Running config config1
2015-04-16 06:24:25,876 [INFO] Command mount1 succeeded
2015-04-16 06:24:25,901 [INFO] Command mount2 succeeded
2015-04-16 06:24:49,942 [INFO] Running config config5

Again, from the command prompt, the service command produces a running service and the expected output:

bash-4.1$ sudo service myservice start
Starting MyService: STARTED MyService Thu Apr 16 06:58:27 EDT 2015
-bash-4.1$

What kind of a return is cfn-init looking for?

Thanks!

Best Answer

The syntax of your services section isn't quite right i.e.

"services": {
    "myservice": {
        "enabled": "true",
        "ensureRunning": "true"
    }
}

If you look at the documentation http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-init.html#aws-resource-init-services it states ...

You can use the services key to define which services should be enabled or disabled when the instance is launched. On Linux systems, this key is supported by using sysvinit. On Windows systems, it is supported by using the windows service manager.

Because you're running a Linux system your "services" section should look like ...

"services": {
    "sysvinit" : {
        "myservice": {
            "enabled": "true",
            "ensureRunning": "true"
         }
    }
}

Hopefully that should do the trick!