Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd unit file documentation #200

Closed
vielmetti opened this issue Jan 9, 2017 · 6 comments
Closed

systemd unit file documentation #200

vielmetti opened this issue Jan 9, 2017 · 6 comments

Comments

@vielmetti
Copy link
Contributor

I'm installing the template [email protected] from the distribution, in order to bring up the system on CoreOS. The docs are a little bit thin; what I'd like to propose is a discussion here, which I'd summarize with a PR for docs/systemd.md that would summarize the instructions and perhaps suggest a best way to deal with that kind of setup, in several ways simple and complex.

To be fair the systemd docs on the use of the @ in a filename to create a variable are also kind of thin.

@vielmetti vielmetti changed the title Use of @ in filename for systemd unit file should be described systemd unit file documentation Jan 9, 2017
@kylemanna
Copy link
Owner

kylemanna commented Jan 9, 2017

Yes, definitely much needed as you've stumbled across the init script form a long time ago. On the bright side, Ubuntu and Debian have stabilized on systemd so the old upstart init script can probably also be removed.

Few comments while I think aloud:

  1. The IPv6 stuff in the current template is a mess because IPv6 in Docker is a mess, inclined to leave it there because it at least works, but I find it distracting.
  2. The ExecStartPre=-/usr/bin/docker pull $IMG step will pull updates to the image before running. I think this is handy to resolve security issues as images are pushed , but others may not expect their system to pull new images at init time. Thoughts?

@pieterlange
Copy link

Big fan of safe defaults here. If people don't want sudden updates to images they shouldn't be running latest anyway.

@vielmetti
Copy link
Contributor Author

Is docker pull a safe step if hub.docker.com is down, or network connections are wonky? We had some github down time today so I'm sensitive to overly reliable systems working a little too well so that they fail rarely and spectacularly.

Actually, hub.docker.com has had some issues of late so this is not an idly curious question.

@kylemanna
Copy link
Owner

Is docker pull a safe step if hub.docker.com is down, or network connections are wonky?

It's setup so that if the docker pull fails, the rest will run anyways:

From systemd.service(5):

If the absolute filename is prefixed with "-", an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is ignored and considered success.

If any of those commands (not prefixed with "-") fail, the rest are not executed and the unit is considered failed.
ExecStart= commands are only run after all ExecStartPre= commands that were not prefixed with a "-" exit successfully.

@pieterlange
Copy link

I was just about to link the docs :) https://www.freedesktop.org/software/systemd/man/systemd.service.html

kylemanna added a commit that referenced this issue Jan 16, 2017
* Describe how to use the reference service.
* Closes #200
kylemanna added a commit that referenced this issue Jan 16, 2017
* Describe how to use the reference service.
* Closes #200
kylemanna added a commit that referenced this issue Jan 16, 2017
* Describe how to use the reference service.
* Closes #200
kylemanna added a commit that referenced this issue Jan 16, 2017
* Describe how to use the reference service.
* Closes #200
kylemanna added a commit that referenced this issue Jan 16, 2017
* Describe how to use the reference service.
* Closes #200
@kylemanna
Copy link
Owner

Please continue discussion at #204

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants