Ed. note: The following are 2 email messages from Richard Hecker, an EFnetoper and experienced IRC helper, on the subject of server desynchronizationsor “desyncs.” It gets fairly technical but it’s really the only way tounderstand and fix this annoying phenomenon. To make things worse, the /namestrick he mentions no longer works on most EFnet servers, so you’ll have torely on good ol’ fashioned deductive reasoning to figure out where the desyncis.
Wed, 8 Apr 1998 11:44:45 -0400
Richard Hecker
On Wed, 1 Apr 1998, The Rose wrote:
I’m wondering what the trick/tricks are for resynching achannel? I’ve never had any luck with attempting it. I’vetried the -o +o stuff, have had chanops try that also, noworkee.
Resyncing a channel is relatively simple if you understand desyncs. A desyncis a condition in which different servers have conflicting information. Withchannel desyncs, they usually start with someone that has ops, but only someservers see that user as being opped. Once that happens, its easy for thedesync to escalate. If that desynced person ops someone else, that new op willalso have desynced ops. If a desynced op kickbans another user, often only theservers that see that person as being opped will allow the ban to be placed,and the kick to go through. At that point, servers have conflicting lists ofops, conflicting lists of bans, and conflicting lists of users on the channel.
So, to fix this all, its usually a matter of finding where the desync is,getting clients on either side of it, and manually making changes on bothsides until they have the exact same information.
Finding the location of the desync will often be helpful. One easy trick is togo into the channel, get ops, and set the topic. If your ops are desynced, youwill receive error messages about not being opped from the servers that don’tsee you as having ops. That doesn’t always work. If that doesn’t work, Iusually paste the/names list to the channel, and ask if anyone sees anythingdifferent from where they are. Usually, finding one server that you haveaccess to that is on the other side of the desync will be enough to allow youto fix it.
[ Note - the following script commands are for the UNIX ircII client only. ]
Here’s a good alias to have handy:
alias usr names $C $*
I use this all the time instead of /NAMES. typing /USR is equivalent to doing/names * ….But there’s an added bonus to this command, and you need this/ON command to appreciate it:
on ^353 "*" if ([$0] == [$S]) {echo Users on $2: $3-} {echo Users on $2: $3-\(from $0\)}(It should all be on one line, BTW)
Here’s the trick…With that /usr command, you can ask other servers to giveyou the list of people on the channel. The /ON command I’ve included allowsyou to easily differentiate between /NAMES responses from your server, andresponses from other servers. Here’s how it looks when I use this command:
/usr
Users on #irchelp: @Trillian @turtle @wmono @Jolo @ApatrixEM @Davin+@DemiShade @MHz @Garfr
/usr *hut.fi
Users on #irchelp: @Trillian @MHz @Garfr @turtle @wmono @Jolo @ApatrixEM+@Davin @DemiShade (from efnet.cs.hut.fi)
/usr larz
Users on #irchelp: @Trillian @turtle @wmono @Jolo @ApatrixEM @Davin+@DemiShade @MHz @Garfr (from irc.blackened.com)
Notice in the last case that I can even name a user instead of a server toquery. In that case, it asked larz’s server (blackened) for the user list.
Using this command will allow you to track down info on the desync withouthopping from server to server. Once you know which servers are desynced, youcan get a client on either side and fix it. But you MUST have ops on BOTHsides to properly fix it. Then its just a matter of comparing user lists (deopand reop anyone who isn’t opped on both sides, and kick out anyone who doesn’tappear onchannel on both sides), ban lists (remove and replace any bans thatdon’t appear on both sides), and channel modes (remove and replace any modesthat are desynced).
What if you don’t have ops on both sides? Then you’re pretty screwed. Itsusually impossible to get everyone out of the channel. The best advice is toresync as much as you can, and pray for a well placed netsplit. Depending onwhere the split occurs, the rejoin may resync the channel for you. Usually itonly partially resyncs it, but often its enough of a resync to be able tofinish the job manually.
Purely for interest’s sake, I may as well mention that channels aren’t theonly things that get desynced. Users can get desynced, too. The most commonuser desync happens when a user leaves, but not all servers receive the updatethat the user is gone. This is what a Ghost is.
Hope that helps
-Rich
Thu, 9 Apr 1998 09:24:23 -0400
Richard Hecker
On Wed, 8 Apr 1998, The Rose wrote:
Exiting the channel left it empty, therefore non-existant. When Iwent back into it it was STILL desyched. I kid you not. I was theonly one on it, too. I got onto various servers and kept going inand out, no matter what server I was on I’d be the only one inthe channel and it was desyched. I must have played around for 20
Some of the stranger desyncs can do some odd stuff, but whenever theres adesync, there’s a server somewhere that thinks users are on it, and thatserver may not give you any error messages.
I was once called into a channel where mode changes just weren’t going throughright. When people opped other people, some users would see it, and somewouldnt. I checked almost every server that users in the channel were on, andevery server I checked seemed to agree on who had ops, and yet, when ops wouldop people, only about half of the servers saw it. I was rather stumped atthis, and I finally decided to get a/TRACE between two servers where thisrift seemed to exist, and check every server between them.
As it turns out, there was a single hub server along the path that wasconvinced that there were no ops at all in the channel. But every otherserver, on either side of this hub server, had the correct opslist, and forsome reason, this hub server wasnt producing any errors.
Anyway, theres always a clue somewhere, its just not always obvious where tolook…
-Rich