Timeout on WordPress cron job

1. Caddy version (caddy version):

2.4.3

2. How I run Caddy:

Installed using apt and started using systemd.

a. System environment:

Debian 11

b. Command:

systemctl start caddy

c. Service/unit/compose file:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

d. My complete Caddyfile or JSON config:

domain.com, www.domain.com {
        bind 999.888.777.666
        reverse_proxy https://111.222.333.444 {
                health_uri /
                health_interval 10s
                health_timeout 10s
                health_status 2xx
                header_up X-Real-IP {remote}
                transport http {
                        dial_timeout 10s
                        response_header_timeout 10s
                        expect_continue_timeout 10s
                        tls
                        tls_insecure_skip_verify
                        tls_timeout 10s
                        keepalive off
                        compression off
                }
        }
        tls {
                on_demand
        }
        import error.conf
}

3. The problem I’m having:

My reverse proxy is working fine in general, but when the backend server itself has a cron job which runs the WordPress cron job file (wp-cron.php?doing_wp_cron) on the server I get a timeout.

Everything else works great and no errors except for this one.

Any suggestions?

4. Error messages and/or full log output:

Sep 01 19:35:12 reverse-proxy caddy[522]: {"level":"error","ts":1630517712.9930885,"logger":"http.log.error","msg":"error handling handler error","request":{"remote_addr":"111.222.333.444:59262","proto":"HTTP/1.1","method":"GET","host":"domain.com","uri":"/wp-cron.php?doing_wp_cron","headers":{"User-Agent":["Wget/1.19.5 (linux-gnu)"],"Accept":["*/*"],"Accept-Encoding":["identity"],"Connection":["Keep-Alive"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"","proto_mutual":true,"server_name":"domain.com"}},"duration":10.044065007,"error":"{id=8ii24ymig} fileserver.(*FileServer).notFound (staticfiles.go:495): HTTP 404","first_error":{"msg":"http2: timeout awaiting response headers","status":502,"err_id":"wxcnuxz8p","err_trace":"reverseproxy.statusError (reverseproxy.go:857)"}}

This is saying (while goofy sounding) that there was an error inside of handle_errors. You didn’t include that part of your config in what you posted, so it’s impossible to say what might’ve gone wrong.

Here’s the content of error.conf

handle_errors {
        encode gzip
        root * /var/caddy
        file_server {
                index timeout.html
        }
}

I simply want to display that error when the backend times out. That is why it is trying to show the error.

You probably need a rewrite line in there. The request path is preserved as-is when going into handle_errors, so if there’s no file on disk in /var/caddy that matches that request path, it won’t succeed. According to your logs, the request was /wp-cron.php?doing_wp_cron, so Caddy is looking for a file /var/caddy/wp-cron.php, which it probably won’t find.

Also, I don’t recommend using /var/caddy or /var/lib/caddy for those files. A better location would probably be /srv.

I added the line

rewrite * timeout.html

I’ll change /var/caddy to /srv/caddy when this is resolved. /srv is still valid according to Filesystem Hierarchy Standard - Wikipedia so it does indeed seem like a better place for these files.

However, now that showing the error message is fixed it still doesn’t explain why the remote server can’t call the wp-cron.php file and times out all the time? Any idea on that one?

I couldn’t answer that. I don’t use WordPress.

You should probably configure your system to actually use crontab rather than using HTTP requests to trigger cron jobs. WordPress’ approach is a hack, mainly to deal with users on shared hosting who don’t have access to crontab.

I’m not the only user for the server. The server with the WordPress sites use a control panel which gives access to run cron jobs.

Most of those people disable the in-built WordPress cron job and run it using the control panels cron job function instead with the following command:

wget -q -O - https://domain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

I sadly can’t control what the users do, so I need to try and figure out another way to make it work if possible.
They could simply use the full path to the file, like /home/user/path/to/wp-cron.php but as I said, I can’t control what they do :confused:

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