I'm running Appium 24/7 on a Windows machine to perform automated tests. I'm running these tests via AVD on an emulator with Android 10. For my test, I give the correct Capabilities and runs functionally great. But after a few hours/days I get the follow error:
UnknownError: An unknown server-side error occurred while processing the command. Original error:*Cannot find any free port in range 8200..8299}. Please set the available port number by providing the systemPort capability or double check the processes that are locking ports within this range and terminate these which are not needed anymore at getResponseForW3CError at asyncHandler.
When my code is executed, I make sure the finally in try executes the AppiumDriverLocalService.stop(); method to kill Appium. My feeling says this does somehow not free up any ports for UIAutomator2 (which you can configure, but I have not configured, through systemPort capability.
} finally {
driver.closeApp();
service.stopServer();
System.exit(0);
}
Why does Appium not free up any ports for UIAutomator2 in the range 8000-8299 after stopping the service?
Android Debug Bridge version 1.0.40
Appium version 1.20.2
Android 10
PS I know of the adb command adb -s $UDID forward --remove-all but does this solve the real issue, I don't want to execute a Java Process each time
Update - Fix 2-3
I have fixed the issue by changing the finally clause to execute the following methods in order:
} finally {
AndroidDriver.quit();
AppiumDriverLocalService.stopServer();
In order to free up the port 8200..8299, AndroidDriver must be quit as UIAutomator2 is linked to this. The AppiumDriverLocalService will kill/forward/free this port and UIAutomator2, after this I can freely stop the server:
[ADB] Removing forwarded port socket connection: 8203
This issue is a good example of your problem. As you can see, Appium team is closing it as a Not A Bug.
Reason is obvious: Appium is not responsible for managing ports, it relies that your system has some free in required (by Appium code) range.
systemPort is used to connect to appium-uiautomator2-server, by default is 8200. Basically Appium selects one port from 8200 to 8299 for appium-uiautomator2-server. However, when you run tests in parallel, you must adjust the port to avoid conflicts. If you are not, you should be safe in 99% cases with the default.
Restart the system (assuming it will clear ports) and run tests. Check Appium server logs for any errors on closing session. It could be that issue is related to ADB setup or permission issue, and UI2 server is not stopped properly.
If so, port remains in use. And it is not Appium to deal with cleanup. I'm not sure that adb command you mentioned is a good 100% guaranteed way to do it.
I would just add a shell script that is executed before Appium server start to clean ports in 8200-8299 range and forget this problem.
killall -9 node - to kill all appium running internally and at root level
and adb kill-server - to kill the abd server by running this it resolved the above issue for me , hope may help someone
Related
After upgrading Docker to 4.6.0 on OSX 12.3 I've had a bit of an odd issue when I stop the xdebug listening client in PHPStorm, it seems that subsequent requests always times out because docker is reporting that host.docker.internal has port 9003 open when it's actually closed so the app always waits for the xdebug client.
I installed nmap on my webapp php container and host to test. If I run "nmap -p 9003 localhost" with the debug client running on my host I can see it open, after turning it off in PHPstorm the same scan shows that it's closed however running "nmap -p 9003 host.docker.internal" inside the container reports that it's still open. If I open other services on my host too it seems that ports start showing as open on the docker internal network however never report as closed after shutting them down on the host.
I upgraded to Docker 4.6.1 but the problem still persists.
Any advice would be appreciated.
This has been fixed in Docker 4.8.1
https://docs.docker.com/desktop/mac/release-notes/
UPDATE: Downgrading to Docker 4.5.0 resolved the issue.
This doesn't solve the problem, just helps to avoid restarting Docker while we are waiting for the fix.
Make changes in xdebug.ini:
xdebug.start_with_request=trigger
xdebug.idekey=VSCODE
This tells XDebug to connect to debugger only if "trigger" is present in the HTTP request.
Now, install Chrome extension Xdebug helper, it's old but still works. Open extensions settings (chrome-extension://eadndfjplgieldjbigjakmdgkmoaaaoc/options.html) and set IDE key to "Other" "VSCODE".
Now, when you want to debug, you enable debugging in VSCode and also enable debugging in Chrome using that extension:
When you are done debugging - choose "Disable" in the extension, and PHP won't try to connect to your debugger, even if the port is still open. How it works - extension just sends cookie XDEBUG_SESSION=VSCODE with each request, and XDebug connects to the debugger only when this cookie is present.
P.S. You can replace VSCODE with IDE key that your IDE uses, or just any string.
I have tried to restart the server with npm start, npx react-native run-ios, npx react-native start. Those commands don't work for me. Help me out to run this project its a project created with npx react native init projectName.
warn No apps connected. Sending "reload" to all React Native apps failed. Make sure your app is running in the simulator or on a phone connected via USB.
The error shown on the emulator
Run adb reverse tcp:8081 tcp:8081 in your terminal then reload in the terminal after running yarn start or npm start, then reload. I hope this is helpful.
I had the same problem and spent hours working on it. I figured out that METRO which is run using this command: npm start or this one npx react-native start couldn't find its way to my mobile app.
one of the solutions that I wasn't totally pleased of was this: a solution that works but has flows
but that workaround wasn't perfect because I had to re-run the command every single time I make a change. So after further researches I found out that the port 8081 is used by an another application that METRO is sending information to ( this is only my guess ). so:
I run the following:
netstat -aon | findstr 8081 // to get the PID of the application that is running on 8081 port
I opened task manager ( CRTL + ALT + del ) under the service section I looked up any
application which uses the PID that matches the one given by the command I ran and I have
forced stopping it.
retried npx react-native start and npx react-native run-android on my project
and the magic happened. It auto refreshes with every change, I wish it helps you.
This is from the docs:
Method 2: Connect via Wi-Fi
You can also connect to the development server over Wi-Fi. You'll
first need to install the app on your device using a USB cable, but
once that has been done you can debug wirelessly by following these
instructions. You'll need your development machine's current IP
address before proceeding.
Open a terminal and type /sbin/ifconfig to find your machine's IP address.
Make sure your laptop and your phone are on the same Wi-Fi network.
Open your React Native app on your device.
You'll see a red screen with an error. This is OK. The following
steps will fix that.
Open the in-app Developer menu.
Go to Dev Settings → Debug server host for device.
Type in your machine's IP address and the port of the local dev
server (e.g. 10.0.1.1:8081).
Go back to the Developer menu and select Reload JS
My setup:
Opertaing System: Windows 8.1
Memory: 16GB
HD: 500GB
etc. non relevant.
Issue:
I noticed the issue when my printer stopped working after a normal restart. At that point I tried to uninstall and reinstall the printer driver. The install failed.
At that point I also realized all my remote desktop connections were also failing, with not being able to find the remote host.
Here is the error I was seeing when install for the printer was failing:
can't start printer spooler service not enough resources are available to start the service
Manually trying to start the spooler service and checking in the event Viewer of windows showed that it was failing on:
Failed to schedule Software Protection service for re-start at 2014-09-13T08:09:30Z. Error Code: 0x80040154.
Further trying to restart the protection service revealed that it was failing on:
Task Scheduler service has encountered RPC initialization error in "RpcServerUseProtseq:ncacn_ip_tcp". Additional Data: Error Value: 1721.
In either case my computer had become somewhat useless as I couldn't install anything and my printer and remote desktop was broken too.
Reporting the problem just in case if someone has a similar issues.
The resolution for my problem is actually posted here, but way back so bringing it to more light:
http://social.technet.microsoft.com/Forums/windows/en-US/0c438376-1486-4ae4-9847-2de7a8767f27/task-scheduler-service-has-encountered-rpc-initialization-error-in?forum=itprovistasp
For me what worked was just to starting the prompt in adminstrator mode, running:
netsh winsock reset
and restarting my machine.
Not exactly certain of what actually fixed the issue.
I have a mac and I'm trying to run Appium to run iOS tests.
I'm using the Appium app for this, I looked on the troubleshoot section and I think everything is setup as it should, but the app give me this error:
"Couldn't start Appium REST http interface listener. Requested address is not available"
Someone know how can I fix this issue?
It seems that from error you are using the IP address or port number that is used by another process in the system, Simply kill that process that using the same port number that you are using or try to give following IP address and port number
1. IP address : 127.0.0.1
2. Port number : any thing that is not in use say 5000
I changed the ipaddress to the systems current IP address and changed port to 4725 and it worked fine
If appium is having that issue i think its from the IP address you are setting it to. You might have more than one instance running by accident, or you simply need to give it a different IP and port number when configuring.
Start the Windows Task Manager by pressing ctrl+alt+del (or open up Activity Monitor on your Mac). Under Processes tab kill the node.exe process. Try to start the Appium server again.
Solution from SO post : Appium: Couldn't start the appium server in Windows
I have the following case:
Two applications (mine and 3rd party) on iOS need to communicate over TCP/IP
I can change the code of my app, but not the 3rd party app
The protocol can't be changed (because I can't change the 3rd party app).
In my app, I want to make sure that I talk to the correct app.
I know how I can get peer port with geetpeername
What I am looking for is a way to figure out the pid of the process which uses this port.
I found similar question: How do you determine the PID of a peer TCP connection on the same iOS device?
However, in his case, both ports are in the same app.
Disclaimer: I am fine with private API. It won't be sent to AppStore. However, I am looking for a solution for non a jailbroken phone.
Update 1
I said that I need PID, because there are known ways of getting association between PID and application bundle id (using sysctl).
Generally speaking, I don't care about PID per se. My concern is figure out what is the application on other side of the socket.
I don't have a solution for this, but if I was going to try to do it, I would proceed in the following way:
On a UNIX system, you can use the lsof command to determine which processes have which files open. This includes sockets, and lsof allows you to determine the pid of a process using a given port. For example, use
lsof -n -P -i :443
if you're trying to determine which process is using port 443 (HTTPS), which might yield (on OS X):
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
firefox 81615 myname 112u IPv4 0xffffff8017379a40 0t0 TCP 192.168.2.7:52521->74.125.28.103:443 (CLOSE_WAIT)
The open source version of lsof for Darwin, I believe, can be found here. So you might try starting with main.c, and using those command line arguments, navigate through the code until you find the system calls that are used.
It's certainly possible that the calls needed will not work when run in a process with user mobile privileges. But, maybe not? If there's a security check inside the lsof source itself, then you can certainly remove that, if you copy and paste the source yourself.
Anyway, it might be worth a try, if no one offers another answer.
Note: lsof is available for jailbroken phones, and I just tried running the current versions available from Cydia. They did not work for me, on 5.1.1 or 6.1.2. Not sure why. I assume that if they were on the repository, though, at some point, someone was able to port lsof to iOS.