I'm not sure what is going on, but every time I run my application (vb.net) Chromedriver eats disk space. I even added another 40GB (Virtual Machine) and now that is gone!
I'm doing the typical:
Dim driver as ChromeDriver = New Chromedriver
driver.Navigate.GoToUrl.....
both on form load, essentially. I constantly re-work the code, so I exit out and have to manually close the console window, maybe that is causing the issue. Will have to put some ChromeDriver destroying instead of letting garbage collection manage that.
HOWEVER:
Where are these files so that I can delete them?
Most likely the files are folders named scoped_dir* inside C://Users/user/AppData/Local/Temp. You can type %APPDATA% in the search window on your taskbar to go to AppData folder and then remove those scoped folders.
Related
We have our Health Check automated wherein all of our applications are logged onto, all via Selenium and only on Internet Explorer.
The code runs well when it was executed directly from a batch file. However, when Jenkins calls this batch (.bat) file, it doesn't execute it completely.
BTW the platform is Windows Server 2008 R2 Standard
This is the .bat file code
#echo off
set path="";
set path="E:\XXXX\jre1.8.0_141\bin";
pushd E:\Jenkins_Softwares\SeleniumCode\HealthCheck_jar
SET JAVA_OPTS=-Xmx4g -Xms512m -XX:MaxPermSize=256m -XX:ReservedCodeCacheSize=128m -XX:MaxHeapSize=512m
java -jar HealthCheck_JenkinsNG.jar
I've added these additional IE options in the JAVA code before launching the IE driver.
InternetExplorerOptions options = new InternetExplorerOptions();
options.introduceFlakinessByIgnoringSecurityDomains();
options.enableNativeEvents();
options.destructivelyEnsureCleanSession();
When Jenkins executes the batch file, the IE browser opens into the Login page. There's something odd when this page is displayed - the entire page alignment is disrupted and all elements get aligned to the left. (I'd like to stress that when the batch file is instead executed directly, there is no such page alignment disruption. The elements retain their original centre position. For some reason, Jenkins sets all of this to the left). The alignment is not exactly a deal breaker for me.
However, when username and password is entered via the Selenium code, it types into the perfect text boxes; but when the submit button is hit, the content in these textboxes turn blank and I'm unable to login. (When this same piece of code is executed via running the batch file directly, I'm able to login and The homepage of my application is displayed)
I doubt if there's something wrong with the selenium java code. Since, it executes properly, when run from the .bat file or even command line or even as a Java Application from an IDE.
For some reason, when this is executed from Jenkins it does not work.
Is there any options or settings that needs to be set when Jenkins works with Selenium on IE 11? Because I've tried tweaking the selenium code so much, they all yield the same result - The elements on the Login page get cleared after the submit button is clicked.
Also, just to mention, all of this is run on one Master node of Jenkins only. There are no slave nodes.
You need to take care of a couple of things as follows:
For the build process Jenkins would need the path of jdk. Simply jre may not suffice.
JDK 8u141 is ancient now and you need to upgrade to latest JDK 8u202
introduceFlakinessByIgnoringSecurityDomains() (in Java) and IntroduceInstabilityByIgnoringProtectedModeSettings() (in DotNet) is not an ideal solution to address the issues croping out of Protected Mode settings.
Here you can find a detailed discussion in Internet Explorer Protective mode setting and Zoom levels
To work with Selenium, InternetExplorerDriver and InternetExplorer you need to fulfill the Required Configuration
Each time I run my selenium script, which uses a Chrome Webdriver, I find that at the end of the execution, I have significantly (~50 Mb) less memory in my drive. I am not pulling/storing data anywhere, I am just instructing it to complete a series of clicks to navigate some UI, so why would this be happening? I suspect that is has to do with my webdrivers never actually quitting, but I'm not sure why that would be the case? If I close out of the chrome page being run by selenium prematurely, I'm assuming the driver closes too? And in the case where it does conclude running, I explicitly program the driver to quit.
Additionally, I can no longer open chrome through my desktop. It simply won't start.
Can someone give me some advice or enlighten me about what is actually taking place behind the scenes to cause this problem?
When execution starts chromedriver creates some temp directories in this location :
C:\Users\username\AppData\Local\Temp
these directories starts with name like "scoped_dir8952_11195" and every directory created by chrome in temp folder starts with "scoped_dir".
when driver.quit() or close() is called it should be deleted but if it is not getting deleted then you have to delete it after execution using java code or you can simply create a .bat file that deletes the directories starting with name "scoped_dir" and then can execute it using ProcessBuilder or Runtime.exec() .
You can also manually delete them if you want.
Hope that helps you.
It seems that I've run out of room on my Master node and I need to clear some space in order to reboot my daily tests. Selenium.log is taking up a lot of space and I'm convinced its not currently being used. Would it be safe to delete?
Edit: I deleted the file and upon starting a new build Selenium created a new log file. I didn't experience any issues during this new build either.
You don't say what creates the file, or where it is, but assuming that you can already see the important details from each build in the Jenkins UI (e.g. in the console log, or in test results etc.), then you shouldn't need to keep any files that are sitting in the workspace or elsewhere.
I am using Oracle Virtual Box version 4.2.16 r86992. Everything was fine until yesterday shutdown.
Today, it shows inaccessible and throws this error:
Runtime error opening C:\Users\xxxxxx\VirtualBox VMs\vBoxxxxXubuntu_Beta\vBoxxxxXubuntu_Beta.vbox for reading: -102 (File not found.).
D:\tinderbox\win-4.2\src\VBox\Main\src-server\MachineImpl.cpp[725] (long __cdecl Machine::registeredInit(void)).
It's good to restore this to working, It would save lot of time and restore configuration settings and data. Thanking your support.
This normally happens if the host OS crashes or you pull the plug on it, leaving the .vbox file unsaved.
In the location:
C:\Users\xxxxxxx\VirtualBox VMs\vBoxxxxXubuntu_Beta\
you should find two files:
vBoxxxxXubuntu_Beta.vbox-prev
vBoxxxxXubuntu_Beta.vbox-tmp
Copy vBoxxxxXubuntu_Beta.vbox-prev to vBoxxxxXubuntu_Beta.vbox.
Select vBoxxxxXubuntu_Beta.vbox, in the VBox manager, right click, and then left click on refresh.
Observe that it now shows Powered Off.
Now you are good to go.
Based on my experience, I was on Windows 7 and running Ubuntu 14.04 as guest OS on Virtual Machine.
Go to your Virtualbox folder (in my case):
C:\Users\Dev12\VirtualBox VMs\Ubuntu
You'll see files with extensions: Ubuntu.vbox-tmp or Ubuntu.vbox-prev
Remove -tmp from file name Ubuntu.vbox-tmp so that it reads as Ubuntu.vbox
Exit from Virtual Machine and start it again.
You should now see error gone away.
The virtual box files with extension .vbox contain metadata the virtualbox hypervisor requires to resolve the guest virtual OS' configuration.
If the main .vbox file is corrupted (i.e. reporting that it is empty) then use the backup .vbox-prev file to recover the contents of the original file.
Do this by renaming the empty .vbox files a temporary name (e.g. rename originalVM.vbox to originalVM-empty.vbox).
Then make a copy of the backup file originalVM.vbox-prev, where the copy will have the same name as the original but with the word "copy" appended to it (i.e. originalVM.vbox-prev is renamed to originalVM (copy).vbox-prev).
It is important to retain the original backup .vbox-prev file it should not be altered or itself renamed.
Now go rename the copy of the newly created .vbox-prev file originalVM (copy).vbox-prev to the original name of the empty .vbox file and be mindful to also change it extension from .vbox-prev back to just .vbox.
That is rename originalVM (copy).vbox-prev back to originalVM.vbox. Now that this is done you may add the .vbox file (guest os) back into the VBOX hypervisor. This will recover the state and snapshot of the "inaccessible" guest VM. Now delete the original empty .vbox file.
I've faced the same issue using CentOs 6.8 on a VirtualBox 5.1 installed in Windows 7 and AjayKumarBasuthkar's solution worked perfectly for me:
I went to C:\Users\\VirtualBox VMs\CentOS6.8
Made a copy of the file CentOS6.8.vbox-prev and gave it the name of CentOS6.8.vbox
Went to the VirtualBox GUI, right-clicked the VM instance and hit refresh
The CentOS instance went from the State Inaccessible to Powered Off
VirtualBox 4.3 is released and could it be that you've updated or there was some issues while updating?
In any case if you are not able to bring up the Virtualbox, remember to backup the VirutalBox VMs folder and going for a fresh install should be the best way forward.
I faced the same problem and I resolved by doing following in Oracle Virtual box 4.3.28 with Ubuntu 14.04 LTS, when Virtual box VM was closed.
Removed ubuntu.vbox to another folder outside virtual box folder
removed -prev from file ubuntu.vbox-prev
start oracle virtualbox, it works excellent.
On a Windows 7 Host, I found that Daemon Tools service had a hold on the file.
The solution was to uninstall Daemon Tools, but I suspect if you stop the service and remove the file association, you would be sorted.
The other issue might be that if your Virtual Machine was on an external hard drive, it is possible that the drive letter has changed. If so, go to Computer Management, and select the hard drive and right click to change the drive letter and save (Note that this is for Windows).
This is going to sound stupid but try to reinstall VB. It may work.
I am adding one critical and important comment to the previous great answers. Make sure that the original .vbox file is corrupted and empty before you copy the content from the.vbox-prev file. If it is not the case and you find it with lines and readable content, don't replace the content of the .vbox.
Changes made to the VM directly before the VM got inaccessible might not be updated in the .vbox-prev backup file . The changes could not be synced with those changes before the OS upgrade or system changes that led to the inaccesable issue.
If you find your VM not accessible after an OS upgrade or system change, first check the.vbox file if it is still readable by a text editor and it has lines. Then you just need to delete the VM from the VirtualBox manager list(just remove the appliance from the list and don't remove files) . Then reopen the.vbox file and it should work perfectly.
If the original.vbox file is corrupted or empty when you open it with a text editor, then and only then, you can copy the content from the .vbox-prev and follow the instructions highlighted.
This was my experience, and I wanted to share it with you to avoid losing some last minute changes before the OS upgrade or crash.
While developing a Cocoa application on 10.9, I have noticed that if I go to ~/Library/Preferences and delete the plist file for my app (to reset it), on the next build-and-run, the app behaves as if the plist file had never been deleted at all.
It took me a long time to track down why this happens and I did not see a question/answer about it on SO, so I'm writing this question and answering it myself to help others.
On 10.9, the system is doing some more robust "caching" of preferences. After deleting the plist file, I fired up Activity Monitor and force-killed the "cfprefsd" process. Be careful: there are multiple processes with this name running and you only want to kill the one running under your own user; do not kill the one running as root.
Doing this seems to flush the preferences cache and on the next run of my app, I get a pristine start-from-scratch launch.
Edit: As reported below, using defaults delete [your bundle identifier] at the command line also appears to eliminate the caching issue. I've had mixed success with this.
I found out that killing the user process cfprefsd will reflush the cache, so your changes will be kept
killall -u $USER cfprefsd
In terminal:
defaults delete com.somecompany.someapp
BTW, I've just released a GUI app that may be more convenient than working with the defaults command:
http://www.tempel.org/PrefsEditor
It works practically the same as Xcode's plist editor, but affects the user's app preferences directly.
To delete all your prefs, you could open your prefs in my Prefs Editor, Select All, then delete them with the Backspace or Delete key, and they're instantly all gone.
However, for this particular task, using defaults delete might still be quicker, especially if you put the command into a text file ending in ".command", and make it executable (with chmod +x). Then you can double click it from the Finder to execute it.