View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005508unrealircdpublic2019-12-25 14:312020-03-29 09:13
Reporterj4son Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilityunable to reproduce
Status resolvedResolutionno change required 
Product Version5.0.0 
Summary0005508: anope sometimes mass deops/unsets in +P channels
DescriptionWe have had two networks who had this by now. It seems to involve +P channels somehow.

See additional details for logs.
Additional InformationOn unrealircd's network, running 5.0.0-rc2 on Dec 11 2019:
16:56 -!- mode/#channel [+s] by User1
16:57 -!- mode/#channel [+H 10:1440] by Syzop
16:58 -!- mode/#channel [+P] by Syzop
16:58 -!- mode/#channel [+i] by Syzop
16:59 -!- mode/#channel [+I ~a:Syzop] by Syzop
16:59 -!- mode/#channel [+I ~a:User1] by Syzop
16:59 -!- mode/#channel [+I ~a:i] by Syzop
13:06 -!- User2 [..] has quit [Ping timeout: 180 seconds]
13:07 -!- User2 [..] has joined #channel
13:07 -!- ServerMode/#channel [-sntirHP] by services.unrealircd.org
13:07 -!- ServerMode/#channel [-bbbbIIIqoao ~T:block:*Build*unreal5-win*Success* ~T:block:*Build*unreal5-fbsd*Success* ~T:block:*Build*unreal5-deb*Success* ~T:block:*build*started* ~a:i ~a:User1 ~a:Syzop Syzop Syzop User1 User1] by services.unrealircd.org
13:07 -!- ServerMode/#channel [+sntirPH 10:1440] by services.unrealircd.org
13:07 -!- mode/#channel [+aoaoqo User2 User2 User1 User1 Syzop Syzop] by ChanServ


Someone else had this with 5.0.0:
...unknown events here...
[13:27:02] * @User1 (..) Quit (Quit: ZNC 1.7.5)
[13:35:36] -example.org:@#channel- owner invited User1 into the channel.
[13:35:36] * User1 (..) has joined #channel
[13:35:36] * services.example.org sets mode: -sntirPk keykey
[13:35:36] * services.example.org sets mode: -qooooooooooo <lots of people here>
[13:35:36] * services.example.org sets mode: -ooooo <more people here>
[13:35:36] * services.example.org sets mode: +sntirPk keykey
[13:35:36] * ChanServ sets mode: +qo owner owner
[13:35:37] * owner sets mode: +o User1

And again in a different channel:
[13:27:02] * @User1 (...) Quit (Quit: ZNC 1.7.5 - https://znc.in)
[13:28:56] <@User2> [INVITE] .. invited himself as Owner
[13:35:48] -example.org:@#otherchannel- Hostess invited User1 into the channel.
[13:36:02] * User1 (...) has joined #otherchannel
[13:36:02] * services.example.org sets mode: -sntirPk keykey
[13:36:02] * services.example.org sets mode: -oooooqo <lots of people>
[13:36:02] * services.example.org sets mode: +sntirPk keykey
[13:36:02] * ChanServ sets mode: +qo Owner Owner
[13:36:02] * Owner sets mode: +o User1
[13:37:40] * Owner sets mode: +ooooo User2 User3 User4 User5 User6
TagsNo tags attached.
3rd party modules

Activities

syzop

2019-12-25 15:11

administrator   ~0021173

Both networks are now running anope in debug mode. We'll see if it triggers again and will post logs here.

syzop

2020-01-02 17:59

administrator   ~0021194

Last edited: 2020-01-02 17:59

 Hi, just checking: you have not seen it again right? With anope in debug mode? I plan to release UnrealIRCd 5.0.1 tomorrow or the day after.

j4son

2020-01-03 07:31

reporter   ~0021202

Hi, since anope is running in debug mode it did not happen again. I think maybe it happens only after restarting the ircd. We will see what happens after updating to 5.0.1

syzop

2020-01-05 09:33

administrator   ~0021204

Same here.. still nothing. Actually anope restarted via cron so I had to set it manually to debug mode again with /OS SET DEBUG ON. We'll see.

If anything, it seems that the issue happens extremely rarely it seems. I suppose that is good, but it also makes it hard to trace it down.

j4son

2020-01-25 12:53

reporter   ~0021254

After upgrading to unreal 5.0.2 nothing new. Services are still in debug mode. But it did not happen after upgrading and restarting the ircd.

I will keep an eye on it.

syzop

2020-01-26 10:04

administrator   ~0021263

Same here. No changes. No additional reports from others either.

I have set this bug to 'feedback' since we need services logs from you or me when this happens, otherwise it is unlikely to find the cause of this bug.

syzop

2020-03-29 09:02

administrator   ~0021389

Now a public bug report, all sensitive (read: network-specific) information has been removed.

syzop

2020-03-29 09:13

administrator   ~0021390

I have looked into this and it seems this behavior in anope is by design. This happens if the TS (timestamp, creation time) of the channel stored in services is lower than the current TS of the channel. Anope will then update the TS (creation time) to the lower value (eg a timestamp from 2018 in my case). The slightly confusing part is that it will only do this once there is a mode that needs to be changed, eg when someone needs to receive chanops, unless you have always_lower_ts set to true, which is not the default (it is false by default).
This actually happens for non +P channels as well, but then it is a first join and is considered normal and we are all used to it. It just "looks" differently for +P channels now that we have channeldb. And, as said, the delaying until some channel mode needs to be changed leads to it happening minutes or hours (in my case even days) after services are linked in.

The good news is that this should only happen ONCE for each +P channel, IF it happens at all. And it doesn't happen in like 99% of the cases because the channel TS is already the same as the one in services. So yeah, it indeed RARE.

I say once, but I fixed a bug in channeldb which meant it didn't restore +P settings properly after an ircd server restart. So if you restarted ALL your IRC servers at once then anope might still do the same behavior again for the same +P channel. On bigger networks this may not be very likely to happen, but on single server (or two-server) networks it is quite possible.

So yeah this can be closed. And before anyone asks: no, anope is not doing anything wrong either, in my opinion. This is just.. how it is.

Issue History

Date Modified Username Field Change
2019-12-25 14:31 syzop New Issue
2019-12-25 14:31 syzop Additional Information Updated
2019-12-25 14:34 syzop Additional Information Updated
2019-12-25 14:38 syzop Additional Information Updated
2019-12-25 14:38 syzop Additional Information Updated
2019-12-25 15:05 syzop Reporter syzop => j4son
2019-12-25 15:05 syzop Additional Information Updated
2019-12-25 15:11 syzop Note Added: 0021173
2019-12-25 15:11 syzop Status new => feedback
2019-12-25 15:11 syzop Status feedback => confirmed
2020-01-02 17:59 syzop Note Added: 0021194
2020-01-02 17:59 syzop Note Edited: 0021194
2020-01-03 07:31 j4son Note Added: 0021202
2020-01-05 09:33 syzop Note Added: 0021204
2020-01-25 12:53 j4son Note Added: 0021254
2020-01-26 10:04 syzop Assigned To => syzop
2020-01-26 10:04 syzop Status confirmed => feedback
2020-01-26 10:04 syzop Note Added: 0021263
2020-03-29 09:02 syzop View Status private => public
2020-03-29 09:02 syzop Note Added: 0021389
2020-03-29 09:13 syzop Status feedback => resolved
2020-03-29 09:13 syzop Resolution open => no change required
2020-03-29 09:13 syzop Note Added: 0021390