1

I'm configuring systemd in a cloud-config file for CoreOS. If I understand this correctly, I have two ways of starting a unit at boot:

Alternative 1, use the [Install]-section (as described in digital oceans guides):

- name: initialize_data content: | [Unit] Description=Run a command [Service] Type=oneshot ExecStart=/usr/bin/mkdir /foo [Install] WantedBy=multi-user.target

Alternative 2, drop the [Install]-section and use command: start:

- name: initialize_data command: start content: | [Unit] Description=Run a command [Service] Type=oneshot ExecStart=/usr/bin/mkdir /foo

Is there any drawbacks of starting the unit using command: start? I get that I can't control which unit it will start after, but anything else? Will it honour [Unit]-directives such as Requires= and After=?

Improve this question

1 Answer 1

Reset to default
0

It appears on CoreOS there's little difference. When systemd is used on other Linux distributions, the distinction is that start only starts up a service, it doesn't cause it to start on boot. That's what enable does, by processing the [Install] section of a systemd file.

However, the CoreOS docs say that the cloud-config commands are processed on every boot. So by specifying a service to start through cloud-config, the service is essentially enabled as well.

CoreOS likely includes both options to give you the full flexibility of accessing both systemd features.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.