Cannot start caddy.service after system restart

1. My Caddy version (caddy -version):

1.0.3

2. How I run Caddy:

linux-systemd

a. System environment:

OS, relevant versions, systemd? docker? etc.

centos7 amd64 systemd

b. Command:

paste command here

c. Service/unit/compose file:

[Unit]
Description=Caddy HTTP/2 web server
Documentation=https://caddyserver.com/docs
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service

[Service]
Restart=on-abnormal

; User and group the process will run as.
User=root
Group=root

; Letsencrypt-issued certificates will be written to this directory.
Environment=CADDYPATH=/etc/ssl/caddy

; 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 -quic -root=/var/tmp
ExecReload=/bin/kill -USR1 $MAINPID

; Use graceful shutdown with a reasonable timeout
KillMode=mixed
KillSignal=SIGQUIT
TimeoutStopSec=5s

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

; Use private /tmp and /var/tmp, which are discarded after caddy stops.
PrivateTmp=true
; 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.)
PrivateDevices=false
; Hide /home, /root, and /run/user. Nobody will steal your SSH-keys.
ProtectHome=true
; Make /usr, /boot, /etc and possibly some more folders read-only.
ProtectSystem=full
; … 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!
ReadWritePaths=/etc/ssl/caddy

; 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.
;CapabilityBoundingSet=CAP_NET_BIND_SERVICE
;AmbientCapabilities=CAP_NET_BIND_SERVICE
;NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile:

http://www.hehevv.xyz {
    redir https://hehevv.xyz{url}
}
 
https://hehevv.xyz {
    root /var/www/
 
    tls ********@gmail.com {
        ciphers ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-WITH-CHACHA20-POLY1305 ECDHE-ECDSA-AES256-GCM-SHA384
        curves X25519 P384
        key_type p384
        protocols tls1.2 tls1.3
    }
 
    proxy /gameforum https://localhost:8888 {
        insecure_skip_verify
        header_upstream X-Forwarded-Proto "https"
        header_upstream Host "hehevv.xyz"
    }
     
    header / {
        Strict-Transport-Security "max-age=31536000;"
        X-XSS-Protection "1; mode=block"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
    }
    
    gzip {
       not /gameforum
    }
    
    log access.log {
    rotate_size 50
    rotate_age  90
    rotate_keep 2
    rotate_compress
    }
     
}

3. The problem I’m having:

After the system is restarted, the caddy.service cannot be started. The same caddy file and caddy.service run normally.

4. Error messages and/or full log output:

â—Ź caddy.service - Caddy HTTP/2 web server
Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2019-10-22 11:39:10 EDT; 18s ago
Docs: Welcome — Caddy Documentation
Process: 6893 ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -quic -root=/var/tmp (code=exited, status=1/FAILURE)
Main PID: 6893 (code=exited, status=1/FAILURE)

Oct 22 11:39:10 host.localdomain systemd[1]: Started Caddy HTTP/2 web server.
Oct 22 11:39:10 host.localdomain caddy[6893]: Activating privacy features… 2019/10/22 11:39:10 [INFO][cache:0xc0000888c0] Started certificate maintenance routine
Oct 22 11:39:10 host.localdomain caddy[6893]: 2019/10/22 11:39:10 [WARNING] Stapling OCSP: no OCSP stapling for [hehevv.xyz]: parsing OCSP response: ocsp: error from server: unauthorized
Oct 22 11:39:10 host.localdomain caddy[6893]: 2019/10/22 11:39:10 [INFO] Certificate for [heheheaa.cf] expires in -3h43m9.600992126s; attempting renewal
Oct 22 11:39:10 host.localdomain caddy[6893]: 2019/10/22 11:39:10 [INFO][hehevv.xyz] Renew certificate
Oct 22 11:39:10 host.localdomain caddy[6893]: 2019/10/22 11:39:10 creating lock file: open /etc/ssl/caddy/locks/cert_acme_hehevv.xyz_httpsacme-v02.api.letsencrypt.orgdirectory.lock: read-only file system
Oct 22 11:39:10 host.localdomain systemd[1]: caddy.service: main process exited, code=exited, status=1/FAILURE
Oct 22 11:39:10 host.localdomain systemd[1]: Unit caddy.service entered failed state.
Oct 22 11:39:10 host.localdomain systemd[1]: caddy.service failed.

5. What I already tried:

yes

6. Links to relevant resources:

Ah, we’ve seen this before on older systems like CentOS 7. Replace ReadWritePaths= with ReadWriteDirectories=.

1 Like

CentOS 7 is old… ? :sob: No VPS I use has CentOS 8 yet.

Ha, yes, CentOS 7 was released in 2014… that’s almost 6 years ago.

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