Awaynick is not used after disconnection from IRC #31

New Issue

2026-10-05T03:54:46+02:00

adam commented

2026-10-05 03:54:46 +02:00

I have my awaynick set and it works great when I disconnect from znc. However if I disconnect from znc and then znc gets disconnected from IRC...when it reconnects it does not use my awaynick. It would be nice to have znc always use my away nick when I'm disconnected from my znc even after a disconnection from IRC.

I have my awaynick set and it works great when I disconnect from znc. However if I disconnect from znc and then znc gets disconnected from IRC...when it reconnects it does not use my awaynick. It would be nice to have znc always use my away nick when I'm disconnected from my znc even after a disconnection from IRC.

adam closed this issue

2026-10-05 03:54:46 +02:00

adam commented

2026-10-05 03:54:48 +02:00

What ZNC version?
Also please paste output of /znc listmodules

What ZNC version? Also please paste output of /znc listmodules

adam commented

2026-10-05 03:54:48 +02:00

znc --version
ZNC 0.200-1.el6 - http://znc.in

adam commented

2026-10-05 03:54:49 +02:00

I've got the same issue. Not very handy that people think you're on, when you're not.

I'm running

version: ZNC 0.200-0.5.rc1.el5

modules loaded:

*status: | keepnick  |                        |
*status: | chansaver |                        |
*status: | awaynick  | WanWizard|away         |
*status: | autoreply | I'm away from my desk. |
*status: | nickserv  |                        |
*status: +-----------+------------------------+

adam commented

2026-10-05 03:54:50 +02:00

This appears to work fine for me, I cannot reproduce this:

[01:22:58] *** REMOTENICK: User zynox changed their nickname to zz_zynox
[01:23:27] *** REMOTEKILL: Remote kill by kylef: zz_zynox!efnet@localhost (testing)
[01:23:27] *** REMOTEQUIT: Client exiting on server arc.darkscience.ws: zz_zynox!efnet@localhost [Killed (kylef (testing))] (0::1)
[01:23:29] *** REMOTECONNECT: Client connecting at arc.darkscience.ws: zz_zynox!efnet@localhost [0::1] [efnet - ZNC]

Please re-open if anyone can reproduce this.

This appears to work fine for me, I cannot reproduce this: ``` [01:22:58] *** REMOTENICK: User zynox changed their nickname to zz_zynox [01:23:27] *** REMOTEKILL: Remote kill by kylef: zz_zynox!efnet@localhost (testing) [01:23:27] *** REMOTEQUIT: Client exiting on server arc.darkscience.ws: zz_zynox!efnet@localhost [Killed (kylef (testing))] (0::1) [01:23:29] *** REMOTECONNECT: Client connecting at arc.darkscience.ws: zz_zynox!efnet@localhost [0::1] [efnet - ZNC] ``` Please re-open if anyone can reproduce this.

adam commented

2026-10-05 03:54:50 +02:00

And try to unload keepnick, their purposes kinda contradict with each other.

And try to unload keepnick, their purposes kinda contradict with each other.

adam commented

2026-10-05 03:54:51 +02:00

I unloaded keepnick some time ago, but that doesn't make any difference.

I have the feeling it has something to do with having an authenticated connection. When ZNC reconnects, the old connection is still there (I guess freenode hasn't timed it out yet), awaynick will try to set the nick, which fails because the nick in already present in the channel...

Is there a way to debug it? Can I log this chain of events somewhere? It usually happens when I'm not around, and find out later that ZNC had me reconnected to the channel without my away nick, and people complain that I don't respond...

I unloaded keepnick some time ago, but that doesn't make any difference. I have the feeling it has something to do with having an authenticated connection. When ZNC reconnects, the old connection is still there (I guess freenode hasn't timed it out yet), awaynick will try to set the nick, which fails because the nick in already present in the channel... Is there a way to debug it? Can I log this chain of events somewhere? It usually happens when I'm not around, and find out later that ZNC had me reconnected to the channel without my away nick, and people complain that I don't respond...

adam commented

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

This would be the case if the nickname is in use.

(kylef/darkscience) ZNC -> IRC [NICK zz_kylef]
(kylef/darkscience) ZNC -> IRC [USER efnet "efnet" "efnet" :efnet - ZNC]
(kylef/darkscience) IRC -> ZNC [:sprnt.darkscience.ws 433 * zz_kylef :Nickname is already in use.]
(kylef/darkscience) ZNC -> IRC [NICK kylef_]
(kylef/darkscience) IRC -> ZNC [:sprnt.darkscience.ws 001 kylef_ :Welcome to the darkscience IRC Network]

Perhaps we can check OnQuit for the away nick we want. Then change if that nick quit's IRC. Similar to how keepnick works.

diff --git a/modules/awaynick.cpp b/modules/awaynick.cpp
index fcd94a4..a7c8800 100644
--- a/modules/awaynick.cpp
+++ b/modules/awaynick.cpp
@@ -104,6 +104,13 @@ public:
                return CONTINUE;
        }

+       void OnQuit(const CNick& Nick, const CString& sMessage, const vector<CChan*>& vChans) {
+               if (!m_pNetwork->IsUserAttached() && Nick.GetNick() == GetAwayNick() &&
+                               !FindTimer("AwayNickTimer")) {
+                       StartAwayNickTimer();
+               }
+       }
+
        virtual void OnIRCDisconnected() {
                RemTimer("AwayNickTimer");
                RemTimer("BackNickTimer");

The only downside, is that if our awaynick contains %nick% it might be based on the altnick instead, so the away nick will be different. In my testing this code didn't work because I was using an alt-nick and my away nick would be zz_kylef_ not zz_kylef like the person who just quit.

This would be the case if the nickname is in use. ``` (kylef/darkscience) ZNC -> IRC [NICK zz_kylef] (kylef/darkscience) ZNC -> IRC [USER efnet "efnet" "efnet" :efnet - ZNC] (kylef/darkscience) IRC -> ZNC [:sprnt.darkscience.ws 433 * zz_kylef :Nickname is already in use.] (kylef/darkscience) ZNC -> IRC [NICK kylef_] (kylef/darkscience) IRC -> ZNC [:sprnt.darkscience.ws 001 kylef_ :Welcome to the darkscience IRC Network] ``` Perhaps we can check OnQuit for the away nick we want. Then change if that nick quit's IRC. Similar to how keepnick works. ``` diff --git a/modules/awaynick.cpp b/modules/awaynick.cpp index fcd94a4..a7c8800 100644 --- a/modules/awaynick.cpp +++ b/modules/awaynick.cpp @@ -104,6 +104,13 @@ public: return CONTINUE; } + void OnQuit(const CNick& Nick, const CString& sMessage, const vector<CChan*>& vChans) { + if (!m_pNetwork->IsUserAttached() && Nick.GetNick() == GetAwayNick() && + !FindTimer("AwayNickTimer")) { + StartAwayNickTimer(); + } + } + virtual void OnIRCDisconnected() { RemTimer("AwayNickTimer"); RemTimer("BackNickTimer"); ``` The only downside, is that if our awaynick contains %nick% it might be based on the altnick instead, so the away nick will be different. In my testing this code didn't work because I was using an alt-nick and my away nick would be `zz_kylef_` not `zz_kylef` like the person who just quit.

adam commented

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

Thanks for looking into this!

Thanks for looking into this!

adam commented

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

That won't work, if away nick will timeout between our initial connection and our joining the first channel.

That won't work, if away nick will timeout between our initial connection and our joining the first channel.

adam commented

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

Perhaps we could just StartAwayNickTimer on connect and we are away. Then it will try it again when the timer has elapsed?

Perhaps we could just `StartAwayNickTimer` on connect and we are away. Then it will try it again when the timer has elapsed?

adam commented

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

👍

I use "Krinkle|detached" as awaynick. But when for some reason ZNC got disconnected while I was away, it re-connects as my normal nickname as opposed to the "detached" state.

One thing to consider (though both will be the same in most cases) is whether this should be enforced from within "awaynick" (e.g. set away nick when re-connecting, unless/until a client connects) - or to do it from "core" (remember nick from before disconnect - which can be the "awaynick" nick - and use that when connecting).

I think connecting clean with default nick (and letting awaynick set the awaynick right away, if appropiate) is preferred. That way if both get disconnected (znc first; which is not unlikely, depending on what caused the disconnect), it will be connecting correctly (with the awaynick set, even though the state right before disconnect was not "away") - until the client also reconnects, in which case awaynick will naturally restore the default nick again.

:+1: I use "`Krinkle|detached`" as awaynick. But when for some reason ZNC got disconnected while I was away, it re-connects as my normal nickname as opposed to the "detached" state. One thing to consider (though both will be the same in most cases) is whether this should be enforced from within "awaynick" (e.g. set away nick when re-connecting, unless/until a client connects) - or to do it from "core" (remember nick from before disconnect - which can be the "awaynick" nick - and use that when connecting). I think connecting clean with default nick (and letting awaynick set the awaynick right away, if appropiate) is preferred. That way if both get disconnected (znc first; which is not unlikely, depending on what caused the disconnect), it will be connecting correctly (with the awaynick set, even though the state right before disconnect was not "away") - until the client also reconnects, in which case awaynick will naturally restore the default nick again.

adam commented

2026-10-05 03:54:55 +02:00

With awaynick module removed, this issue is obsolete.

With awaynick module removed, this issue is obsolete.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#31