We are running Selenoid Grid on a three node cluster (that is also running Kubernetes). Every so often when running some robotframework tests the same test in Chrome browser on the grid we see ERR_NETWORK_CHANGED when we open browser page and test fails. We never see this when not running in Grid.
Captured tcpdump and saw (RST, ACK) coming from docker container for chrome browser. Would appreciate any suggestions on how to debug this.
And yes, we do plan on moving the Grid to its own nodes (as there could be conflict between Kubernetes and Selenoid as we are not running the Kubernetes version).
Related
I want to use a NextJS app on Fly.io machines, which stop automatically when the main process stops (with exit code 0).
Therefore I wanted to call process.exit(0) after my code has decided that this process is done.
But the edge runtime doesn't have this function, which makes sense if you're really running on the Vercel edge network, but is a problem for me running in my own Docker container
I am evaluating a self-hosted artifactory installation on a trial license. I followed the official installation instructions for the docker container and the linux archive file. Neither of these installation options are working. The artifactory service fails to start.
I have opened an issue to track the problem: https://www.jfrog.com/jira/browse/RTFACT-27182
TL;DR; A component fails, a nasty stack trace appears in the logs, and eventually the services stop.
It would seem that there is a bug in artifactory. I have traced this back to multiple versions and this issue spans multiple years.
The problem appears to be that artifactory cannot get past the bootstrapping/initialization phase when started with artifactoryctl. At a certain point (around 2-5 minutes in) all the services stop and a pid file is left over, which is bad.
The workaround I have found is that the service can pass this initialization phase only after multiple start/stops (3 to be exact). In other words, we call artifactoryctl start, wait for all failures, then artifactoryctl stop and repeat two more times. On the fourth and final start, we will see the service come online (in about 150 - 190s). From then on, the service will start correctly with one call to artifactoryctl start.
I have not yet looked at the systemd unit file. My guess would be that it has/or could be made to have a number of retries to work around this issue and perhapse this issue does not exist when using the service wrapper.
I have also not yet looked again at the docker container which appears to be failing for the same reason. A workaround off the top of my head would be to modify the entrypoint script. If you were to dockerk exec into the container and try the workaround above it would likely terminate the root process and kill the container.
TCP connections work fine as I am able to converse with someone over zoom and teamviewer. However, whenever I attempt to access another webpage, I get a network error. Google seems to work fine for some reason but any webpage I go to listed by Google fails to connect. The only way I can open up my http connections is by ending a task called "init" inside of task manager. This shuts down my vscode as well as my ubuntu terminals I have running. If someone knows the solution please do tell. It's really annoying having to close out my vscode and terminals as well as my local servers to look up information and debug.
I found a fix to this issue.
So I was running a Windows Subsystem for Linux and my Windows Build was outdated as well as WSL. When I updated Windows and upgraded to WSL2, my issue was resolved and I don't seem to get any more network errors.
Overview:
Chromedriver works normally on one machine but extremely slowly on two other identical machines.
Setup:
Selenium Webdriver using .Net for coding and Selenium Grid for distributing the tests. MSTest is being used from within Visual Studio 2010 in order to run the tests.
A 64bit Windows 7 local machine acting as the Hub
Three 32-bit Win 7 remote machines (two of them are virtual) on my local network all configured as nodes. Here is the command used to start the nodes on the remote machines:
java -jar c:\seleniumWebDriver\seleniumGrid\selenium-server-standalone-2.31.0.jar -role node -hub http://XXX.XXX.XXX.XXX:4444/grid/register -browser "browserName=chrome",maxInstances=4 -Dwebdriver.chrome.driver="C:\seleniumWebDriver\chromedriver.exe"
The driver is launched like this from within the code:
DesiredCapabilities capability = new DesiredCapabilities();
capability.SetCapability(CapabilityType.BrowserName, browser);
driver = new RemoteWebDriver(new Uri(hubUrl), capability);
The variable "browser" and "hubUrl" above is passed via an app.config file that is built at runtime. For this case, browser=chrome.
Problem:
When I setup machine 212 (which is a virtual machine) as a chrome node using the command above, and then launch the scripts from the hub, I see chrome start in the proper remote machine and run normally. It fields between 5-10 commands per second.
When I setup either machine 78 (virtual machine) or machine 103 (real machine) as a node in the same manner, and then launch the scripts from the hub, I see the node start up chrome properly. However, it runs extremely slowly, like 1 command per sec or less.
Other info:
Like I said, on one machine chrome works normally, but on the others, runs extremely slowly. Firefox and IE, when configured as nodes, work normally.
I have compared the machine 212 (which works properly) with the other machines and cannot find the difference. All the machines are using 'selenium-server-standalone-2.31.0.jar' and the same version of the ChromeDriver.
It does not appear that the node machines are being overloaded. Also, it is a very consistent difference in performance which does not seem related to any fluctuating load on the network or the machines.
My network tech has verified that all these machines are configured identically on the network.
Has anybody seen anything like this before?
EDIT 1: I logged in today and all three remote machines are running chrome slowly. Before one of them was normal, but now they are all slow.
I ran into a similar issue where chromedriver was slow in some machines and it turned out to be a proxy issue. Disabling "Automatically detect settings" under Chrome://settings >Change proxy settings> LAN Settings> made webdriver execute commands faster in chrome for me.
My proxy settings were not using automatic detection, but I found the following helped a lot. The time it took to start the driver went down from 43 seconds to 1 second
driver = new ChromeDriver(new ChromeOptions{Proxy = null});
Bug link in chromedriver issues This is long lasting issue that got lowest priority. But as more user will vote for it maybe someone will fix it. It could also be releated to Parsing of proxy configuration is not standard compliant which will be fixed soon.
This code solved the problem for me for Chrome 75 on macOS 10.14.3
ChromeOptions options = new ChromeOptions();
options.setProxy(null);
driver = new ChromeDriver(options);
I have an ASP.NET website that I want to test with Selenium. I want to setup a Jenkins instance on a "staging" virtual machine, to run the tests automatically.
The problem is that the tests run very slowly - several times slower than on my development machine. A single, simple test can take more than 2-3 minutes.
I'd like to know if this is to be expected, if there are any obvious pitfalls for such a testing setup as mine, and if there's anything I can do to profile and improve the performance of the test suite.
Info:
Tests run on a 2.7GHz 2GB Ram virtual machine with Windows 7 64bit.
My dev machine is similar, but with a 32-bit Win installation.
The following is done by Jenkins:
The website gets checked out from source control, and configured with a custom web.config. The main differences are that it's compiled in release mode and it connects to a database on a different machine(also a virtual machine, on the same server).
IIS is monitoring the website's directory and automatically reloads changes.
The following command is run (directories sanitized): nunit-console Selenium-Project-Dir /labels
The tests are run on the Chrome webdriver.
The selenium project uses NUnit and WebRunner.
Driver instances are created once - before all tests, in a [SetUp] attribute inside a [SetUpFixture] class. They are deleted once, in the class's [TearDown] attribute.
A sample test looks like this:
[Test, Combinatorial]
public void AnExistingUserCanLogin(
[ValueSource(typeof(Drivers), "Good")]
IWebDriver driver)
{
// This function clicks on some buttons and fills in some forms.
LoginUser(driver);
// Make sure the user is now logged in
Assert.IsTrue(driver.ElementIsPresent(By.ClassName("imgUserAvatar")));
Assert.IsTrue(driver.ElementIsPresent(By.CssSelector("a.my-profile")));
Assert.IsTrue(driver.ElementIsPresent(By.CssSelector("a.logout")));
}
(The "Drivers" class contains lazily-instances webdriver instances of FF, IE, Chrome. You can guess what the "Good" static property of the class instances)
The fact that it is a VM should not be a problem, and RAM sounds like it is good. What OS is being run though? Some of the Windows OS have significant speed differences between the different bit versions (because of demands on hardware). This is especially noticeable in Vista but I have noticed a difference between Windows 7 and Server 2003.
I have found that there is a huge problem if the machine running the 64bit VM is a 32bit machine. It often seems to work well for a while and then as it continues to run tests will slow down. Which should be a duh but the main thing is that there may be too many VMs being run from the same place. Other programs will be affected by this and that can help troubleshoot if your VMs are on a company farm.
The other factor that has made a significant difference is if you are running the tests against different browsers. IE8 and IE9 will take the same selenium command and run them at different speeds. I don't know why this is, I just know that I have seen it. Make sure the staging machine has the current version of Chrome (or at least the same as your dev machine).
How the staging machine is networked to the database might be making a difference. This seems like a very small chance but if there is firewall crap between the two VMs that can have significant impact on time.
The only other thing I can think of that might be changing the length of time is if there are other programs being executed on the on the staging machine at the same time. Checking the CPU usage might helpful. Personally, I have noticed that my VM uses a lot more of the CPU than my personal machine. If this is the case the only solution I have found so far is to give the VM more processing power or to only run the test and nothing else.
Good luck!