I have a python app behind supervisor and uwsgi.
At a certain point, my app stopped to answer the queries with this message in the logs:
Tue Sep 6 11:06:53 2022 - *** uWSGI listen queue of socket "127.0.0.1:8200" (fd: 3) full !!! (101/100) ***
In my use case,
If a query is not answered within 1s, the answer does not matter anymore; the client app will automatically re-do the request
restarting the whole uwsgi takes around half an hour
Thus I prefer to lose few requests than restarting.
QUESTIONS :
Is it possible to detect a full queue from inside the python app ?
Is it possible to clear the queue from inside ?
Precision: this question is not about fixing the underlying issue. I'm working on that separately. It is only about knowing if this particular workaround is possible and how to implement it.
I'm using uwsgi 2.0.20. Looking at the queue framework does not help since uwsgi has no attribute (e.g.) queue_slot. Doc outdated ?
EDIT
I can reproduce the error with this simple bash script:
#!/bin/bash
for i in {0..200}
do
echo "Number: $i"
sleep 0.2
curl -X POST "http://localhost:1103/my_app" &
done
(my app accepts POST, not GET)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
I deployed my vapor project to Ubuntu. And made the configuration of supervisor and Nginx.
When I invoke my server. first call is success but When I try second call I get 502 bad gateway error from browser. When I check error log, the error is
"Fatal error: Error raised at top level: bind(descriptor:ptr:bytes:) failed: Address already in use (errno: 98) : file /home/buildnode/jenkins/wo$"
If I kill the port(8080) process. And after, I try to connect again first try is success then get fail again.
What should I do to get rid of this error?
This might be caused by another process using that port.
I had the same issue and was able to solve it by listing all the processes on port :8080:
$ sudo lsof -i :8080
and then killing all of them one by one by typing:
$ kill {PID of the process}
After that, my app built again properly.
taken from here
I had the same issue. This worked for me:
$ kill -9 {PID of the process}
Hope this helps!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
**Problem: **
The result must be a working translator - offline.
We need http API (self-hosted) similar to Google Translate.
I found a few options:
Install Microsoft Translator on Windows, download dictionaries, and somehow through http transfer requests for translation there
Apertium, this option is closer to reality, but it’s not clear how to set everything up ...
Apache Joshua
Promt, it is perfect but it is very expensive
Install Android on PC, and there is already Google Translate, but again there will be a question of sending http requests
**Todo: **
We need to translate whole sentences, not just individual words.
Maybe there is some kind of command line utility. Or maybe there is something for linux.
Which of the above options is better to look for more information?
The five-minute solution is to do this on Debian or Ubuntu:
sudo apt install apertium-apy # http server for apertium
sudo apt install apertium-eng-spa # install some language data
sudo systemctl enable apertium-apy # start http server on next boot
sudo systemctl start apertium-apy # start http server right now too
You now have translation between English and Spanish that responds to http requests and answers in JSON:
curl 'http://localhost:2737/translate?langpair=spa|eng&q=Eres+la+leche'
You can see all the apt-installable Apertium language pairs with
apt-cache search apertium |grep 'pair$'
If you want more pairs in Apertium, you could try the adding the nightly apt repo with unreleased data (or consider Contributing your own language data).
However, you tagged this neural-network – if you want NN's, or more language pairs than Apertium has, you could train a translator with OpenNMT and data from e.g. http://opus.nlpl.eu/ , but that will definitely take more than five minutes :-)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 10 months ago.
Improve this question
I am new to CentOS 7 and I am configuring a static IP on CentOS 7, so I have edited the file /etc/sysconfig/network-scipts/ifcfg-eth0 as following:
TYPE=Ethernet
BOOTPROTO=none
Device=eth0
ONBBOOT=yes
IPADDR=192.168.4.196
NETMASK=255.255.255.0
GATEWAY=192.168.88.254
DNS1=8.8.8.8
USERCTL=no
But when I issue the command
systemctl restart network
I am getting the error
failed to start LSB :/Bring Up down Networking
ip route show gives me no output.
I have applied the solution that stops NetworkManager with the same existing error.
I am able to configure a dynamic DHCP and get a dynamic IP address but not static one.
What can be possible solutions?
Its because of interface issue
Solution worked for me was:
Check the interface available
cp ifcfg-eno16780032 ifcfg-ens192
vi ifcfg-ens192 and change NAME and Device field to ens192
systemctl disable NetworkManager
systemctl status NetworkManager -> inactive
systemctl stop network
systemctl start network
After that check ip a
get the details of IP and able to ping that IP.
You should change BOOTPROTO to static and move your DNS config to your /etc/resolv.conf file, for example:
TYPE=Ethernet
BOOTPROTO=static
PHYSDEV=eth0
ONBBOOT=yes
IPADDR=192.168.4.196
NETMASK=255.255.255.0
GATEWAY=192.168.88.254
USERCTL=no
When facing this issue that derailed proper autossh functionality on my roaming laptop, I decided to rip apart whatever of my MageiaOS code to understand the root cause. I did not have NetworkManager, so knew for sure it was not the obstacle.
The found issue could be described as kind of eventual live-lock between SysV and systemd ways of managing network service. Potentially, many conditions could trigger it (NetworkManager is one of the examples), in my case it was misconfigured vboxnet ifaces from VMWare.
There're two critical blockers in each part of SysV/systemd balance that might start triggering each other in the loop. On SysV side, init.d/network script eventually calls "ifup $device boot", which in response of 'boot' parameter starts ifplugd daemon for pluggable ifaces. The problem with this daemon that despite of '-I' switch (used to ignore errors) it still fails with exit code 4 upon detecting itself in memory. The only proper way to shutdown this daemon from network script is issuing "ifdown $device boot" command, which is supposed to get executed upon stopping network service by 'service' or 'systemctl' commands.
The interesting part of this question: why ifplugd is already in memory before the network service starts? Well, in my case WiFi iface was fired before misconfigured vbox iface but the latter caused entire initscript to fail. So, network was started on boot but service status was recorded as failing. But what prevents us just stopping network service and consequently killing ifplugd from ifdown/boot command? The answer is: systemd in its ingenious ways of handling ExecStop directive in unit file (which is auto-generated on the fly for network service). Basically, "systemctl stop" command just ignores ExecStop directive if it believes that the service is not started. Well, of course it is not because... if previously failed stumbling on unexpected ifplugd instance! So, no way to stop the service, hence no way to get rid of ifplugd, hence no way of (re)starting the service and so on.
Conclusion. There's no single recipe for this sort of trouble because the compatibility balance between network script and systemd approach is very fragile, so many unexpected factors can start interfering. To troubleshoot this scenario, several statuses might be useful:
network service: systemctl status network
ifplugd service: ps ax|grep ifplugd
network link status: ifconfig / iwconfig
autogenerated unit: cat /var/run/systemd/generator.late/network.service
other places running ifup independently: grep -rs ifup /etc
and of course, "bash -x" and debugging "echo Bump" instruction. :-)
Long-term solution is fixing ifplugd to honour '-I' switch in this scenario. Mid-term solution is fixing /etc/sysconfig/network-scripts/ifup-eth for ignoring ifplugd return code. Short-term solution seems to be the most tricky, which is just removing all possible config factors triggering this live-lock. But this is the only one tolerating system autoupdates...
Execute tee /etc/modprobe.d/*blacklist*.conf <- "blacklist ideapad_laptop"
Then reboot. This should unblock your Wi-Fi.
I came here looking for a answer to my case so I'll share, maybe it will help someone else. I'd like to thank cPanel staff for pointing this out to me
As for the reported issues, we have seen the CloudLInux servers running a kernel version lower than "3.10.0-862" and update to Cloudlinux 7.7, they will get an update to the 'iproute' package.
The 'iproute' package needs to wither a newer kernel or to be excluded from updating onto the server initially.
This information has been reported. You can find some more information about it here:
https://www.cloudlinux.com/cloudlinux-os-blog/entry/cloudlinux-os-7-7-released
In my case
journalctl -xe
Shows there was a duplicate interface configuration eth0 & eno1 using the same UUID:
Nov 06 09:35:41 4200-150-137 /etc/sysconfig/network-scripts/ifup-eth[27549]: Device eno1 does not seem to be present, del
Nov 06 09:35:41 4200-150-137 network[27401]: [FAILED]
Nov 06 09:35:41 4200-150-137 network[27401]: Bringing up interface eth0: [ OK ]
removing the unused interface ifcfg file solved the problem for me.
After several trials including restarting of network manager, commenting out the UUID on the interface concerned (mine being ifcfg-eth0), it finally boiled down to a missing file which apparently needs to be included despite the fact that its values can be included directly in the interface file.
vi /etc/sysconfig/network
then add your right values and save:
NETWORKING=yes
HOSTNAME=xxx.xxx.xxx
GATEWAY=x.x.x.x
I hope this helps someone. It is tested on CentOS 7 as a guest VM on Hyper V on Windows 10.
I have VPS with OVH and have been struggling with similar issue.
Just wanna share my solution as it can help some people.
It used to delay boot by 5 minutes, dhclient was checking ipv6 on ifup call.
Set this to no
DHCPV6C=no
inside /etc/sysconfig/network-scripts/ifcfg-eth0
I know this is an old discussion but i had this problem on my bare metal server from ovh after disable NetworkManager service by installing CPanel
This issue solved by adding bellow parameters' in ifcfg-eno1 (or in your case any active interface)
LINKDELAY=31
NM_CONTROLLED=no
ONBOOT=yes
DHCPV6C=no
Also note that you have activated the network service
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I have a general question. How does one start a systemd unit *.service after a particular *.service has started successfully?
More specific question is, how do I start website.service only after mongodb.service has started? In other words website.service should depend on mongodb.service.
In the .service file under the [Unit] section:
[Unit]
Description=My Website
After=syslog.target network.target mongodb.service
The important part is the mongodb.service
The manpage describes it however due to formatting it's not as clear on first sight
systemd.unit - well formatted
systemd.unit - not so well formatted
After= dependency is only effective when service including After= and service included by After= are both scheduled to start as part of your boot up.
Ex:
a.service
[Unit]
After=b.service
This way, if both a.service and b.service are enabled, then systemd will order b.service after a.service.
If I am not misunderstanding, what you are asking is how to start b.service when a.service starts even though b.service is not enabled.
The directive for this is Wants= or Requires= under [Unit].
website.service
[Unit]
Wants=mongodb.service
After=mongodb.service
The difference between Wants= and Requires= is that with Requires=, a failure to start b.service will cause the startup of a.service to fail, whereas with Wants=, a.service will start even if b.service fails. This is explained in detail on the man page of .unit.