The server is cent os with apache2+php configured. Sometimes the pages are getting locked. Too much time to respond.
While checking htop in server found strange processess. All values are zero for this "sh" processes.
Can't find how it got created?
Related
I need some help with a really strange problem.
I use wget (busybox) to obtain the the IP address of some remote clients, to use it on a DNS (a sort of "homemade ddns"). Those clients run a script that every 5 mins calls
wget -O /dev/null "https://my_dns.org/poll.php?user=User_N&pwd=password_N"
Everything was fine, until I updated my http server to remove TLS1.0/TLS1.1
After updating: running the above command on the clients' console it still works OK, while running it automatically (launching it from a script in /etc/init.d) I get this error:
Connecting to my_dns.org (www.xxx.yyy.zzz:443)
wget: error getting response: Connection reset by peer
...Any idea about why does this happen, and how to fix...?
(The shell on the clients runs as root...)
Thank you in advance for your help
Regards
I've got problem with completing pgadmin4 installation thru sudo /usr/pgadmin4/bin/setup-web.sh command.
During this process instalator does not recognizing that Apache is running and asks me if I want to start it:
The Apache web server is not running. We can enable and start the web server for you to finish pgAdmin 4 installation. Continue (y/n)? y
Then it just spits some errors:
Too few arguments.
Error enabling . Please check the systemd logs
Too few arguments.
Error starting . Please check the systemd logs
So far I havn't found where the logs are stored.
About my apache, I am quite sure that my server is running, because I can connect to it through browser, phpmyadmin is working properly, and service apache2 status returns * apache2 is running. By my understanding apache2 is just fancy word for httpd service, and there is no other service called simply apache.
PostgreSQL seems to work properly from command line, haven't tested if I can connect to it yet, but this shouldn't be the case right?
I am using
**PostgreSQL:** 12.5 (Ubuntu 12.5-0ubuntu0.20.04.1)
**Ubuntu:** Ubuntu 20.04 LTS
**Server:** Apache/2.4.41 (Ubuntu)
I had the same issue for Debian 10 and Ubuntu 20. The /usr/pgadmin4/bin/setup-web.sh script is using 'uname -a' which doesn't contain "Debian" identifier in the return string. Updating this to read /proc/version will allow APACHE to be specified as the Debian variant of apache2.
Change:
UNAME=$(uname -a)
To:
UNAME=$(cat /proc/version)
I had a similar problem with Ubuntu running inside WSL 2. Managed to resolve it by modifying the /usr/pgadmin4/bin/setup-web.sh script. I moved these lines outside of the conditional:
IS_DEBIAN=1
APACHE=apache2
This allowed the installation to progress beyond the Too few arguments. error. There was still an error however:
System has not been booted with systemd as init system (PID 1). Can't operate.
Error restarting apache2. Please check the systemd logs
I resolved this by running:
sudo service apache2 restart
After this I tried bringing up the admin page by visiting http://127.0.0.1/pgadmin4 from the Windows host. This still didn't work, and had to connect using the Ubuntu machine's ip address (you can find it out via ifconfig) which finally allowed me to see the login page.
We recently did a GitLab upgrade from 11.x up to 12.9.2. It all went well; however, when I do gitlab-ctl pg-upgrade it shows the DB being 10.12. But when I do gitlab-rake gitlab:env:info it shows 10.7.
If I drop into gitlab-rails dbconsole it shows:
psql (10.12, server 10.7)
I didn't originally set this server or instance up. Any idea why it would be showing two different versions (does 10.12 mean the client is 10.12, the server is still 10.7?) Ideally the server would be 10.12.
Thanks for any help.
Answered my own question after further digging.
I ran a stat on /opt/gitlab/embedded/postgresql/10/bin/postgres and it showed that it was indeed changed when we did the upgrade.
Then I ran an lsof and saw that the postgres process had this binary open with a (deleted) marker, meaning it had the previous file still open in memory.
I ran a gitlab-ctl stop and a gitlab-ctl start and now it's showing properly when I do gitlab-rails dbconsole.
Should've done all that first!
I face a problem that I can ping to correct IP address, it have no loss. And also I use nmap ping the pi address, and I get it correctly. Then I using VNC viewer to try access to pi, but it always show up "The connection was refused by the host computer"
Did u all have any idea ?
Your problem indicates that your Raspberry Pi was reached by the connection attempt, but that no service was running on the relevant port and hence the connection was refused. I think, this is because the VNC service is not running on your Raspberry Pi.
Update 1
Raspbian now comes with the server by default thanks to a partnership with RealVNC, it just needs to be enabled.
Original
You must enable VNC Server on your Raspberry Pi using terminal
sudo apt-get update
sudo apt-get install realvnc-vnc-server
or you can also enable VNC Server on the command line using the sudo raspi-config command.
Advanced Options->VNC:Yes
Now you can connect to the VNC Server using a application such as VNC Viewer.
I have been having this issue with my Raspberry Pi Zero W even though it worked perfectly beforehand. This page https://www.realvnc.com/en/connect/docs/raspberry-pi.html should help.
I ran vncserver in a ssh window after verifying the interface settings in raspi-config.
It started the VNC Server and gave me the VNC Server catchphrase and the IP address with Port Number as shown in the photo linked below.
vncserver output
After running that command I was able to get the VNC Viewer on my windows machine to connect to the pi.
I then ran sudo systemctl enable vncserver-x11-serviced.service in the ssh window so that it would start automatically on subsequent reboots.
I've had this same problem but found a different reason. I found three ways to get around this error message.
Plug a mouse or keyboard into the Raspberry Pi zero, waking up the screen and the VNC connection.
Wait about 5 - 10 minutes which is the amount of time for the screen saver to kick in which seems to wake up VNC connection. but don't wait to long other wise run this command to get things going via ssh "systemctl start vncserver-x11-serviced.service".
I am hoping the new update they just published will fix this problem. I don't see this as much with the Raspi B3+ as with the Zero H.
The last was plug in both monitor and mouse and that for sure fixes the VNC issues but defeats the headless connection. It seems that running headless and the screen/saver are somehow related but just not smart enough to figure it out.
For people using newer version of Raspberry, VNC option is found under:
Config>Interface Options
pinging to any service will only tells us that whether the server is currently listening on that port or not. It will not tell you the possible result to connection request asked by client.
It seems that, you have installed VNC server but not started it properly. Use this command to start it...
# vncserver start
Also recheck the port number is correct or not.
With the Rasp Pi 4 - had connecting fail after rebooting both the server and client (both Rasp Pi 4s).
Took a while to realize that I have two clients: One named "VNC Client", the other "VNC Viewer for Google Chrome".
The former works, the latter doesn't.
Sometimes Xcode does not stop the debugging process properly and the only way to kill that process seems to be a reboot of the mac.
I can not kill it via shell command (kill -9, or actually sudo - kill -9). I also tried to remove the process from the launchctl table before killing with the command, which also does not work, the command returns 'No such process'.
Is there really no other way than rebooting the system in such a case??
Thanks.
Try looking here: Couldn't register with the bootstrap Server and here: iPhone - strange error when testing on simulator
I myself experienced this occasionally, but I've never managed to resolve it using any of the methods stated. Hate to say this, but I always end up restarting the Mac to fix it.