During the teamwork development process that shares the same instance of Vagrant I always had trouble relaunching Vagrant Share due to it's session expiration. Documentation says that it's currently 1 hour (even though sometimes it worked only for 10-15 minutes). Is it possible to remove or extend session expiration time?
Currently (June 2016) the expiration time has been extended even more to 8 hours based on VagrantCloud's documentation:
Share sessions expire after a short time (currently 8 hours), but can
also be expired manually by ctrl-c from the sharing machine or via the
web interface.
However it doesn't seem to be any option to set the expiration interval yourself. And I don't believe it will ever be. The purpose of vagrant share is to share your work for a limited time just for your client to have a look or for your partners to do some testing and come back with feedback, not mid-term hosting.
It is not currently possible to change the vagrant share session expiration timeout.
Related
Ever since virtualizing several physical servers into GCP, I have had an issue where anytime the servers(s) are rebooted the time is changed to be several hours ahead (I think it's 4 hours, but may be 6 hours). My local office is located in CST time zone and that is what we want the server to display. In GCP the virtual servers are in the us-central1a zone. On the virtual server, run the tzutil /g command it shows that the server is set to "central standard time". It also shows Central timezone if I click the clock on the toolbar then choosing "change date and time settings"
After the server has been rebooted (and reports wrong time) I can correct the time by clicking the "update now" options (found on toolbar clock, "change date and time settings", internet time tab, change settings" "update now" (this points to time server time.nist.gov).
This issue only began occurring after migrating into GCP so I believe it to be a Compute Engine issue and not an OS issue.
any thoughts on why this might be happening? I have this on occurring on all 4 windows servers that were migrated into Google Cloud. three are win2008r2, and one is Win2012r2
I appreciate any help that can be given to get this resolved, as I can't even reboot without connecting to the server afterwards and checking/fixing the time, I do have set a startup script to delay and then sync time after rebooting, but it has not worked 100% of the time, so this is more of a band-aid than a fix.
I do have set a startup script to delay and then sync time after rebooting, but it has not worked 100% of the time, so this is more of a band-aid
Getting this script working is probably the solution, here. For what it's worth, you'd need to do the same thing on both Azure and AWS as well, since they also set Windows timezones to UTC by default using the same mechanism.
See AWS docs on the Specialize Phase
See this Stackoverflow question for a similar question about Windows on Azure
Normally all servers run on UTC time, its clients (applications, browsers, etc) set their timezones according to where they are, and its up to them to translate UTC time to whichever locale they are in. (Put another way, you wouldn't want a server with a million client connections to have to keep track of each client's timezone in order to work properly). In your case, the bottom line is that requiring a custom timezone on the server will also require a custom server configuration, and the behavior you're seeing is by design. That's why your best bet is to understand why the startup script isn't working like you expect it to.
For reference, these docs may be helpful:
Google Compute Engine: Providing a startup script for Windows instances
Google Compute Engine: Creating a Windows Image
If you looked at the VM instance logs in the GCP Console you'd see that VM BIOS reports time in UTC
2019/10/3 14:9:44 Begin firmware boot time
After a while BIOS hands over to the bootloader
2019/10/3 14:9:45 End firmware boot time
Booting from Hard Disk 0...
The OS boots up. Behind the scene the OS time service recognizes the system timezone, then sets up and synchronizes time with the time source. From that time forward running programs and services report events based on the local system time:
...
2019/10/03 09:10:05 GCEWindowsAgent: GCE Agent Started (version 4.6.0#1)
In the Windows Event Log you should see entries made by the Time-Service:
Log Name: System
Source: Time-Service
Level: Information
The time provider NtpClient is currently receiving valid time data from metadata.google.internal,0x1 (ntp.m|0x1|0.0.0.0:123->169.254.169.254:123).
The time service is now synchronizing the system time with the time source metadata.google.internal,0x1 (ntp.m|0x1|0.0.0.0:123->169.254.169.254:123).
In the command prompt you can ensure that the time configuration and state are correct:
C:\Users\user>systeminfo | find /i "Time"
System Boot Time: 10/3/2019, 9:09:49 AM
Time Zone: (UTC-06:00) Central Time (US & Canada)
Hence you don't need synchronizing time neither manually or with with a startup script. The time service will do it for you: to synchronize the system time right after the boot and to keep it in sync afterwards.
All you need is to set correct Time zone and the Internet time server for Windows, and then make sure the time server is reachable via the network.
I have an classic ASP site on IIS(both IIS 6,and 8) and both perform the same. We've had this issue for years on IIS 5,6,7,8 and never could figure it out. I have a time out setting on the IIS application pool settings of 120 minutes. I do not have a session.timeout setting in any of the ASP code itself. I do have a Session.Abandon in the global.asa file, which works well.
Most of the time if a user is idle for > 120 minutes, it gives them a message that their session has timed out, expires the sessions and redirects them back to the login page.. this is how it should work and most of the time is does.
The issue I have is that about 5% of the time, some users seem to be able to keep the session alive beyond the 120 minutes. Some for days.
I'm wondering if anyone has any ideas what could cause this? Some ideas that I think could cause this??
I assume they keep their browsers open for days, but could a user that has a browser window open but sitting idle AND on another TAB of that same browser be active on other websites? Does that activity make the TAB with my application still active/not idle? I've tested this on several environments but not able to replicate.
Some type of software like a URL filter, proxy server or Antivirus could be causing their browser to not be idle?
Of course a user can keep the session idle if they use the app beyond the 2 hours, but it is rather unlikely they do this, especially for days.
Its hard to troubleshoot since the users are all customers. So I have no clue if its a certain browser, browser version, or their network environment.
Any ideas?
have you tried out to set the timeout in the Application_OnStart method in global.asa?
I had a similar problem, but in my case the session ended up before timeout.
After I set up timeout the problem was solved, just including this line:
Session.Timeout=20
Hope it helps.
Session timeouts work perfectly as expected when a clients' local time is in sync with a UTC server, however if the client has their local time set to some time in the future, they constantly receive session timeout messages and are logged out of the site.
What are some possible solutions to this problem used by other developers? I am sure that I am not the first person to have this problem, however I cannot find much information on it online.
Thanks but I worked it out. Before, I was setting a user's session to expire at a certain time, 15 minutes after their last activity. However, that expire date is set based on the UTC server's time, not the user's local time. So when the client's local date/time was compared to the expire date/time it would always cause a timeout for users with local time more than 15 minutes in the future.
I fixed this problem by setting the expire time to be an amount of time (15 minutes) rather than the actual date/time of expiration. That way no matter what the user's local time is, they will timeout 15 minutes after their last activity.
Practical Challenge:
I have a LR script that runs against an app being mocked and do not have a logout button (yet).
The test runs fine With stable response time for about 10 minutes, but after that the response time peaks and the server goes into 99% memory usage and transactions start to fail.
I suspect this is due to the script does not terminate the vusers after each run anf it builds up a lot of running sessions against the server wich is not terminated. But I might be wrong.
Anyays I want to programatically close each run after it has competed the business process.
I have red somewhere that web_set_sockets_option ("SHUTDOWN_MODE", "ABRUPT") could be used for this, but I want to be sure that this function actually does what I want and what does 'ABRUPT' means?
Are there better ways of closing sessions? Clicking the close browser during recording does not result in anything being captured in the script.
It's a server issue on session aging. Your server admin for your website can adjust the timeout values where no activity has taken place on a given session. By default most places have this set at 30 minutes. Trim it to what you need rather than taking the default value on the server.
Also, you may have hit a leak situation if resources are constantly accumulated on the server side but never released.
Based on your question I assume you're using the WEB/HTML protocol. I agree that the core issue is that your app's sessions should expire more elegantly and probably sooner. But, in order to get beyond this while testing you can try this. It isn't a guarantee, but it has worked sometimes for me in the past when dealing with similar situations. Try changing your Run-time Settings for the script:
Run-time Settings > Browser > Browser Emulation
Make sure you have the box checked for "Simulate a new user on each iteration". You can also try playing with the other settings here, like clearing the cache each iteration. This could cause a new connection setting with the web page for each iteration depending on the server's session settings. Again, this isn't 100%, but it has worked for me from time to time.
try this:
web_set_sockets_option("CLOSE_KEEPALIVE_CONNECTIONS", "1");
I observe the following weird behavior. I have an Azure web role which is deployed on love Azure cloud. Now I click "Configure" in the Azure Management Portal and change the number of instances - the portal shows some "activity". Now I open the browser and navigate to the URL assigned to my deployment and start refreshing the page something like once per two seconds. The page reloads fine many times and then fro some time it will stop reloading - the request will be rejected, then after something like half a minute the requests are handled normally.
What is happening? Is the web server temporarily stopped? How do I change number of instances so that HTTP requests to the role are handled at all times?
When you change the configuration file, your current instance might be restarted. This might be the reason you met with, which your website didn't response in about 30 seconds.
Please have a look http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.changing.aspx and check if it 's because of the role restarting.
What you are doing is manual. Have you looked at the SDK for autoscaling Azure?
http://channel9.msdn.com/posts/Autoscaling-Windows-Azure-applications
Check out the demo at the 18 minute mark. It doesn't answer your question directly, but its a much more configurable/dynamic way of scaling Azure.
Azure updates your roles one update domain at a time, so in theory you should see no downtime when updating the config (provided you have at least two instances). However, if you refresh the browser every couple of seconds, it's possible that your requests go always to the same instance due to keep-alive.
It would be interesting to know what the behavior is if you disable keep-alives for your webrole. Note that this will have a performance impact, so you'll probably want to re-enable keep-alives after the exercise.