Server Bugs

Bug reports on new double region crossing fixes by Pepper Linden

There are some delicate relationships between the event poller server side timeout, the event poller viewer side timeout and the child agent inactivity server side timeout. Problems in this area have been discovered before. I think I just got to the bottom of another one. This is not something that needs an urgent fix, but if any work is done on the event poller, this issue needs to be considered. Pepper Linden has told me that there's a 50-secoind timer which causes the server to disconnect a child agent for inactivity. I've seen that happening. If the viewer's long poll timeout is longer than 50 seconds, there is a possibiilty of child agents timing out and a DisableSimulator being sent. I've done some tests in Sharpview. A 90 second timeout causes an unexpected DisableSimulator for an active child region followed by a viewer disconnect about once every hour. With a 15 second timeout, that does not happen in 24 hours. So I now have a workaround inside Sharpview. Here is what I think is happening. I can only see viewer side, of course. Pepper set up an island atop a region corner at Blake Sea - Nelson on aditi. I set up a train track loop which goes right through the region corner, and a small train which endlessly circles the loop. We put avatars on the train and run unattended region crossing tests for hours or days. This is a useful stress test and has brought out some region crossing bugs, which have been fixed. By now, the LL and Firestorm viewers can run that test for a full day without error. But when I run one of the avatars from my Sharpview viewer, it was failing in 1-3 hours. I was using a long HTTPS poll with a 90 second timeout. That works fine until you start running multi-hour tests. Why would the timeout matter? Because, apparently, no activity on the event channel for 50 seconds causes a DisableSimulator. An event channel timeout seems to count as "activity". So if the event channel timeout is longer than the DisableSimulator timeout, and there's no real traffic on the event channel, and it's a child region, and the timers line up, the region disables itself for that viewer for inactivity. Henri Beauchamp has experimented with various timeouts in his viewer, and notes that behavior changes with the timeout value. Since both server and viewer can time out, whomeever has the shorter timeout times out first. If both have the same timeout, there's a race. We're still not sure about all the possible race conditions. I'd suggest a solid fix that gets rid of HTTPS timeouts. When there are no events to send, the servers should send an empty array of events over the event channel every 15-20 seconds to keep the connection alive. Existing viewers should ignore such an empty array. so this should not affect existing viewers. All HTTPS transactions on the event channel then become OK 200 transactions, the happy path. Overhead drops, because re-establishing the HTTPS connection several times a minute means a full cryptographic handshake, while sending a short message over an existing persistent connection is much cheaper. If there are any remaining unexplained event poll problems, this is probably worth doing. It's so easy to create intermittent problems by changing one of those numbers. Changes to libcurl, Apache (which, I think, front-ends the HTTPS caps on sim servers), the sim servers themselves, or viewers can affect this. It's a huge pain to diagnose such problems, because the failure rate is so low and you need a test fixture like the little train on its track loop. This took weeks of work, because the test is so slow.

Offline IM email timestamps appear to use UTC rather than SLT, This is making them inconsistent with in world timestamps.

We have 4 parcels across our sim, we have three parcels that work without issue but the one listed in the viewer info voice will not work regardless of settings, restarting voice, restarting the viewer, disabling and re-enabling voice in the land setting. We have confirmed on both Windows and Linux, along with Multiple viewers on both operating systems and multiple people that they too cannot get voice on this parcel. Any help would be immensely appreciated.

Both group chat and IM failing to initiate. I mostly experience it in Firestorm Social Island (simhost-0be97bd680c67540a.agni), as do the rest of the team. Starting an IM with someone else will work most of the time and every once in a while end up with a popup stating "Unable to start a new chat session with Username. The session initialization is timed out". Group chats will either fail silently or give the following message inline: "Second Life: You are the only participant in this IM session. Your message is not being broadcast at this ti2me." Tested on Second Life Release 26.1.1.23806384790, Alchemy Beta 7.1.9.2516 and Firestorm 7.2.3.80036.

Overview of the problem We are experiencing a persistent communication failure when our automated vendor within Second Life (through a POST request with LLHttpRequest) tries to communicate with our backend server located at https://factorycasas.es/Radio/Crear_Emisora.php . Every transaction attempt from Second Life consistently results in an HTTP Status Code 499 (Customer closed the request/Timeout) on the LSL side, while conventional web browsers, API testing tools (such as Postman) and external HTTP clients can successfully access the endpoint, obtaining a 200 OK status in less than 50 milliseconds. Technical environment and architecture Target endpoint: [ https://factorycasas.es/Radio/Crear_Emisora .php] SSL/TLS configuration: Valid certificate (Certbot/Let's Encrypt) with the complete intermediate chain configured correctly. Backend optimization: The PHP script implements asynchronous execution in the background (fastcgi_finish_request (), ignore_user_abort () and CLI workers) to ensure that the HTTP 200 response is sent to the client instantly, eliminating any internal processing bottleneck. Symptoms and Diagnostic Findings LSL behavior: When executing LLHttpRequest from a scripted object in the world, the request was blocked for approximately 25 seconds and was abruptly interrupted with HTTP 499, returning an empty response body (body: “”). Network Interception Test: When testing the endpoint using external web clients or curl from external networks, the response is immediate (HTTP/ 1.1 200 OK). When monitoring network traffic using tcpdump on the VPS pointing to Linden Lab's known outbound IP ranges (64.129.x.x, 216.82.x.x, 162.243.x.x), incoming TLS handshakes or packets coming from Second Life regions are not recorded or appear to be completely discarded, strongly suggesting that outbound traffic from the SL simulator is being filtered, blocked or limited before reaching the server's public interface, or that the domain Destination /IP has been unintentionally marked or restricted in the simulator's outbound firewall. Alternative access: Other domains hosted outside this VPS or specific network perimeter successfully receive callbacks (LLHttpRequest) from the exact same region without throwing error 499. Request for assistance Since external HTTP access to factorycasas.es operates normally for all global traffic, with the exception of requests from Second Life simulator nodes, we kindly request your collaboration to: Check if the domain factorycasas.es or the associated IP address of the VPS is currently restricted, rate-limited, or blacklisted within Linden Lab's outgoing proxy/firewall infrastructure. Review possible output routing problems or incompatibilities in SSL/TLS ciphers between the simulator's HTTP client library and our server configuration. Thank you in advance for your time and technical support. I am at your disposal for any clarification.

We did 11 races in January with all together 96 racers and have about 7-12 racers per race. A race takes normally max 40min. But there was not a single race in January all sailors finished without disconnects or thrown off the sail boat on crossing sim boarders The region "Depace" is the worst sim in the last weeks. We crash there most of the times either on the crossing into Depace or out of Depace. It happens as well when someone sails alone there. There is not much underwater stuff that needs to be rezzed long. So there is no actual reason for these crashes there. Check the sim Depace first and seriously and don't just look at some general parameters or values. Do a serious check including server address changes and all those things. The other sims start getting the same issues more and more. So the whole area is worth to be seriously checked. and i talk about all these sims: Stodierski, Mautte, Paltiete, Mon Bayete, Degrand, Sarante, Petaccio, Rexach, Betacourt, Feraco, Repaci, Castrum, Palmerston, Rafeiraga, Valdivian, Couse, Gerache, Collhaytah, Port Pawtee, Maris, Conwy, Port Gonnornertnert, Quimadra, Depace, Lavaca, Val Encia, Benach, Coull, Oprince, Getachew, Wyrldmaker, Corpening, Geffers, Costagliola, Cottier

I have built a full mesh airship that occasionally, for no reason I can define, secretly changes from Prim Physics to Convex Hull. I am seeking a resolution to this as it is a product I am selling and I want to give my clients the best possible experience. I have reuploaded parts of the build and detached parts I had given the Physics of 'None' from the main ship. I have even detached the doors thinking maybe the door script was doing it somehow. Even after all of this, the build will still randomly go into convex hull. There are many pieces in the build. This is what the physics looks like: https://gyazo.com/0c13bc3345aad4017acc2b2ff19c2913 Any suggestions for what I might try to resolve this issue?

I have searched for previous reports on this subject, but not found anything. Sorry if it has been discussed before. This is not recent, it has been around since I've been in SL. People complain about it, but why can't it be sorted out? If you fly or sail a vehicle solo though a parcel where vizibility has been turned off, nothing happens to the camera position that has been programmed into the vhicle. But if you fly or sail with a friend or friends all sitting on the same vehicle, then the programmed vehicle cameras get messed up as you enter, and as you leave the parcel where parcel visibility is turned off. As many estate islands have navigable water around them, and some estates (such as Tuarua Fiji) renting full sims, half sims and quater sims to residents, where some have vizibility on, and others have vizibility off, this is a real pain to sail though with friends on the boat. You have to reset the boat camera on entry, then reset it again on exit. Is there no fix to this issue that can be applied to the sime, or automated in the boat scripts? if there is something, I'd gladly add it tothe vhehicles that I build.

A year later and it is getting worse. It happens nearly every trip in my boat. I have identified three ways this happens on a region change. I suspect that they are different manifestations of the same underlying cause. Unsit, where the boat does rez in the new sim and continues on its way while I am thrown overboard and end up on the bottom. My boat (Machichaco by Isard) detects this and sends me a message with it's current SLURL, allowing me to TP to it, resit, and take control. This used to be the most common form of failure. Loss of control. I remain sitting on the boat but it is no longer responsive to my inputs. The boat (and I) continue in the new sim, moving along the previous velocity vector in a phantom state, passing through buildings and land. If the velocity had a vertical component we may end up flying up at an angle, or submerging. I think this is the viewer extrapolating on its own. Catapult. The boat does NOT complete rezzing in the new sim but I do. Since the boat no longer exists, it does not send me a SLURL message and it does not end up on somebody's land where it would eventually get returned. As in case #2, my avatar continues along the previous velocity vector, often up into the sky (sometimes hundreds of meters up). I can follow my progress on the Map but I notice that the viewpoint and the avatar location are not together. I can see myself off in the distance as we fly away. Eventually, either a timeout or reaching the far side of the new sim, I am suddenly jerked back to two sims back, standing on the sea bottom. I can walk forward and backward but unable to turn. At this point I can TP back home but on arrival, the inability to turn continues. This case is happening a lot now. Examination of the log for case #3 (collected at 2026-06-03T02:16:14Z) finds many suspicious WARNING messages which may provide clues. I was proceeding West along an open corridor in the Blake Sea area: Norwegian, Japan, Irish, China. Caribbean. Speed was about 11 knots. (Entry to Caribbean is where case #3 happened.) Each of these warnings appear multiple times. I was using a non-mesh avatar with no scripts other than a Navigation HUD that was logging sim crossings (88 kB), and the boat control HUD (64 kB). There is, in at least case #3, no logging of actually entering the new sim. requestExperiences : Capability query method not set getCapability called before caps received for GetExperienceInfo stageAfterCompletion : HTTP request 0x7f6205a56c10 failed after 0 retries. Reason: Forbidden (Http_403) onCompleted : Possible failure [Http_404] cannot POST url ' https://simhost-0353d13a62153db1f.agni.secondlife.io:12043/cap/defd51df-3e5d-1671-81f7-5d5f44b87a5e ' because Not Found onAssetLoadComplete : Error getting material asset data: Asset request: failed (-1) process_agent_movement_complete : agent_movement_complete() with NULL avatarp. parserWarning : Failed to parse parameter "sd[order]" The "Statistics" window shows that UDP traffic continues as before with a sim ping time of 134ms. This looks like a combination of race conditions and the new sim simply not responding. I note that setting Draw distance to just 32m increases reliability considerably but it is very boring because the whole point of these trips is to look at the scenery pass by.