Don't reload znc.pem on every client connection #662

New Issue

2026-10-05T04:36:58+02:00

adam commented

2026-10-05 04:36:58 +02:00

Need some way to poke ZNC to reload it instead.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29395815-don-t-reload-znc-pem-on-every-client-connection?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

Need some way to poke ZNC to reload it instead. ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/29395815-don-t-reload-znc-pem-on-every-client-connection?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:36:59 +02:00

One option is to use inotify

One option is to use inotify

adam commented

2026-10-05 04:37:00 +02:00

Just add an command like znc reloadcert or similar.

It will work for most purposes. Anyone who is using Letsencrypt (or any other CA) most likely already uses cron jobs to update the certificate and concatenate the cert files into znc.pem, so adding another cron job that reloads the cert after updating it shouldn't be an issue.

Just add an command like znc reloadcert or similar. It will work for most purposes. Anyone who is using Letsencrypt (or any other CA) most likely already uses cron jobs to update the certificate and concatenate the cert files into znc.pem, so adding another cron job that reloads the cert after updating it shouldn't be an issue.

adam commented

2026-10-05 04:37:01 +02:00

@muffeeee such command would require user to connect to ZNC via IRC protocol (and authenticate as some admin) from crontab.

@muffeeee such command would require user to connect to ZNC via IRC protocol (and authenticate as some admin) from crontab.

adam commented

2026-10-05 04:37:01 +02:00

No, I'm not talking about an IRC command - I'm talking about a UNIX command that can also be run manually from a terminal session.

znc reloadcert

Either that, or make service znc reload also reload cert, or make something like service znc reloadcert

No, I'm not talking about an IRC command - I'm talking about a UNIX command that can also be run manually from a terminal session. `znc reloadcert` Either that, or make `service znc reload` also reload cert, or make something like `service znc reloadcert`

adam commented

2026-10-05 04:37:02 +02:00

@muffeeee The second part only works when ZNC is set up as a service which is NOT the default configuration. The first operates on the principle that there's a way to pass a command to the running ZNC from the command like, which I don't think is possible as it currently exists.

@muffeeee The second part only works when ZNC is set up as a service which is NOT the default configuration. The first operates on the principle that there's a way to pass a command to the running ZNC from the command like, which I don't think is possible as it currently exists.

adam commented

2026-10-05 04:37:03 +02:00

Either way, my znc doesn't reload the cert on every connection anyway for some reason, so I'm still stuck with a soon-to-expire cert unless I restart znc.

Either way, my znc doesn't reload the cert on every connection anyway for some reason, so I'm still stuck with a soon-to-expire cert unless I restart znc.

adam commented

2026-10-05 04:37:03 +02:00

No permissions to read the file?
ZNC does NOT cache cert in memory yet. This bug is exactly about this.

2016-01-17 14:50 GMT+00:00 muffe notifications@github.com:

Either way, my znc doesn't reload the cert on every connection anyway for
some reason, so I'm still stuck with a soon-to-expire cert unless I restart
znc.

—
Reply to this email directly or view it on GitHub
https://github.com/znc/znc/issues/1215#issuecomment-172331576.

No permissions to read the file? ZNC does NOT cache cert in memory yet. This bug is exactly about this. 2016-01-17 14:50 GMT+00:00 muffe notifications@github.com: > Either way, my znc doesn't reload the cert on every connection anyway for > some reason, so I'm still stuck with a soon-to-expire cert unless I restart > znc. > > — > Reply to this email directly or view it on GitHub > https://github.com/znc/znc/issues/1215#issuecomment-172331576.

adam commented

2026-10-05 04:37:04 +02:00

You could make ZNC reload all config files including znc.pem on SIGHUP, SIGUSR1, or SIGRTMIN.

You could make ZNC reload all config files including znc.pem on SIGHUP, SIGUSR1, or SIGRTMIN.

adam commented

2026-10-05 04:37:05 +02:00

Is this bug about a performance improvement? Is there a significant impact? When I first read that znc reloaded it on every connection it seemed like a great idea to me.

Is this bug about a performance improvement? Is there a significant impact? When I first read that znc reloaded it on every connection it seemed like a great idea to me.

adam commented

2026-10-05 04:37:05 +02:00

It's about LetsEncrypt, no one cared before it came.

It's about LetsEncrypt, no one cared before it came.

adam commented

2026-10-05 04:37:06 +02:00

Yeah but the current behavior makes it easier to use it with letsencrypt (no need to do anything to reload certs), while this ticket is about not reloading it every time and possibly adding an extra manual reload step (which is how it works everywhere else, but still)

So I assume it's for performance reasons. Just wondering how big of a deal that is. I don't know znc's scalability requirements, either.

Yeah but the current behavior makes it _easier_ to use it with letsencrypt (no need to do anything to reload certs), while this ticket is about not reloading it every time and possibly adding an extra manual reload step (which is how it works everywhere else, but still) So I assume it's for performance reasons. Just wondering how big of a deal that is. I don't know znc's scalability requirements, either.

adam commented

2026-10-05 04:37:06 +02:00

From what I have understood the longer term aim is to

Start ZNC as root
ZNC reads certs from /etc/letsencrypt/whatever
3.ZNC becomes the normal user and continues normally.

Or at least that has been wished without having to manually copy LE certs around the system and lose automatic renewals.

From what I have understood the longer term aim is to 1. Start ZNC as root 2. ZNC reads certs from /etc/letsencrypt/whatever 3.ZNC becomes the normal user and continues normally. Or at least that has been wished without having to manually copy LE certs around the system and lose automatic renewals.

adam commented

2026-10-05 04:37:07 +02:00

Start ZNC as root

Certainly no, see #1233

which is how it works everywhere else

That's the reason

> Start ZNC as root Certainly no, see #1233 > which is how it works everywhere else That's the reason

adam commented

2026-10-05 04:37:08 +02:00

If it's not done for performance benefit there is no reason to fix this. I consider it a feature.
And frankly the performance penalty of the file read is negligible. It's not a web server with thousands of connections requesting it constantly.
Otherwise triggering the reload of the certificate via handling SIGHUP is the best option.
Restarting znc to reload the certificate should not be considered.

If it's not done for performance benefit there is no reason to fix this. I consider it a feature. And frankly the performance penalty of the file read is negligible. It's not a web server with thousands of connections requesting it constantly. Otherwise triggering the reload of the certificate via handling SIGHUP is the best option. Restarting znc to reload the certificate should not be considered.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#662