Is there a config reloader when the mounted tls certs at the location runner/certs changed?

Hi Team,

We are running Pushpin as a Helm chart in our Kubernetes cluster and have mounted TLS certificates for our domain at runner/certs location in the pod. Recently, the certificates were renewed. However, since there was no config reload or pod restart, the certificate changes have not propagated.

Is there a reload endpoint on the server so that I can try sending a SIGHUP signal to reload the configuration rather than restarting the pod?

I suspect you can get a more definitive answer from @jkarneges or @harmony7 , but as I understand it the Pushpin design is intended to allow you to freely restart instances when needed. If that’s the path you choose, you’d want to run multiple pods for redundancy, and restart them in sequence so they each get updated while the others continue to handle traffic.

Certs are cached in memory and automatically reloaded when the underlying file timestamps change. Try touching the files?

1 Like

We are using cert-manager to issue certificates, and I attempted to recreate the certificate, which in turn created a new TLS secret. The new secret file is reflected in the pod volume, but the modified timestamp on the file hasn’t changed. Is there a better way for Pushpin to identify changes, such as the MD5 checksum of the file, rather than the modified timestamp?

Maybe something like that could be implemented, but a goal is for the cache hits to be very cheap. I’d see about trying to make cert-manager update timestamps before making Pushpin do more disk I/O.