iOS sims hang up on session initialization - appium

I set the capability
"noReset": true,
but sometimes, my iOS sims hang up on sessions creation, and I have to kill and restart them. Anyone else have a similar experience? Any solutions?

Practically all my problems with the server errors and slow driver initializations and hang-ups have been solved by simply clearing the ports that the Appium servers and drivers use before initializing any new servers or drivers; on linux this has been accomplished by killing all the processes that use a port with this command:
lsof -i tcp:${PORT_NUMBER}| awk 'NR!=1 {print $2}' | xargs kill

I tried everything but only this helped.
Just add capability: waitForQuiescence = false

Related

How to stop Docker (and Kubernetes) using Docker desktop?

I'm running Docker Desktop for MacOS and I don't know how to stop the Docker service. It runs all the time using up the MacBook battery.
On a simple search, there are docs showing how to stop the containers but not the docker service itself.
I might be missing something obvious, but is there a way to stop both Kubernetes and Docker service without having to kill the desktop app?
The docker desktop app starts a qemu vm, so the desktop app has no control over the PIDs.
To oversome the "situation" do the following:
open the Terminal app
edit the file ~/.bash_profile
add the following lines
#macro to kill the docker desktop app and the VM (excluding vmnetd -> it's a service)
function kdo() {
ps ax|grep -i docker|egrep -iv 'grep|com.docker.vmnetd'|awk '{print $1}'|xargs kill
}
save the file
Quit the terminal app and open it again.
Type kdo to kill all the dependend apps (hypervisor, docker daemon etc.)
You can open the Activy Monitor, select Docker and then use the Quit button.
Maybe you will need to use the Force Quit option.
I had been searching around for an answer to this too, as I noticed com.docker.hyperkit was taking >3GB memory and a lot of CPU, when the desktop app wasn't even opened on Mac OS X Catalina, Docker Desktop 3.0.4
Just as I was about kill -9, I noticed that quitting the docker app again actually did kill off every process except com.docker.vmnetd for whatever reason.
So I guess the solution here was... reopen and re-quit? I also made sure, of course, there were no running containers. I removed an old image too, unsure if that was related to it finally being able to fully quit.
com.docker.hyperkit taked > 8GB Memory . just run in terminal kill -9 PID
ex my process kill -9 71397

How to stop Appium server programmatically and automated in Jenkins Pipeline

Appium server sometimes it does not stop when you try to close it, server and port is still hanging forever and the Appium CLI has no build-in command to stop the server which makes it harder to manage programmatically
Imagine that you want to manage it programmatically with the automation process in your CI/CD pipeline
such as Jenkins it could be a really painful story
appium
or
appium & (as background process)
The command to start Appium server that can be stopped only when you terminate it but sometimes it not stop
I've searched for the answer on StackOverflow for a long time and none of them answer directly to my question
So far what seems to work is that you have to kill the process of the server manually in the shell with the specific process id
To make it simply work with the pipeline, we could have a short version of the command
kill $(lsof -t -i :4723)
kill \$(lsof -t -i :${APPIUM_PORT}) [In Jenkinsfile]
Where the APPIUM_PORT is your Appium port, the default port is 4723
lsof command should work in Unix-like systems e.g. MacOS, Linux
lsof is a command meaning "list open files", which is used in many
Unix-like systems to report a list of all open files and the processes
that opened them
By running this command it should return an ID of the process running on that specific port to use for the kill signal
To implement in the pipeline
Add this step at the end of your Jenkinsfile
post{
always{
...
echo "Stop appium server"
sh "kill \$(lsof -t -i :${APPIUM_PORT})"
}
success{
...
}
failure{
...
}
cleanup{
...
}
}
It should kill the hanging Appium server process and you can start the new Appium server again with the same port!
To see more details on this I already publish a blog here
How to start/stop Appium server in Jenkins Pipeline
Hope it helps

How to stream multicast from pcap file (automation)

I have 3 pcap files - UDP, RTP and RTP with FEC. The last one means that I have 3 sockets that have to go at the same time for error correction.
I tried to use tcpreplay but it doesn't work if streamed inside of 1 machine which is the purpose. Docker won't work because of the same problem, virtualization could work but the Linux kernel I'm working with makes a huge problem so I'm looking for another tool like tcpreplay that would stream to localhost.
The solution is bittwist. bittwist.sourceforge.net
It requires libpcap-devel module from linux repos. Stream to loopback intarface.
Still would be happy to get to know any other solutions.
bittwist uses the same lib under the hood as tcpreplay. The actual solution was:
sudo sysctl -a | grep "\.rp_filter" | awk '{print $1 "=0"}' | xargs sudo sysctl

Using Instruments to launch automation tests via SSH

I'm currently trying to run iOS mobile functional tests from a CI server. Just so you know I'm using the Calabash framework but my problem is related to Instruments : Instruments doesn't launch the requested device.
When I use Instruments directly from the terminal on the server, everything goes fine (Instruments -w "iPhone 5s (8.1 Simulator)" for example). I get the following message :
Waiting for device to boot...
Instruments Usage Error : No template (-t) specified
instruments, version 6.1 (56160)
usage: instruments [-t template] [-D document] [-l timeLimit] [-i #] [-w > device] [[-p pid] | [application [-e variable value] [argument ...]]]*
However when I launch the same command from an SSH connection, it ignores the requested device and launches the device previously used. And this time it stays stuck at Waiting for device to boot...
Does anyone have an idea that could explain this behaviour ? Why would it work from a local session and not from a remote ssh connection, and how to fix it ?
I have Instruments in version 6.1, on OS X Yosemite.
Thank you.
Good question, I know that if the process being run is considered a background or system task it won't be able to launch instruments and run the test since it requires user level runtime status. I discovered this when trying to launch instruments from a cron job. When you ssh your shell thread may be considered system level. My only suggestion would be to put your commands in a shell script, and somehow call the script on a user-level thread. Unfortunately I am not a unix expert and cannot give you the specifics of how to do that, hope this helps.
Ran into the same thing. If you use Jenkins as your CI server, connecting your slave using JNLP Web Start instead of SSH will allow instruments to work as expected. Not an ideal solution for all configurations, but it does the trick.

Webrick will not stop or restart

I was running Linux Mint 13 prior to now, and just switched to Fedora 17. Since I have made the switch, I can no longer stop Webrick. I use Jetbrains Rubymine, and starting the server works fine, but as soon as I hit stop, or restart, it somehow detatches from the processes and I cannot use that port again until I reboot my computer. My first thoughts were that it was a problem with Rubymine, but when I start the server in a console, it does the exact same thing. I hit ctrl-c to stop it (and it appears to do so), but as soon as I go to start the server again on that port, it fails because of duplicate address in use.
I have this error on Mint (opposite to you, as I see) - Ubuntu machine always exits fine by CTRL+C. Solution without restarting your machine: kill Webrick process. Search for a PID of detached server process via ps aux | grep rails command and then kill it via kill -9 <PID>
In one line you can run this in your project dir:
kill -9 `cat tmp/pids/server.pid`
(You can also set this command as an alias in your .bash_profile, to use more easily)
Or is there no Webrick process to kill, whatsoever?

Resources