2

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!

4

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!

| improve this answer | |
  • The full blob ends up being "config5": { "services": { "sysvinit": { "myservice": { "enabled": "true", "ensureRunning": "true" } } } } but no joy. Thanks. – LizH Oct 26 '15 at 15:03
  • Can you post the entire example in, this has worked works for me quite nicely in the past – bobmarksie Oct 28 '15 at 17:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.