View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005508||unreal||ircd||public||2019-12-25 14:31||2020-03-29 09:13|
|Priority||normal||Severity||major||Reproducibility||unable to reproduce|
|Status||resolved||Resolution||no change required|
|Summary||0005508: anope sometimes mass deops/unsets in +P channels|
|Description||We have had two networks who had this by now. It seems to involve +P channels somehow.|
See additional details for logs.
|Additional Information||On 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
|Tags||No tags attached.|
|3rd party modules|
||Both networks are now running anope in debug mode. We'll see if it triggers again and will post logs here.|
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.
||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|
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.
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.
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.
||Now a public bug report, all sensitive (read: network-specific) information has been removed.|
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.
|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|