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=?

gogstad
  • 143
  • 5

1 Answers1

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.

Mark Stosberg
  • 3,901
  • 24
  • 28