Anope IRC Services
Anope Support => 1.8.x/1.7.x Support (Read Only) => Topic started by: T-rexke on June 09, 2006, 04:58:13 PM
-
hi wth is this strange error i never had it before until to day :)
[17:40] * services.ChatPlekkiej.net sets mode: -ntr
does anybody know the answer?
-
does nobody know the anser?
-
the channel was dropped ?.... there are enough possible reason why services would do that, with the info you provide it s impossible to speak of an error...
-
If this is the same as the problem i had what's happening is he is entering an empty, registered channel, ChanServ is setting the modes, an assigned bot is entering the channel then the modes are unset apparently by the services server.
Then if you leave the channel and rejoin it the same happens again.
-
This happens to me too.... but only in channels where there is a bot server bot assigned.
-
I can't duplicate this at all.
.:16:14:. * Now talking in #katsklaw
.:16:14:. * ChanServ sets mode: +nrt
.:16:14:. * ChanServ changes topic to ''
.:16:14:. * Joins: kats-bot (katsklaw@litter.box)
.:16:14:. * kats-bot sets mode: +o kats-bot
registered channel, kats-bot is a services bot ... I join the empty channel #katsklaw .. everything is normal.
What version of Anope?
What ircd?
what is the mlock listed in: /cs info #channel all
-
Unreal3.2.4
Anope-1.7.14 (1023)
-ChanServ- Mode lock: +nrt
If the first person joining is an services/net admin (need to check what all ranks it works for) it works fine the problem happens only when a normal user join an empty channel where a bot server bot is assigned
-
this is wat he does when i join
[09:55] * Now talking in #chatplekkiej
[09:55] * ChanServ sets mode: +ntr
[09:55] * ChanServ changes topic to 'Hoofdroom van deze server | Voor Vragen Join #help | typ /motd voor de motd [CP Beta online: http://www.chat-web.nl/site !] (T-rexke)'
[09:55] * services.ChatPlekkiej.net sets mode: -ntr
[09:55] * services.ChatPlekkiej.net sets mode: -o T-rexkeand right after that the service bot joins
[bewerken aan 11-6-2006 door T-rexke]
-
Thats what i was getting. The only way i tried which worked to fix it was to move services to another server on my network. That was with restoring the previous databases as they were on the previous server so that would suggest it isnt a database problem.
-
Im guessing your clocks are way differnt, and it's seeing the join before it thinks the channel was ever created, as such, it takes the modes away.
Sync your clocks.
-
Saying that this only started for me i installed an NTP client to automatically sync the time on my server. As i understand the IRCd maintains its own clock based on the time of the system at startup but Anope uses the system clock throughout. So if the system clock was re-sync'ed that would mean there would be a difference between the 2 even if on the same computer.
[Edited on 11-6-2006 by Jobe1986]
-
hm now it sets the modes but if i hop the modes are gone again and if i hop a couple of times the modes are back until i hop again :S
[bewerken aan 11-6-2006 door T-rexke]
-
Since Unreal is the ircd there is a module out there called os_tssync that can help keep the clocks sync'ed. Nothing beats a good NTP client .. but for those that can't/don't run one .. the module is fairly useful. Just google for it.
[Edited on 13-6-2006 by katsklaw]
-
[15:44] -Server1.network.com- *** Server=Server1.network.com TStime=1150202695 time()=1150202695 TSoffset=0
-
[15:44] -Server2.network.com- *** Server=Server2.network.com TStime=1150202693 time()=1150202695 TSoffset=0
-
[15:44] -Server3.network.com- *** Server=Server3.network.com TStime=1150203009 time()=1150203011 TSoffset=0
-
[15:44] -Server4.network.com- *** Server=Server4.network.com TStime=1150202689 time()=1150202691 TSoffset=0
-
[15:44] -Server5.network.com- *** Server=Server5.network.com TStime=1150202680 time()=1150202681 TSoffset=0
-
Is this Ok?
-
can it be because of U:Lines ??
-
i already got the answer it was something with the time :)
-
I am having the exact same problem with Anope 1.7.14 and UnrealIRCd 3.2.5. I am using Suse 10.1.
I had compiled and installed the os_tssync module from here http://www.nomadinc.net/mymods/files/os_tssync.c and loaded it using operserv on the irc server.
After running /operserv os_tssync, got the message that the servers were now synced, but after the sync the server was now unresponsive. No commands I entered did anything. Seems like the server freezed.
Had to kill the ircd daemon from the process table.
Is there any other way to sync the servers? Since this problem seems to be a time issue.
I know Unreal also has /tsctl command but I'm not sure how it works to sync the server times.
/tsctl ALLTIME produces the following:
*** Server=caribyard.homeip.net TStime=1151886920 time()=1151883551 TSoffset=3369Dunno if that helps.
-
You are so far out of sync that the ircd froze, this is a known Unreal issue that if the clock is to far out that it will hold and wait for the time to catch up
Try syncing the computers clock up first then then worry about the ircds being within seconds.
-
How do I sync the computers clock?
EDIT: Nevermind. I changed my time zone on my system clock, restarted the server and it now shows*** Server=caribyard.homeip.net TStime=1151890117 time()=1151890348 TSoffset=-231That's much better than before.
The problem with the services server removing the channel modes is now gone. whew.
Thanks Trystan
[Edited on 3-7-2006 by Davio]
-
well in Unreal3.2.5, they now have a timesync feature... You can set that up on all servers, then maybe the times will keep in sync.
-
I have a similar Problem. Always, when my cusins server brakes away from the network and someone joins an empty but registered channel, this happens:
[00:12] * Attempting to rejoin channel #test
[00:12] * Rejoined channel #test
[00:12] * ryogairc.de sets mode: +pnt
[00:12] * ChanServ sets mode: +rlL 2 #home
[00:12] * ChanServ changes topic to '<font color="red">Offizielle Homepage von RyogaIRC - <a href="http://ryogairc.de/">http://ryogairc.de/</a></font> (Ryoga)'
[00:12] * services.ryogairc.de sets mode: -pntrlL #home
[00:12] * services.ryogairc.de sets mode: -o Ryoga
[00:12] * Robot (botserv@bots.ryogairc.de) joins
[00:12] * Robot sets mode: +ao Robot Robot
[00:12] * Robot sets mode: +q Ryoga
Has anyone an idea what causes this and how to fix it? The other ircd runs on a PC so it can't be online 24/7
-
It is caused by a time synchronization problem where the Services package and the IRCd are seeing different times. I think this may be because Anope uses the system clock where as some IRCd's such as unreal run their own internal clock. So if the system clock changes the IRCd clock wont and so will cause a time difference.
Just my theory.
-
/tsctl svstime works to fix it temporarily, as well as restarting the services. but always when a server connects or leaves, the problem comes up again. :'(
I wonder why this happens. Why are the clocks not synced, after a server connects/leaves?
[Edit:]
I got the problem again now, after this line appeared:
[02:02] -ryogairc.de- *** Notice -- Time running backwards! 1152316950 - 1152316951 < 0
[Bearbeitet am 8. 7. 06 von Ryoga]
-
Originally posted by Rob
Im guessing your clocks are way differnt, and it's seeing the join before it thinks the channel was ever created, as such, it takes the modes away.
Sync your clocks.
I checked again and mentioned, that it happens always when a server connects/disconnects, but also if not. my UnrealIRCd and the services are on the same machine, so how can the clocks of them be "way diferent" already 3 seconds after the services were stared or /tssctl svstime was used? sometimes, nothing helps to fix it at all, it just happens again and again.
Actually, unassigning Botserv helps for now but that's not really a solution :(
Chanserv sets the modes, then services server unsets them, afterwards botserv-bot joins... so it looks to me like the services Server thinks the modes were set before the channel was created becaus they were set before botserv joins. what clocks to syncronice at all? the ones of chanserv and botserv or what?
[Bearbeitet am 8. 7. 06 von Ryoga]
-
A problem i found that may cause this is when the server that services is connected to connects to another server. I find it is better if another server connects to that server instead treating it as a hub even if the only servers connected to it are services and a link to the main part of the network.
-
In my case, the server with the services is the only one with static IP, so others connect to it.
-
It could be a case of the servers clock ending up at a different time to that of the IRCd's internal clock then.
-
I'm using a virtual server, maybe that causes that unreal claims from time to time that the time is running backwards... and that could also cause the other problem... but is there a way to fix or to workaround?
-
Ryoga,
Output of /tsctl alltime
Please.
-
I did it twice (before and after cycling a channel, i'm not sure if that makes any difference). Btw the services server removed the modes again this time. I also cycled the chan 7 times, twice the modes stayed and 5 times they got removed.
first time:
[21:13] -ryogairc.de- *** Server=ryogairc.de TStime=1152558802 time()=1152558801 TSoffset=1
[21:13] -irc.RyogaIRC.com- *** Server=irc.RyogaIRC.com TStime=1152558801 time()=1152558804 TSoffset=-1
second time:
[21:14] -ryogairc.de- *** Server=ryogairc.de TStime=1152558864 time()=1152558864 TSoffset=1
[21:14] -irc.RyogaIRC.com- *** Server=irc.RyogaIRC.com TStime=1152558866 time()=1152558867 TSoffset=-1
-
Just so you have somthing to compare to from a network that is currently working correctly:
First Time:
-bravo.invictachat.co.uk- *** Server=bravo.invictachat.co.uk TStime=1152560185 time()=1152560215 TSoffset=-28
-alpha.invictachat.co.uk- *** Server=alpha.invictachat.co.uk TStime=1152560185 time()=1152560186 TSoffset=-1
-delta.invictachat.co.uk- *** Server=delta.invictachat.co.uk TStime=1152560187 time()=1152560188 TSoffset=0
Second Time:
-bravo.invictachat.co.uk- *** Server=bravo.invictachat.co.uk TStime=1152560243 time()=1152560273 TSoffset=-28
-alpha.invictachat.co.uk- *** Server=alpha.invictachat.co.uk TStime=1152560243 time()=1152560245 TSoffset=-1
-delta.invictachat.co.uk- *** Server=delta.invictachat.co.uk TStime=1152560245 time()=1152560246 TSoffset=0
Oh and for reference my Anope is running on the same computer as bravo and i was connected to bravo.
[Edited on 10-7-2006 by Jobe1986]
-
because getting further information is cool, I'll give some too:
I was connected to ryogairc.de, services are running on the same maschine. My server maschine is a so called virtual server with SuSE Linux 9.3 as operating system.
-
Oh and some extra info from me:
Am running on Windows, a mixture of XP Pro and NT 4 (yes i know needs to be updated when i can)
Anope is running on XP Pro.
All servers are automatically syncing their clocks from the server running Anope on a daily basis.
When trying to run 1.7.14 on Windows NT 4.0 the log shows:
[Jun 04 14:31:23 2006] Loading IRCD Protocol Module: [unreal32]
[Jun 04 14:31:23 2006] status: - [Module, Okay - No Error]
[Jun 04 14:31:23 2006] Microsoft Windows 95 is not a supported version of Windows
This is incorrect as it is not Windows 95 but Windows NT 4.0 (Just thought id bring that to your attention again.)
-
As a reminder, many of these issues can be solved by running a NTP client on your server. If you cannot install a NTP client ask your server admin to do it. If that fails and you use Unreal IRCd using http://www.nomadinc.net/mymods/files/os_tssync.c will fix your time issues.
-
A NTP client, hmm, but it changes the server clock, doesn't it? so why should I run it? does it matter if it is eg. 12:30 or 11:47? as long as all servers have the same time?
[Bearbeitet am 11. 7. 06 von Ryoga]
-
Thats the purpose of an NTP client. To make sure all the servers have the correct time.
[Edited on 11-7-2006 by Jobe1986]
-
Anyways, the module works to fix the prolem. even if all servers claim "timediff 0"
-
does it matter if it is eg. 12:30 or 11:47?
Yes, it matters greatly! All servers need to have the same time so that timestamps are synchronised. Would it matter to you, Ryoga, if you logged into your server at 12:39 and I logged into another server at the exact same moment but my clock says 12:38 and you get killed in a nick collision because my timestamp is older? I'm sure it would matter then.
IRC servers *must* stay in sync with each other or you will experience utter chaos.
ciao
-
well.. I said: "Does it matter AS LONG AS ALL SERVERS HAVE THE SAME TIME" and you say "It matters, because all servers have to have the same time"... may I ask why you negate my statement and repeat it afterwards?
Anyways, today I had to use /operserv TSSYNC around 3 times till it worked, and still, sometimes, the service server removes all modes on join (only once in 7 joins instead of 5 times in 7 joins as before, but it still happens :( :( :( ).
And still noone was able to tell me satisfiely how the clocks of UnrealIRCd and Anope can be different if they run on the same machine.
-
unreal will use a ntp server and apply an offset to the time of the box, services will not, they will rely on the host system time. As such, if unreal moves the time away from the system time to be "correct" and anope dosnt, you get diffrent times on the same box.
-
Might be a suggestion for anope to be able to somehow retrieve the time of the server it's directly connected to and use that as a base for its time.
-
Anope gets it's time from the computer it's running from .. just like all other irc daemons. The issue here isn't the ircd server nor services .. it's the fact that server admins are not running some form of reliable clock or an NTP client and their network is suffering from it.
Services, nor IRCd's should be modified to overcome the lack of access to or understanding of the OS.
-
The point im making is with UnrealIRCd if im correct it sets its time offset when it first starts up. Then if the system time is changed afterwards it is then incorrect and thats where the problem will start to occour.
Im not sure how the entire time system of Unreal works but thats how the base of it appears to work for me.
[Edited on 13-7-2006 by Jobe1986]
-
The solution to all of these problems is for box administrators to keep their boxes sync'd up. It's not a complicated process cronning an ntp client to keep things ticking over nicely. You can poke around setting offsets, syncing anope to its own source, or to some ntp server, but the root of the matter is that the box admin needs to sort his stuff out.
-
Originally posted by chaz
The solution to all of these problems is for box administrators to keep their boxes sync'd up. It's not a complicated process cronning an ntp client to keep things ticking over nicely. You can poke around setting offsets, syncing anope to its own source, or to some ntp server, but the root of the matter is that the box admin needs to sort his stuff out.
This was my underlying point. Thank you chaz for wording it differently. :)
-
Yeah, figured repeating it might make it sink in :)
-
Just for reference for other users if youve got your servers working nicly with NTP set up properly you should get /tsctl alltime results like this:
[15:12:29] -bravo.invictachat.co.uk- *** Server=bravo.invictachat.co.uk TStime=1153145554 time()=1153145554 TSoffset=0
[15:12:29] -alpha.invictachat.co.uk- *** Server=alpha.invictachat.co.uk TStime=1153145554 time()=1153145554 TSoffset=0
[15:12:29] -delta.invictachat.co.uk- *** Server=delta.invictachat.co.uk TStime=1153145554 time()=1153145553 TSoffset=1
-
the services setting mode -ntr thing only occured on my network when all the servers were switched to Unreal3.2.5... I never noticed this problem back on 3.2.3 or 3.2.4... could this be an Unreal problem also?
-
I dont think youll find it is an Unreal problem as i had this problem with UnrealIRCd 3.2.4 I definatly think its a time problem as it only appeared to occour when some of the server's times became out of sync. For example where the system clock had been updated to the correct time but Unreal was still applying an offset thereby making Unreal's time incorrect.
In most cases it appears to occour after the servers been running for some time.
Basically if you can start it up so Unreal has a time offset of no more then + or - 2 then there should be a problem when the offset makes the time that Unreal uses incorrect.
[Edited on 18-7-2006 by Jobe1986]
-
Originally posted by Jobe1986
In most cases it appears to occour after the servers been running for some time.
Not in my case, it happens just after the server has been started
-
can somebody give me the os_tyssync module for windows and unreal 3.2.5 version? thx :)
-
Added you to msn to send you it.
-
Or not, as you don't need it anymore.
-
I'm still getting a really bad offset, by about
TStime=1156037737 time()=1156066418 TSoffset=-28679
-
Your servers time could really do with synchronizing using an NTP client.
-
this used to happen to me if you HAVE a bot assigned to that channel then unassign it and re assign it to said channel. if you DONT then IDK whats wrong (if this helps)
-
Here this problem occurs after upgrading to the latest Anope 1.7.15. (already had UnrealIRCD 3.2.5)
Re-assigning the bot and dropping®istering doesn't help.
The server and services are both on the same server - no other linked servers present.
When joining a registered channel with mode lock +rsR, where no people are in yet:
[20:24:56] * ChanServ sets mode: +srR
[20:24:56] * ChanServ changes topic to 'blabla (STING)'
[20:24:56] * services.xxxx.nl sets mode: -srR
[20:24:56] * services.xxxx.nl sets mode: -o STING
Joining a regular registered channel where no other people are in yet:
[20:36:33] * ChanServ sets mode: +r
[20:36:33] * ChanServ changes topic to 'blabla (STING)'
[20:36:33] * services.xxxx.nl sets mode: -r
[20:36:33] * services.xxxx sets mode: -o STING
[Edited on 21-8-2006 by STING]
[Edited on 21-8-2006 by STING]
[Edited on 21-8-2006 by STING]
-
I think that's a timesync issue but I'm not sure.
-
My apologies - I've used os_tssync to sync the times, it is in working order now.
Thanks
-
I've loaded os_tssync, I used /operserv tssync. Here's what I get:
°° 08:53:20 °° * (irc.xxx.com): *** Notice -- TS Control - U:line set time to be 1156488714 (timediff: 0)
°° 08:53:20 °° * (irc.xxx.com): *** Global -- from OperServ: Cyber used TSSYNC to sync all server's TS (TS: 1156488714)
After that, I join channel as a founder, services root, superadmin - and I get no status. I must say that I don't get "services sets mode -ntr" error, but it seems there is still a problem.
Any suggestion how to fix it?
-
/msg NickServ set autoop on
i believe that should fix it
[Edited on 25-8-2006 by Tom65789]
-
It works!
Thx m8 :)
[Edited on 25-8-2006 by Pedja]
-
Hello
where can i download the new services 1.7.17 that works. and with that commadon in it....
/msg NickServ set autoop on
why have the forgot to import that i the new services version.
or have the fix it
-
Do you mean this link: http://sourceforge.net/project/showfiles.php?group_id=94081 ?
[Edited on 23-10-2006 by n00bie]
-
Hello
i could see that the site was working and i could download fro mthere yesterday.
But have the fix the /msg set nickserv autoop on
this would be easyer for my members not to set that function every time the log on.. some user can use it once others need to put this in perform.
-
os_tssync is the best solution! Thanks trystan! Now I feel happy! (because im using a virtual server, so i cannot adjust the system-clock)
-
For anope 1.7.18 & UnrealIRCD 3.2.6
[02:38] * Now talking in #support
[02:38] * ChanServ sets mode: +ntrcVCNG
[02:38] * services.xxx.net sets mode: -ntrcVCNG
[02:38] * services.xxx.net sets mode: -o orga
but I used tssync,It can fix it now.
Why? anope.. doesn't have auto TSSYNC when connected IRCD ???
-
why would anope do that ?
the server admin is supposed to make sure the time on the box is correct, there s specialized software for that...
and tssync is just an ugly fix, it can cause servers to hang for a certain period...
-
Ok... and how 2 set up it, I just basic user,I know how 2 fix this problem with module tssync.
" the server admin is supposed to make sure the time on the box is correct, there s specialized software for that... "
Does it have a Document.....
-
yes: NTP (Network Time Protocol)
http://www.ntp.org/
you need root to be able to run it though...
So if you use a shell, you need to contact your host.
But if your host doesn't syncronize time on his box, i d seriously consider getting another host since this is something essential every administrator does... shouldn't be asked for
-
Oh... Thank you very much.
Now my host run ntp and does not have problem wth timesync... :D
-
Fistly appolagies for dragging up a month old thread.
Secondly i can explain exactly why you can see services.domain.tld setting modes -ntr.
First though i would like to point out that technically speaking it is actually Unreal that makes the mode change not Anope. But the cause of it is with the timestamp of the SJOIN used to join the BotServ bot to the channel.
According to Unreal's server protocol when it recieves an SJOIN where the timestamp is less then what it knows to be the timestamp for that channel it resets the modes for that channel and lists it as being the server that sent the SJOIN as setting the modes. This is the reason Anope doesnt re-set the modes because Anope is completly unaware of the mode change to begin with.
So basically this problem is caused by the time Anope uses being a few seconds different from the time Unreal is using.
This can be fixed within Anope by one of a few ways:
1. Because of the way SJOIN's are handled it would be sensible for Anope to include the channels modes in the SJOIN instead of leaveing the modes param blank (which is the cause of no modes being reset)
2. Anope could use a timestamp on the SJOIN it knows is definatly in the future so that the bot is joined to the channel but no modes are change since the BotServ bot is opped after anyway.
3. (This one i dont really think is a good idea but does work in my experiments) Unreal accepts the basic JOIN message from servers so Anope could simply use that instead.
Ideally 2. is the best option because it results in NO modes being reset. But 3 would have the same effect too.
As for what server admins can do in the mean time to resolve this, the simple answer is to make sure the server Anope is running on has an accurate clock by means of NTP or alternativly using/tsctl to ajust the offset on your servers to make sure Anope's timestamps are seen by the Unreal servers as in the future.
[Edited on 8-2-2007 by Jobe1986]
-
replies to numbers:
1> constantly changing modes because another server changed them can lead to the infamous "bot fight" widley seen take place between Chanserv and Eggdrops because they are both set to enforce modes and both think they are right. No thanks.
2> Future to whom? .. how is services to know what is "in the future" to the ircds if they have offset times? .. no thanks, lets stick to the facts.
3> would cause undue desyncs IMO not to mention that the ircd should use it's own timestamp on the SJOIN so the events are not responded to out of order due to some latency somewhere. No thanks.
"As for what server admins can do in the mean time to resolve this, the simple answer is to make sure the server Anope is running on has an accurate clock by means of NTP"
Now THAT is the correct answer and it has always been the correct answer for many many years. Plus NTP is simple to use and mostly automatic. It's also conveniently the solution with the fewest variables.
Some things are simply required to function properly, in this case NTP. If you don't use ntp, expect desyncs ... it's that simple. I find servers like mine that run ntp don't have this issue.
If you are hosted on machine that you don't have root access to, tell the admin to run ntp .. it' something they should be doing anyway, especially if they sell shell hosting accounts. The best solution is not always the high tech or most complicated solution.
-
install ntpdate on your machine
ntpdate -s -u pool.ntp.org
and a dayly cron
30 1 * * * /usr/sbin/ntpdate -su pool.ntp.org
-
Mod NOTE: Your solution will not fix this issue.
This thread has reached 3 full pages and it doesn't need to. When Services acts in this fashion, it's a timestamping issue, all possible solutions have been already discussed in full detail and there is no need to comment further. Please read this thread in it's entirety as your solutions WILL be in it.
Locking.
[Edited on 18-8-2007 by katsklaw]