log errors to syslog [$5] #8

New Issue

2026-10-05T03:52:58+02:00

adam commented

2026-10-05 03:52:58 +02:00

I would like to see znc errors logged to syslog. This allows it to fit more easily into standard ops workflows so alerts can be set up, so there is a known place to look for errors, and the is a history of logs that can be archived. The current practice of logging to an admin user on *status doesn't help if an admin user is not currently logged in to znc.

--- There is a **[$5 open bounty](https://www.bountysource.com/issues/704-log-errors-to-syslog?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).

I would like to see znc errors logged to syslog. This allows it to fit more easily into standard ops workflows so alerts can be set up, so there is a known place to look for errors, and the is a history of logs that can be archived. The current practice of logging to an admin user on *status doesn't help if an admin user is not currently logged in to znc. ## <bountysource-plugin> --- There is a **[$5 open bounty](https://www.bountysource.com/issues/704-log-errors-to-syslog?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [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 03:52:59 +02:00

Uhm, which errors are logged to *status?
AFAIK only failed rehashes are and logging just those to syslog feels wrong.

Which other error messages do you have in mind?

Uhm, which errors are logged to *status? AFAIK only failed rehashes are and logging just those to syslog feels wrong. Which other error messages do you have in mind?

adam commented

2026-10-05 03:53:00 +02:00

If I edit znc.conf and then "/znc rehash", I get messages if the rehashing did not succeed. However, if I "kill -HUP ", I am not given any messages if the rehashing failed. I would like to be able to look in a log file (syslog or otherwise) on the machine to diagnose errors.

If I edit znc.conf and then "/znc rehash", I get messages if the rehashing did not succeed. However, if I "kill -HUP <zncpid>", I am not given any messages if the rehashing failed. I would like to be able to look in a log file (syslog or otherwise) on the machine to diagnose errors.

adam commented

2026-10-05 03:53:00 +02:00

So only rehash errors should go to syslog, no other kind of error? Why would anyone check the syslog for failed rehashes then?

So only rehash errors should go to syslog, no other kind of error? Why would anyone check the syslog for failed rehashes then?

adam commented

2026-10-05 03:53:01 +02:00

Honestly, I've used znc for quite a while and have only had errors that were my fault (bad configs, etc). It's quite reliable, so I don't even really know what errors could happen.

The kind of errors I'm talking about are the ones that prevent ZNC from running. Of course, I've seen transient IRC connectivity issues. I agree that those may not need to be in a syslog entry (although I don't think that's a problem if they are there).

My situation is that I (and my coworkers) maintain an instance of znc on an internal machine for users that aren't familiar with IRC. Generally, those of us that are familiar use screen+irssi or our own instance of ZNC on our own machine. When users are added or removed from the znc config, the processed is HUP'd, and we have to simple wait and see if the changes took. There is no feedback. Server locations or ports may have been entered incorrectly. Closing tags may be missing. The only way to know if there is an error is to wait and see what happens. And "wait-and-see" only works if the recent change involved something that can be seen. If it were something like buffer size changes, I would have to assume the changes took since there is no way for me to see any logs. In my opinion, a known, standard place like syslog (or something else in /var/log) would let me check for errors easily and monitor with alerts if something needs attention.

Honestly, I've used znc for quite a while and have only had errors that were my fault (bad configs, etc). It's quite reliable, so I don't even really know what errors could happen. The kind of errors I'm talking about are the ones that prevent ZNC from running. Of course, I've seen transient IRC connectivity issues. I agree that those may not need to be in a syslog entry (although I don't think that's a problem if they are there). My situation is that I (and my coworkers) maintain an instance of znc on an internal machine for users that aren't familiar with IRC. Generally, those of us that are familiar use screen+irssi or our own instance of ZNC on our own machine. When users are added or removed from the znc config, the processed is HUP'd, and we have to simple wait and see if the changes took. There is no feedback. Server locations or ports may have been entered incorrectly. Closing tags may be missing. The only way to know if there is an error is to wait and see what happens. And "wait-and-see" only works if the recent change involved something that can be seen. If it were something like buffer size changes, I would have to assume the changes took since there is no way for me to see any logs. In my opinion, a known, standard place like syslog (or something else in /var/log) would let me check for errors easily and monitor with alerts if something needs attention.

adam commented

2026-10-05 03:53:02 +02:00

So in other words, you already figured out yourself that it's a bad idea to edit the config by hand. However, you didn't yet figure out that it's better to edit the config via webadmin.

So in other words, you already figured out yourself that it's a bad idea to edit the config by hand. However, you didn't yet figure out that it's better to edit the config via webadmin.

adam commented

2026-10-05 03:53:02 +02:00

The complete lack of any logging in znc is pretty unusual. For example, if you clobber the perms on your ssl cert so that znc can't read it, it just sits there with its eyes crossed and there's no indication of what's wrong.

The complete lack of any logging in znc is pretty unusual. For example, if you clobber the perms on your ssl cert so that znc can't read it, it just sits there with its eyes crossed and there's no indication of what's wrong.

adam commented

2026-10-05 03:53:03 +02:00

Something like http://logging.apache.org/log4cxx/ may be used, and it supports more than just syslog... Though perhaps we'll need a license change for that (e.g. #218)

Something like http://logging.apache.org/log4cxx/ may be used, and it supports more than just syslog... Though perhaps we'll need a license change for that (e.g. #218)

adam commented

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