I am creating an NFQUEUE with queue num 0 to receive the packet of the DNS Response and then I am changing the DNS response IP and push the changed packet again to the NFQUEUE.
Everything is working fine, But when my application is crashing, the Queue is bonded with the old PID and didn't clean up properly. So when I am running the application again, it's sometimes failing to create the new NFQUEUE and sometimes it succeeds (not sure exact scenario when it happens ).
Version Details:
kernel version:4.13.12
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION=Ubuntu 16.04.4 LTS
Can someone please help with the proper cleanup process.
As it is happening during the crash, I am not able to handle it.
nfq_close() and nfq_destroy_queue() are also unusable.
Related
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
I have "mariadb" set to 127.0.0.1 in my /etc/hosts file and sidekiq occasionally throws errors such as:
Mysql2::Error::ConnectionError: Unknown MySQL server host 'mariadb' (16)
The VM is not under significant load or anything like that.
Later edit: seems other gems have trouble resolving hosts too:
WARN -- : Unable to record event with remote Sentry server (Errno::EBUSY - Failed to open TCP connection to XXXX.ingest.sentry.io:443 (Device or resource busy - getaddrinfo)):
Anyone have any idea why that may happen?
I've figured this out a couple weeks ago but wanted to be sure before posting an answer.
I still can't figure out the mechanic of this issue but it was caused by fail2ban.
I had it running in a container polling the httpd logs and blocking the tremendous amount of bots scraping my sites.
Also I increased the max file handlers and inotify handlers.
fs.file-max = 131070
fs.inotify.max_user_watches = 65536
As soon as I got rid of fail2ban and increased the inotify handlers the errors disappeared.
Obviously fail2ban gets on the "do not touch" list because of this, and we've rolled out a 404/403/500 handler on application layer that pushes unknown IPs to Cloudflare.
Although this is probably an edge case I'm leaving this here in hope it helps someone at some point.
I have a storm cluster with 1 nimbus node and 3 supervisor node which are running on docker containers on AWS ec2 instances. I had a topology running with the number of workers equal to 3 and it ran perfectly fine. I stopped and removed this container and started a new one. After this, I seem to have the following error in the supervisor logs:
2016-10-03 21:18:22 b.s.m.n.Client [ERROR] connection attempt 129 to Netty-Client-hostname:6702 failed: java.lang.RuntimeException: Returned channel was actually not established
I have edited "/etc/hosts" to include the hostname as follows:
IP-address hostname
Yet, the problems seems to persist. Although, the same topology runs perfectly fine with the number of workers set to 1. Any pointers on solving this issue is appreciated.
The problem was with the hostname. I changed the hostname to match the DNS name by updating "/etc/hostname" as well as "/etc/hosts" and the rebooted nimbus instance followed by the supervisor instances. This fixed the problem. Hope this helps anyone who is stuck with the same problem!
Please check your supervisor log, sometimes you need to redeploy the app because supervisor has not started the topology yet.
I have a Rails 4.2 app running on Heroku. Occasionally there is an issue that causes most incoming requests to get a server error. For example, there could be a memory leak or a max database connection issue. How can I setup a script or service to automatically restart the server when it detects errors?
I think this service could ping the app every few minutes and if it detects an error, it should confirm there's really a problem and then run heroku restart. How could this be set up?
After Googling this topic, I came across Neptune.io, which seems to provide a useful service for this task.
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.