Caddy stops running after some hours

1. The problem I’m having:

Caddy stops after running for a while and I dont know why. Its been happening which leads to downtime . I would have to manually restart my server to get it working and its frustrating. Im hoping I can get a solution for this. thanks

2. Error messages and/or full log output:

When this happens , im unable to get logfile however when i run caddy status, I get this

 caddy.service - Caddy
     Loaded: loaded (/etc/systemd/system/caddy.service; enabled; vendor preset: enabled)
     Active: failed (Result: oom-kill) since Thu 2023-06-01 06:36:10 UTC; 5min ago
    Process: 3062139 ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile (code=killed, signal=KILL)
   Main PID: 3062139 (code=killed, signal=KILL)
        CPU: 10min 19.533s

3. Caddy version:

caddy v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

4. How I installed and ran Caddy:

a. System environment:

Ubuntu 22.04.1 LTS (GNU/Linux 5.15.0-1019-aws aarch64)

b. Command:

sudo systemctl enable caddy
sudo systemctl start caddy
sudo systemctl restart caddy

c. Service/unit/compose file:

Please use the preview pane to ensure it looks nice.

d. My complete Caddy config:

  storage s3 {
        host "my host"
        bucket "my-bucket"
        access_id "my key"
        secret_key "my key"
        prefix "ssl"
        insecure true
        storage_clean_interval 100d
on_demand_tls {
             interval 2m
             burst 5

http:// {
redir https://{host}{uri}

*, {
@www header_regexp www Host ^www\.(.*)$
  redir @www https://{re.www.1} 301
tls {
    dns route53 {
    max_retries 10 
    aws_profile "my-key" 
    access_key_id "my-key" 
    secret_access_key "my-key" 
    region "my-region" 
        root * /var/www/lave/public
        encode zstd gzip
         php_fastcgi unix//var/run/php/php8.2-fpm.sock

https:// {
@www header_regexp www Host ^www\.(.*)$
  redir @www https://{re.www.1} 301

         tls {

        root * /var/www/lave/public/
        encode zstd gzip
         php_fastcgi unix//var/run/php/php8.2-fpm.sock


5. Links to relevant resources:

Are you sure there’s no logs? What do you see with this:

journalctl -u caddy --no-pager | less +G

This implies Caddy got killed due to your system running out of memory. How much RAM does that machine have?

Since you’re using on-demand-tls, keep in mind that certificates are cached in memory, so if you have a lot of certificates, that could be the cause.

Do you have any monitoring on that system? Check memory usage graphs. Is there anything else running on that machine that could be eating up RAM? If so Caddy could get killed off even if it isn’t the one using a lot of memory.

See Keep Caddy Running — Caddy Documentation for instructions to turn on restarting for your systemd service, it should help mitigate downtime.

the system has 2gig ram
I think thats why it got killed right ? because memory usage is quiet high according to monitoring graphs

You know you don’t need this, right? :upside_down_face:

You’ll know after running the command Francis gave you :slight_smile:

2gigs of ram should run Ubuntu server ok as long as you don’t run much anything else on it. I run the minimal install of Ubuntu server, and with only caddy running on it I see about 700mb ram used usually.

1 Like

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