|Anonymous | Login | Signup for a new account||2020-01-18 06:43 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008513||opensim||[REGION] OpenSim Core||public||2019-04-05 08:22||2019-11-01 03:03|
|Target Version||Fixed in Version||master (dev code)|
|Summary||0008513: Teleport refused because failed to verify user presence|
|Description||Teleport fails between two regions with error in console and viewer:|
2019-04-05 10:13:53,091 DEBUG [ENTITY TRANSFER MODULE]: Teleport of Test User from Test Region 1 to Test Region 2 was refused because Failed to verify user presence in the grid for Test User, access denied to region Test Region 2.
The regions are setup to where they are not immediately next to each other like this: [Test Region 1] [Void] [Test Region 2]
Teleport works one time to either region and then every subsequent teleport attempt thereafter fails with the above message. The only way I have found to get around this is to relog and then teleport to the desired region; but after that it is back to square one with the error messages, relog to teleport, repeat.
Strangely this does not happen with two completely blank regions; I only started noticing this when I started building and putting stuff out on the second region and attempted to teleport back to the first region and it failed. Blanking the regions out lets me teleport back and forth fine again but as soon as I start putting stuff out again teleports start to fail in this fashion.
Currently I see this on OSGrid with my two region test setup. I have not yet tested this on a local grid.
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||.NET / Windows64|
|This may be a specific osGRID issue due to the regular cleaning of the presence table.|
Possibly... But does it get cleaned out on each relog? Because I can make this happen consistently: Login > Teleport > Try teleport back; fails. Relog, can teleport once, fails every time after; repeat.
I will test and see if it's an issue on local grid and post the results here later on when I get a chance.
edited on: 2019-04-05 20:41
After some testing on local grid (Not OSGrid) I can also trigger this issue. I ran git bisect and found a bad commit in which it started happening but I don't think it found the correct commit because compiling the commit before that still exhibited the issue. So I think the issue is not quite as consistent as I first thought it is. Will need to run bisect again and see if I can find a point where the bisect result makes more sense.
edited on: 2019-04-05 23:33
5 git bisect sessions later... I think I have come up with a commit that makes sense now at commit df14ed7d312e2f38e21912447835d9f078b97a95
I did some extensive testing on the commit just before that one and can't get the issue to trigger. So I feel more confident that the issue starts appearing at df14ed7d312e2f38e21912447835d9f078b97a95
Git Bisect Results:
$ git bisect bad
df14ed7d312e2f38e21912447835d9f078b97a95 is the first bad commit
Author: UbitUmarov <firstname.lastname@example.org>
Date: Mon Jan 14 18:39:16 2019 +0000
more on TP
:040000 040000 487d8bfaa32227c005e9862f77e98f5c3491c7b7 38063a13dcbdaae3bf790a9ae167c2c56c614ab9 M OpenSim
:040000 040000 9caa783069181cfc0cdecac35ed085f548b14e09 0ae596f7081ba2d5aea0a1a4609e4d6c0fc9565b M bin
This is another one of those odd ones, as I'm running my whole grid on the new code, and nobody is getting this error ...
I'm sure it is a combination of things causing it, just don't know what the secret sauce is ..
|I have noticed that if NPCs are involved, as in, the creation of them and removal of them before TPing back and forth, it seems to make this trigger more easily.|
|@mewtwo0641 Try the latest master Ubit has been working on that I think ...|
|I just gave master a try but the issue still persists|
|The only way I have found to trigger this is doing "Suicidal" TP's , if you let both the receiving and sending regions settle , it does not seem to happen.|
I did some more testing on this but this time with a new database and still see the issue. A new thing that I have noticed is that any regions that decide that the user is no longer online will be invisible to the user even if they are directly adjacent to the region the user is in ([Region][Region] As opposed to my original setup of [Region][Void][Region]).
Some regions within the same OpenSim instance will still accept TPs and some won't and will be invisible to the user. The regions that do and do not appear to be at random. Whenever a user TPs to a region that is still accepting TPs from that user there's a flood of messages in the console listing off the regions that aren't accepting TPs that look like this:
[ENTITY TRANSFER MODULE]: Region (Region Name) did not accept (User Name) (User UUID): Failed to verify user presence in the grid for (User Name), access denied to region (Region Name)
This scenario is more obvious when there are more than a couple regions on the OpenSim instance (The one I tested this time had about 10 regions).
|This seems improved now as of master (commit f29fdb6bdae51e50f749e2144a3e92fb3171f436) but will keep an eye on it before confirming fixed since it's a random occurrence.|
|Haven't seen this issue for a while. Seems fixed by master.|
|2019-04-05 08:22||mewtwo0641||New Issue|
|2019-04-05 08:36||BillBlight||Note Added: 0035029|
|2019-04-05 09:30||mewtwo0641||Note Added: 0035030|
|2019-04-05 19:59||mewtwo0641||Note Added: 0035032|
|2019-04-05 20:41||mewtwo0641||Note Edited: 0035032||View Revisions|
|2019-04-05 21:07||mewtwo0641||Note Added: 0035034|
|2019-04-05 21:09||mewtwo0641||Note Edited: 0035034||View Revisions|
|2019-04-05 21:35||mewtwo0641||Note Deleted: 0035034|
|2019-04-05 23:09||mewtwo0641||Note Added: 0035035|
|2019-04-05 23:33||mewtwo0641||Note Edited: 0035035||View Revisions|
|2019-04-06 02:13||BillBlight||Note Added: 0035037|
|2019-04-06 10:12||mewtwo0641||Note Added: 0035038|
|2019-04-06 10:28||BillBlight||Note Added: 0035039|
|2019-04-06 18:18||mewtwo0641||Note Added: 0035040|
|2019-04-08 04:43||BillBlight||Note Added: 0035064|
|2019-04-08 19:07||mewtwo0641||Note Added: 0035069|
|2019-04-09 03:32||aiaustin||Relationship added||related to 0008515|
|2019-04-09 03:32||aiaustin||Relationship deleted||related to 0008515|
|2019-04-09 04:04||mewtwo0641||Note Added: 0035072|
|2019-11-01 03:03||mewtwo0641||Note Added: 0035812|
|2019-11-01 03:03||mewtwo0641||Status||new => resolved|
|2019-11-01 03:03||mewtwo0641||Fixed in Version||=> master (dev code)|
|2019-11-01 03:03||mewtwo0641||Resolution||open => fixed|
|2019-11-01 03:03||mewtwo0641||Assigned To||=> mewtwo0641|
|Copyright © 2000 - 2012 MantisBT Group|