Infrastructure/caddy
0
Fork 0
mirror of https://github.com/caddyserver/caddy.git synced 2025-01-13 22:51:08 -05:00
Code Issues Activity

systemd, README: Edit for clarity

Browse source
This commit is contained in:
W-Mark Kubacki 2016-05-11 19:09:54 +02:00
parent 389a6eb344
commit d377c79a5d
No known key found for this signature in database
GPG key ID: C6704E572665DF57
1 changed files with 35 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
dist/init/linux-systemd/README.md vendored
View file

@ -1,40 +1,54 @@
# systemd unit for caddy # systemd unit for caddy
Please do not hesitate to ask [me](mailto:klingt.net+caddy@gmail.com) if you've any questions. Please do not hesitate to ask if you have any questions.
## Quickstart ## Quickstart
- install the unit configuration file: `cp caddy@.service /etc/systemd/system` - Install the unit configuration file: `cp caddy.service /etc/systemd/system/`
- reload the systemd daemon: `systemctl deamon-reload` - Reload the systemd daemon: `systemctl daemon-reload`
- make sure to [configure](#configuration) the service unit before starting caddy - Make sure to [configure](#configuration) the service unit before starting caddy.
- start caddy: `systemctl start caddy@someuser` - Start caddy: `systemctl start caddy.service`
- enable the service (automatically start on boot): `systemctl enable caddy@someuser` - Enable the service (automatically start on boot): `systemctl enable caddy.service`
- the `.caddy` folder will be created inside the users home directory that runs caddy, i.e. `/home/someuser/.caddy` for `systemctl start caddy@someuser` - A folder `.caddy` will be created inside the home directory of the user that runs caddy;
you can change that by providing an environment variable `HOME`,
i.e. `Environment=HOME=/var/lib/caddy` will result in `/var/lib/caddy/.caddy`.
## Configuration ## Configuration
- do not edit the systemd unit directly, use systemd's builtin tools: - Do not edit the systemd unit file directly. Instead, use systemd's builtin tools:
- `systemctl edit caddy@` to make user local modifications to the service unit - `systemctl edit caddy.service` to make user-local modifications
- `systemctl edit --full caddy@` to make system-wide modifications - `systemctl edit --full caddy.service` for system-wide ones
- in most cases it's enough to adapt the `ExecStart` directive: - In most cases it is enough to override the `ExecStart` directive.
- `systemctl edit caddy@` - systemd needs absolute paths, therefore make sure that the path to caddy is correct.
- systemd needs absolute paths, therefore make sure that the path to caddy is correct
- example: - example:
```ini ```ini
[Service] [Service]
; reset the original setting ; an empty value clears the original (and preceding) settings
ExecStart= ExecStart=
ExecStart=/usr/bin/caddy -conf="/etc/caddy/myCaddy.conf" -agree -email="my@mail.address" ExecStart=/usr/bin/caddy -conf="/etc/caddy/myCaddy.conf" -agree -email="my@mail.address"
``` ```
- to view your configuration use `systemctl cat caddy@` - To view the resulting configuration use `systemctl cat caddy`
- double check the permissions of your web root path to make sure that caddy can access it as its run user and group - Double check permissions of your *document root* path.
The user caddy runs as needs to have access to it. For example:
```bash
# caddy would run as www-data:www-data
# serving, in this example: /var/www
sudo -u www-data -g www-data -s \
ls -hlAS /var/www
```
## Tips ## Tips
- use `log stdout` and `errors stderr` in your Caddyfile to make use of `journalctl` - Use `log stdout` and `errors stderr` in your Caddyfile to utilize `journalctl`.
- `journalctl` is systemd's log query tool - `journalctl` is systemd's log query tool.
- lets say you want all the log entries for caddy since the last boot beginning from the last entry: `journalctl --reverse --boot --unit caddy@someuser` - Let's say you want all the log entries since the last boot, beginning from the last entry:
- maybe you want to follow caddys log output: `journalctl -fu caddy@someuser` `journalctl --reverse --boot --unit caddy.service`
- to send a signal to a service units main PID, e.g. let caddy reload its config: `systemctl kill --signal=USR1 caddy@someuser` - To follow caddy's log output: `journalctl -fu caddy.service`
- Send a signal to a service unit's main PID, e.g. have caddy reload its config:
`systemctl kill --signal=USR1 caddy.service`
- If you have more files that start with `caddy` – like a `caddy.timer`, `caddy.path`, or `caddy.socket` – then it is important to append `.service`.
Although if `caddy.service` is all you have, then you can just use `caddy` without any extension, such as in: `systemctl status caddy`