Give a module argument in znc.conf so that the module returns false in OnLoad.
Execute /znc rehash to make znc re-read the configuration.
rehash fails since a module returned false in OnLoad.
Give a new argument for the module in znc.conf so that the module returns true in OnLoad.
Try either 5) or 6) in any order.
execute /znc updatemod "module", and updatemod succeeds, but the module is not really updated.
execute /znc rehash, and rehash succeeds, but the module is not really updated.
Here is an example.
When Module "A" receives 1 or 2 as argument, it returns true in OnLoad.
When Module "B" receives 3 as argument, it returns false in OnLoad.
You initially had LoadModule = A 1
You changed it to LoadModule = A 3, and rehashed.
Rehash fails.
After you change it to LoadModule = A 2, either "/znc rehash A" or "/znc updatemod A" fails to make A accept "2".
1) Give a module argument in znc.conf so that the module returns false in OnLoad.
2) Execute /znc rehash to make znc re-read the configuration.
3) rehash fails since a module returned false in OnLoad.
4) Give a new argument for the module in znc.conf so that the module returns true in OnLoad.
Try either 5) or 6) in any order.
5) execute /znc updatemod "module", and updatemod succeeds, but the module is not really updated.
6) execute /znc rehash, and rehash succeeds, but the module is not really updated.
Here is an example.
When Module "A" receives 1 or 2 as argument, it returns true in OnLoad.
When Module "B" receives 3 as argument, it returns false in OnLoad.
You initially had LoadModule = A 1
You changed it to LoadModule = A 3, and rehashed.
Rehash fails.
After you change it to LoadModule = A 2, either "/znc rehash A" or "/znc updatemod A" fails to make A accept "2".
<!-- github-sync-id:2920340 -->
ZNC is already running. I add "LoadModule = dcc" to an user that is NOT admin and do pkill -HUP znc:
[ !! ] Loading Module [dcc]... [ Module [dcc] aborted: You must be admin to use the DCC module ]
[ ** ] Module [dcc] aborted: You must be admin to use the DCC module
I make the user an admin again, pkill -HUP znc and:
[ ok ] Loading Module [dcc]... [./modules/extra/dcc.so]
The issue is not just with modules, but somehow the user's seem to get leaked. Existing clients will use the some old CUser object, but new clients will get a different CUser object.
From a breakpoint in "get RealName tesa" after the user lookup we can see the current user != the tesa user.
(gdb) p pUser
$2 = (CUser *) 0x7fffffffc3b0
(gdb) p m_pUser
$3 = (CUser *) 0xb93800
A new user seems to created from the config in some cases when we rehash, instead the old user should be updated.
The issue is not just with modules, but somehow the user's seem to get leaked. Existing clients will use the some old CUser object, but new clients will get a different CUser object. 
From a breakpoint in "get RealName tesa" after the user lookup we can see the current user != the tesa user.
```
(gdb) p pUser
$2 = (CUser *) 0x7fffffffc3b0
(gdb) p m_pUser
$3 = (CUser *) 0xb93800
```
A new user seems to created from the config in some cases when we rehash, instead the old user should be updated.
<!-- github-comment-id:3697628 -->
@crocket could you please try to reproduce the issues you are having with the latest master branch. This should hopefully fix these issues.
@crocket could you please try to reproduce the issues you are having with the latest master branch. This should hopefully fix these issues.
<!-- github-comment-id:3812444 -->
rehashing doesn't lead to segmentation fault as it did when one or more of networks had IRCConnectEnabled set to yes.
But the original issue still remains.
After rehash fails, even webadmin fails to load or unload modules.
@kylef // I built the latest master branch.
rehashing doesn't lead to segmentation fault as it did when one or more of networks had IRCConnectEnabled set to yes.
But the original issue still remains.
After rehash fails, even webadmin fails to load or unload modules.
<!-- github-comment-id:3842688 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Give a module argument in znc.conf so that the module returns false in OnLoad.
Execute /znc rehash to make znc re-read the configuration.
rehash fails since a module returned false in OnLoad.
Give a new argument for the module in znc.conf so that the module returns true in OnLoad.
Try either 5) or 6) in any order.
execute /znc updatemod "module", and updatemod succeeds, but the module is not really updated.
execute /znc rehash, and rehash succeeds, but the module is not really updated.
Here is an example.
When Module "A" receives 1 or 2 as argument, it returns true in OnLoad.
When Module "B" receives 3 as argument, it returns false in OnLoad.
You initially had LoadModule = A 1
You changed it to LoadModule = A 3, and rehashed.
Rehash fails.
After you change it to LoadModule = A 2, either "/znc rehash A" or "/znc updatemod A" fails to make A accept "2".
This bug doesn't exist but only for my module.
I'm going to close it.
It happens with another sample module on the latest git version I compiled yesterday.
So I'm reopening it.
ZNC is already running. I add "LoadModule = dcc" to an user that is NOT admin and do pkill -HUP znc:
I make the user an admin again, pkill -HUP znc and:
Rehash says module was loaded, but:
11:02:56 < *status> User modules:
11:02:56 < *status> +------------+-----------+
11:02:56 < *status> | Name | Arguments |
11:02:56 < *status> +------------+-----------+
11:02:56 < *status> | bouncedcc | |
11:02:56 < *status> | notes | |
11:02:56 < *status> | admin | |
11:02:56 < *status> | autoattach | |
11:02:56 < *status> | perform | |
11:02:56 < *status> | autocycle | |
11:02:56 < *status> +------------+-----------+
11:02:56 < *status> Network modules:
11:02:56 < *status> +---------------+-----------+
11:02:56 < *status> | Name | Arguments |
11:02:56 < *status> +---------------+-----------+
11:02:56 < *status> | route_replies | |
11:02:56 < *status> | nickserv | |
11:02:56 < *status> +---------------+-----------+
Also. this user isn't an admin, because:
11:01:48 < *status> Unknown command [updatemod] try 'Help'
So sounds like rehashing is broken in general?
The issue is not just with modules, but somehow the user's seem to get leaked. Existing clients will use the some old CUser object, but new clients will get a different CUser object.
From a breakpoint in "get RealName tesa" after the user lookup we can see the current user != the tesa user.
A new user seems to created from the config in some cases when we rehash, instead the old user should be updated.
If any network has IRCConnectEnabled set to true in znc.conf, when you rehash,
the following segmentation fault is caused.
(crocket/freenode) CLI -> ZNC [znc rehash]
[ ok ] Opening Config [/etc/znc/configs/znc.conf]...
[ ** ] Module [partyline] already loaded.
[ ** ] Module [webadmin] already loaded.
[ ok ] Binding to port [+1491]...
[ ** ] Loading user [crocket]
[ ok ] Loading Module [simple_away]... [/usr/lib64/znc/simple_away.so]
[ ok ] Loading Module [route_replies]... [/usr/lib64/znc/route_replies.so]
[ ok ] Loading Module [replaybuffer]... [/usr/lib64/znc/replaybuffer.so]
[ ok ] Adding Server [efnet.xs4all.nl +6697]...
[ ok ] Adding Server [irc.he.net +6697]...
[ ok ] Loading Module [simple_away]... [/usr/lib64/znc/simple_away.so]
[ ok ] Loading Module [nickserv]... [/usr/lib64/znc/nickserv.so]
[ ok ] Loading Module [route_replies]... [/usr/lib64/znc/route_replies.so]
[ ok ] Loading Module [replaybuffer]... [/usr/lib64/znc/replaybuffer.so]
[ ok ] Adding Server [irc.freenode.net +6697]...
[ ok ] Loading Module [perform]... [/usr/lib64/znc/perform.so]
[ ok ] Loading Module [simple_away]... [/usr/lib64/znc/simple_away.so]
[ ok ] Loading Module [route_replies]... [/usr/lib64/znc/route_replies.so]
[ ok ] Loading Module [replaybuffer]... [/usr/lib64/znc/replaybuffer.so]
[ ok ] Adding Server [apink.hanirc.org 8080]...
[ ok ] Loading Module [nickserv]... [/usr/lib64/znc/nickserv.so]
[ ok ] Loading Module [replaybuffer]... [/usr/lib64/znc/replaybuffer.so]
[ ok ] Loading Module [route_replies]... [/usr/lib64/znc/route_replies.so]
[ ok ] Loading Module [simple_away]... [/usr/lib64/znc/simple_away.so]
[ ok ] Adding Server [irc.oftc.net +6697]...
[ ok ] Loading Module [replaybuffer]... [/usr/lib64/znc/replaybuffer.so]
[ ok ] Loading Module [route_replies]... [/usr/lib64/znc/route_replies.so]
[ ok ] Loading Module [simple_away]... [/usr/lib64/znc/simple_away.so]
[ ok ] Adding Server [ssl.ozinger.org +16667]...
[ ok ] Loading Module [simple_away]... [/usr/lib64/znc/simple_away.so]
[ ok ] Loading Module [route_replies]... [/usr/lib64/znc/route_replies.so]
[ ok ] Loading Module [replaybuffer]... [/usr/lib64/znc/replaybuffer.so]
[ ok ] Adding Server [irc.ph2network.org +6697]...
[ ok ] Loading Module [simple_away]... [/usr/lib64/znc/simple_away.so]
[ ok ] Loading Module [route_replies]... [/usr/lib64/znc/route_replies.so]
[ ok ] Loading Module [replaybuffer]... [/usr/lib64/znc/replaybuffer.so]
[ ok ] Adding Server [irc.rizon.net +6697]...
[ ok ] Loading Module [admin]... [/usr/lib64/znc/admin.so]
[ ok ] Loading Module [bouncedcc]... /usr/lib64/znc/bouncedcc.so ZNC -> CLI [:*status!znc@znc.in PRIVMSG crocket :Rehashing succeeded!]
Connecting user/network [..sogaH�Sn��Lt����/etc/znc/users/crocket/networks/rizon/moddata/simple_away/.registryy5;2c%23;5%0a;mode%20;%25;nick%25;%20;%2b;x%0a;�{���Sn���Sn��{��Sn�����Perform PRIVMSG%20;%5e;%5e;%20;%3a;%ec;%9d;%b8;%ec;%a6;%9d;%20;crocket%20;Sok3%25;2c%23;5%0a;mode%20;%25;nick%25;%20;%2b;x%0a;h�y``�{4����Send replies (e.g. to /who) to the right client only_away/.regi�Pv{��Sn��{x�y@{@{p{p{�
t�s�Lt�{8�z��y�{X��n�(�y��r�{�{@{@{�{�{X��n��{<����/etc/znc/users/crocket/networks/hanirc/moddata/route_repliesa`{;����/etc/rc.d/rc.znc: line 24: 12316 Segmentation fault sudo -u $ZNC_USER -i /usr/bin/znc --datadir /etc/znc -D -f@crocket could you please try to reproduce the issues you are having with the latest master branch. This should hopefully fix these issues.
@kylef // I built the latest master branch.
rehashing doesn't lead to segmentation fault as it did when one or more of networks had IRCConnectEnabled set to yes.
But the original issue still remains.
After rehash fails, even webadmin fails to load or unload modules.
Maybe I should close this issue. Using webadmin is probably the solution.