Install as Service On Raspberry Pi?

I’m mostly a Windows person, but I decided to have a go at getting Caddy running on a Raspberry Pi. I followed this guide: How to Setup a Raspberry Pi Caddy Web Server - Pi My Life Up

If I ran Caddy manually from the command line, everything works fine. However, when I try to run it as a service I get this error:

caddy.service - Caddy HTTP/2 web server
Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/caddy.service.d
Active: failed (Result: exit-code) since Tue 2018-02-06 03:11:05 UTC; 19s ago
Docs: Welcome — Caddy Documentation
Main PID: 5375 (code=exited, status=217/USER)

Feb 06 03:11:05 raspberrypi systemd[1]: Started Caddy HTTP/2 web server.
Feb 06 03:11:05 raspberrypi systemd[1]: caddy.service: Main process exited, code=exited, status=217/USER
Feb 06 03:11:05 raspberrypi systemd[1]: caddy.service: Unit entered failed state.
Feb 06 03:11:05 raspberrypi systemd[1]: caddy.service: Failed with result ‘exit-code’.

This is what my service definition file looks like:

Description=Caddy HTTP/2 web server
Documentation= systemd-networkd-wait-online.service


; User and group the process will run as.

; Letsencrypt-issued certificates will be written to this directory.

; Always set “-root” to something safe in case it gets forgotten in the Caddyfile.
ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp
ExecReload=/bin/kill -USR1 $MAINPID

; Use graceful shutdown with a reasonable timeout

; Limit the number of file descriptors; see man systemd.exec for more limit settings.
; Unmodified caddy is not expected to use more than that.

; Use private /tmp and /var/tmp, which are discarded after caddy stops.
; Use a minimal /dev (May bring additional security if switched to ‘true’, but it may not work on Raspberry Pi’s or other devices, so it has been disabled in this dist.)
; Hide /home, /root, and /run/user. Nobody will steal your SSH-keys.
; Make /usr, /boot, /etc and possibly some more folders read-only.
; … except /etc/ssl/caddy, because we want Letsencrypt-certificates there.
; This merely retains r/w access rights, it does not add any new. Must still be writable on the host!

; The following additional security directives only work with systemd v229 or later.
; They further restrict privileges that can be gained by caddy. Uncomment if you like.
; Note that you may have to add capabilities required by any plugins in use.


Any idea what’s going wrong?

I don’t do much systemd, but it looks like this part is very specifically called out as potentially not working on Raspberry Pis. I guess as the unit file was updated to uncomment it, the comment itself wasn’t changed?

Probably not smart on the guide author’s part to link to the master branch of caddy.service instead of a commit that, presumably, worked at the time of writing the guide.

I commented out that line and tried it again, but I get the same error.

Do you know of any other options for running Caddy as a service on a Raspberry Pi instead of systemd?


Actually, I’ve just realised - it sets it false, so the comment is accurate. My mistake!

Honestly, other than that, it looks mostly the same as the file would have been when the author wrote the guide.

As for other options for running as a service… I use Docker, which handles init for the services on my systems. I don’t know if it’ll work all that well on a Pi…

Is the www-data user set up correctly on your Pi? The error code indicates a problem there.

I honestly don’t know. I went through all of the commands in the tutorial, but I’m not sure how to check if the user is set up correctly.

You could check for it in /etc/passwd. Here’s what mine looks like. I expect it to look similar on a Pi.

whitestrake at cadmus in ~
→ grep "www-data" /etc/passwd

Yep, mine is identical to yours:


Google’s got plenty of results for people with this error code for usernames with a dash in them, but all of them seem to agree that when it’s set directly (i.e. user=www-data) there’s no issue, so that doesn’t seem like our culprit.

Hopefully someone here with more experience with systemd than I will be able to pop in and help.

Raspberry Pi’s depending on OS may handle users differently.

Try changing the user/group in systemd to the main user of your PI.

If it works, I see two possibilities:

  1. systemd will not start any service for user which name contains dash ("-"). systemd will exit with status 217 (See: FS#37755 : [systemd] does not start service for USER with dash in name) (check your systemd version)
  2. The user and group needs to be a “local” user (so may need to be adjusted)

It looks like I am running systemd version 232, so I don’t think this version is affected by the dash problem.

I tried changing the user/group to the user “pi”. I edited the caddy.service file, and tried to reinstall the service. Save error. But maybe I am misunderstanding what you mean by the main user of my Pi (the default username for Raspbian is pi).

Looks like I am still stuck.

I meant the “pi” user (main user) yes.

I’ll let you know if I have other ideas.

I managed to find a workaround, but I’m not sure if there is any downside to doing it this way.

The rc.local file can run things automatically whenever the Raspberry Pi starts, so I put this line in there:

sudo caddy -conf /etc/caddy/Caddyfile &

And that seems to do the trick.

I ran into another problem when trying to transfer files to /var/www/localhost, I kept getting permission errors in WinSCP. I moved all of the files in the webroot to /home/pi/caddywww and that seems to fix that problem. I’m not sure if that’s a proper way to do things on Linux though.

Stuff really only goes in /var/www by long-standing convention (run man hier, short for ‘hierarchy’, on your Pi - it probably has a copy of the standard for the file system hierarchy, which is notably not a tutorial, merely a reference). You can put your HTML files wherever you like, including the home folder of the user your web server runs as. There’s almost no “wrong” place to put things.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.