Unrecoverable config error when a module [no longer] exists. #596

New Issue

2026-10-05T04:32:09+02:00

adam commented

2026-10-05 04:32:09 +02:00

Based on #1119 - Mikaela brought up a valid point. What if users upgrade and their configuration is not up to date?

I put the idea to test, and was confident ZNC would handle this manner in a clean and elegant way, perhaps something like "This module [no longer] seems to exist, ignoring this config entry". Perhaps with a prompt "Start ZNC anyways?" and a --ignore-missing-modules flag.

[ .. ] Checking for list of available modules...
[ >> ] ok
[ .. ] Opening config [/home/zarthus/.znc/configs/znc.conf]...
[ >> ] ok
[ .. ] Loading global module [webadmin]...
[ >> ] [/home/zarthus/znc-build/lib/znc/webadmin.so]
[ .. ] Binding to port [+1111]...
[ >> ] ok
[ ** ] Loading user [zarthus]
[ ** ] Loading network [freenode]
[ .. ] Loading network module [garbage_module]...
[ !! ] Unable to find module [garbage_module]
[ ** ] Unable to find module [garbage_module]
[ ** ] Unrecoverable config error.

This would essentially solve upgrading issues with module changes from refusing znc to start up.

I don't think this should alter the config, just ignore the entries that ZNC cannot make sense of, or are refusing to load because they don't exist. A warning should be thrown, yes, but I do not believe it should be the be-all-end-all of starting up ZNC. Especially when considering upgrading, and that it does not seem to be that there are tools.

Most users would probably prefer a way to ignore the warning or have ZNC sort it out, than to manually edit the possibly overwhelming config of ZNC.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26917044-unrecoverable-config-error-when-a-module-no-longer-exists?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).

Based on #1119 - Mikaela brought up a valid point. What if users upgrade and their configuration is not up to date? I put the idea to test, and was confident ZNC would handle this manner in a clean and elegant way, perhaps something like "This module [no longer] seems to exist, ignoring this config entry". Perhaps with a prompt "Start ZNC anyways?" and a `--ignore-missing-modules` flag. ``` [ .. ] Checking for list of available modules... [ >> ] ok [ .. ] Opening config [/home/zarthus/.znc/configs/znc.conf]... [ >> ] ok [ .. ] Loading global module [webadmin]... [ >> ] [/home/zarthus/znc-build/lib/znc/webadmin.so] [ .. ] Binding to port [+1111]... [ >> ] ok [ ** ] Loading user [zarthus] [ ** ] Loading network [freenode] [ .. ] Loading network module [garbage_module]... [ !! ] Unable to find module [garbage_module] [ ** ] Unable to find module [garbage_module] [ ** ] Unrecoverable config error. ``` This would essentially solve upgrading issues with module changes from refusing znc to start up. I don't think this should alter the config, just ignore the entries that ZNC cannot make sense of, or are refusing to load because they don't exist. A warning should be thrown, yes, but I do not believe it should be the be-all-end-all of starting up ZNC. Especially when considering upgrading, and that it does not seem to be that there are tools. Most users would probably prefer a way to ignore the warning or have ZNC sort it out, than to manually edit the possibly overwhelming config of ZNC. ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26917044-unrecoverable-config-error-when-a-module-no-longer-exists?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:32:10 +02:00

Associated conversation in #znc-dev:

(11:01:41) <Zarthus> >When I upgrade from 1.4 to 1.7.0 or newer, will my ZNC start without issues or will it die to missing awaynick module?
(11:01:50) <Zarthus> I haven't tested, but if that makes znc straight up die I'd be surprised
(11:02:22) <Zarthus> let's see if i can mimic a config entry
(11:02:58) <Mikaela> at least in the past ZNC has died on start to not being able to load some module specified in config file.
(11:03:19) <Zarthus> that sounds more like a critical bug than something this pull request should worry about
(11:03:59) <Zarthus> but you're right
(11:04:00) <Zarthus> https://gist.github.com/Zarthus/3ae7314c2836b52e8549
(11:04:44) <Mikaela> and I believe this is why the boilerplate code was added.
(11:05:40) <Mikaela> I have seen requested on #znc for flag to ignore modules that aren't found which makes sense, but I don't want it default in case someone fails with compiling ZNC somehow and compiles it without modules, it's not nice if all modules of all users are unloaded

Associated conversation in `#znc-dev`: ``` (11:01:41) <Zarthus> >When I upgrade from 1.4 to 1.7.0 or newer, will my ZNC start without issues or will it die to missing awaynick module? (11:01:50) <Zarthus> I haven't tested, but if that makes znc straight up die I'd be surprised (11:02:22) <Zarthus> let's see if i can mimic a config entry (11:02:58) <Mikaela> at least in the past ZNC has died on start to not being able to load some module specified in config file. (11:03:19) <Zarthus> that sounds more like a critical bug than something this pull request should worry about (11:03:59) <Zarthus> but you're right (11:04:00) <Zarthus> https://gist.github.com/Zarthus/3ae7314c2836b52e8549 (11:04:44) <Mikaela> and I believe this is why the boilerplate code was added. (11:05:40) <Mikaela> I have seen requested on #znc for flag to ignore modules that aren't found which makes sense, but I don't want it default in case someone fails with compiling ZNC somehow and compiles it without modules, it's not nice if all modules of all users are unloaded ```

adam commented

2026-10-05 04:32:11 +02:00

perhaps with a prompt "Start ZNC anyways?"

How would this work with systemd unit or crontab? I prefer the other suggestion

and a --ignore-missing-modules flag

which could be mentioned in znc instead of the prompt.

Also my concern as I said on #znc-dev is I have seen requested on #znc for flag to ignore modules that aren't found which makes sense, but I don't want it default in case someone fails with compiling ZNC somehow and compiles it without modules, it's not nice if all modules of all users are unloaded.

And to add to my worry, it would be even worse for ZNC to write config file with no modules.

> perhaps with a prompt "Start ZNC anyways?" How would this work with systemd unit or crontab? I prefer the other suggestion > and a --ignore-missing-modules flag which could be mentioned in `znc` instead of the prompt. Also my concern as I said on #znc-dev is _I have seen requested on #znc for flag to ignore modules that aren't found which makes sense, but I don't want it default in case someone fails with compiling ZNC somehow and compiles it without modules, it's not nice if all modules of all users are unloaded._ And to add to my worry, it would be even worse for ZNC to write config file with no modules.

adam commented

2026-10-05 04:32:11 +02:00

How would this work with systemd unit or crontab? I prefer the other suggestion

I'm not sure if there's a solid way to detect if it's a user running the command or not, but the way I see it it's either prompting the user (which a lot of software does, separately offering a --no-interaction or --assume-yes flag (see --ignore-missing-modules in this case). Or ZNC flat out just erroring. In either case, ZNC would not start and the sysadmin would have to find out why.

which could be mentioned in znc instead of the prompt.

Do you mean the command znc? Are you expecting something like consider running znc with --ignore-missing-modules? I'm not entirely sure what you mean with this.

The way I see it, it's currently failing, and will still fail with my suggestion unless you explicitly tell it otherwise. It just avoids the user having to dive into the config.

> How would this work with systemd unit or crontab? I prefer the other suggestion I'm not sure if there's a solid way to detect if it's a user running the command or not, but the way I see it it's either prompting the user (which a lot of software does, separately offering a --no-interaction or --assume-yes flag (see --ignore-missing-modules in this case). Or ZNC flat out just erroring. In either case, ZNC would not start and the sysadmin would have to find out why. > which could be mentioned in znc instead of the prompt. Do you mean the command `znc`? Are you expecting something like `consider running znc with --ignore-missing-modules`? I'm not entirely sure what you mean with this. The way I see it, it's currently failing, and will still fail with my suggestion unless you explicitly tell it otherwise. It just avoids the user having to dive into the config.

adam commented

2026-10-05 04:32:12 +02:00

I mean instead of a prompt Start ZNC anyway? mention that it's possible to run ZNC with --ignore-missing-modules.

I'm not sure if there's a solid way to detect if it's a user running the command or not,

As far as I am aware there isn't and I fear cron would launch multiple instances of the prompt causing issues with resource usage in longer run.

Adding new flags for not running interactively is a big NO!, because people have always used crontabs and different initscripts and this change would break them. If there must be a new flag, make it --interactive instead, that wouldn't break anything.

I mean instead of a prompt _Start ZNC anyway?_ mention that it's possible to run ZNC with `--ignore-missing-modules`. > I'm not sure if there's a solid way to detect if it's a user running the command or not, As far as I am aware there isn't and I fear cron would launch multiple instances of the prompt causing issues with resource usage in longer run. Adding new flags for not running interactively is a big **NO!**, because people have always used crontabs and different initscripts and this change would break them. If there must be a new flag, make it `--interactive` instead, that wouldn't break anything.

adam commented

2026-10-05 04:32:13 +02:00

I'd probably argue the current behavior is the best behavior. This way, when a configuration file is loaded, the least amount of functionality is lost and there's no surprises. This is especially important in the case of third-party modules being used. If ZNC were to simply start up and skip the modules it can't load, that would reduce the amount of information in the configuration file.

That said, I wouldn't be opposed to a CLI argument to change this behavior. The use of such an argument would also mean the user would have to pass it explicitly, and thus be fully aware of the implications.

If implemented, I might also propose adding a warning about how the LoadModule entries would be removed from the configuration file when ZNC writes to it again as it periodically does. When that happens, ZNC would no longer attempt to load those modules the next time it starts up.

Ben (MrC @ Freenode)

I'd probably argue the current behavior is the best behavior. This way, when a configuration file is loaded, the least amount of functionality is lost and there's no surprises. This is especially important in the case of third-party modules being used. If ZNC were to simply start up and skip the modules it can't load, that would reduce the amount of information in the configuration file. That said, I wouldn't be opposed to a CLI argument to change this behavior. The use of such an argument would also mean the user would have to pass it explicitly, and thus be fully aware of the implications. If implemented, I might also propose adding a warning about how the LoadModule entries would be removed from the configuration file when ZNC writes to it again as it periodically does. When that happens, ZNC would no longer attempt to load those modules the next time it starts up. Ben (MrC @ Freenode)

adam commented

2026-10-05 04:32:13 +02:00

Perhaps with a prompt "Start ZNC anyways?"

I'm thinking of a poor sysadmin booting up an upgraded znc instance with a couple of hundreds of users. When would the "Start ZNC anyway?" prompt appear? After every error? -Frustrating. Only after first error? -Don't know what's coming up. After parsing the whole config? -Could have missed a bunch of errors.

and a --ignore-missing-modules flag.

Making it explicit, something like --ignore-module awaynick would be less error-prone ie. no accidentally lost modules.

> Perhaps with a prompt "Start ZNC anyways?" I'm thinking of a poor sysadmin booting up an upgraded znc instance with a couple of hundreds of users. When would the "Start ZNC anyway?" prompt appear? After every error? -Frustrating. Only after first error? -Don't know what's coming up. After parsing the whole config? -Could have missed a bunch of errors. > and a --ignore-missing-modules flag. Making it explicit, something like `--ignore-module awaynick` would be less error-prone ie. no accidentally lost modules.

adam commented

2026-10-05 04:32:14 +02:00

(21:18:42) <Zarthus> i'm considering two alternative appproaches
(21:19:43) <Zarthus> the first one is rather simple: if something gets deprecated, do something about it on bootup, and not on the LoadModule function
(21:20:19) <Zarthus> the second is some sort of config parser that receives an older version and a newer one and checks for possibly irrelevant things (like a LoadModule awaynick statement)
(21:20:59) <Zarthus> the problem with both of these is that it does not really "fix" the unrecoverable config error, but I'm starting to see more and more why it's unrecoverable to begin with
(21:21:55) <Zarthus> it seems to be the best approach there is to letting the user know znc needs help fixing something and is unable to determine the next step
(21:22:32) <Mikaela> while not becomimg interactive with cron & init scripts
(21:23:11) <Zarthus> i'm thinking of something that hooks in make install to parse the configuration then
(21:23:35) <Mikaela> and distribution packages?
(21:24:04) <MrC> And there might not be any config file before, or after "make install".
(21:24:10) <Zarthus> doesn't have to be make install, but znc could detect if it's the first run since an upgrade
(21:24:12) <Mikaela> and global installs too
(21:24:38) <Zarthus> we don't really care about new installs, they'll have an up-to-date config
(21:24:48) <Mikaela> first run after upgrade is detected as it starts by backing up the config file
(21:25:27) <Zarthus> great, so then perhaps we can move some of the legacy-loadmodule-logic into there and *fix* it rather than work around it
(21:25:55) <Zarthus> it might even be an idea to allow for znc administrators to run a 'verify-config' command of some sort to do it interactively while znc is running

``` (21:18:42) <Zarthus> i'm considering two alternative appproaches (21:19:43) <Zarthus> the first one is rather simple: if something gets deprecated, do something about it on bootup, and not on the LoadModule function (21:20:19) <Zarthus> the second is some sort of config parser that receives an older version and a newer one and checks for possibly irrelevant things (like a LoadModule awaynick statement) (21:20:59) <Zarthus> the problem with both of these is that it does not really "fix" the unrecoverable config error, but I'm starting to see more and more why it's unrecoverable to begin with (21:21:55) <Zarthus> it seems to be the best approach there is to letting the user know znc needs help fixing something and is unable to determine the next step (21:22:32) <Mikaela> while not becomimg interactive with cron & init scripts (21:23:11) <Zarthus> i'm thinking of something that hooks in make install to parse the configuration then (21:23:35) <Mikaela> and distribution packages? (21:24:04) <MrC> And there might not be any config file before, or after "make install". (21:24:10) <Zarthus> doesn't have to be make install, but znc could detect if it's the first run since an upgrade (21:24:12) <Mikaela> and global installs too (21:24:38) <Zarthus> we don't really care about new installs, they'll have an up-to-date config (21:24:48) <Mikaela> first run after upgrade is detected as it starts by backing up the config file (21:25:27) <Zarthus> great, so then perhaps we can move some of the legacy-loadmodule-logic into there and *fix* it rather than work around it (21:25:55) <Zarthus> it might even be an idea to allow for znc administrators to run a 'verify-config' command of some sort to do it interactively while znc is running ```

adam commented

2026-10-05 04:32:15 +02:00

Making it explicit, something like --ignore-module awaynick would be less error-prone ie. no accidentally lost modules.

And with this the config file would be written without awaynick? Sounds good to me except that it seems to only accept single module.

How about e.g. --ignore-modules awaynick q nickserv?

> Making it explicit, something like `--ignore-module awaynick` would be less error-prone ie. no accidentally lost modules. And with this the config file would be written without awaynick? Sounds good to me except that it seems to only accept single module. How about e.g. `--ignore-modules awaynick q nickserv`?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#596