I've got an old passivley cooled Pentium II box which I am turning into a silent File/Backup server for our LAN at home. Naturally for stability and performance on old hardware, I am running Linux.
The problem I have is that when you reboot the machine, it ends all processes, unmounts etc as usual, but after that the screen just blacks out and it doesn't go anywhere. I have to physically reboot the machine.
During startup theres a message saying BIOS is earlier than 1999, you should set ACPI=FORCE in Grub. I added this and also tried the noacpi and noacip options to no avail.
Windows ran on this fine before so I don't see why Linux would have an issue.
When I type a command with putty, the connection is closed immediately. I tried shutdown-r now and reboot, halt, do nothing to console closes and nothing happens.
After a hundred connection, I can use ls, su and kill.
I think it's the fact that the partition is corrupted. I can not Hardware reboot the server because CTN1 is "out of business".
VPS isn't rebooting by itself when it goes down. Anyone has any program/script that monitors heartbeat of the server? Like when it goes down, the program will automatically reboots the system. I know there's such a script out there but I forgot what it called.
I had to reboot my server and about 20 minutes later I tried to access the web site but the page was not found... I am able to login to SSH. However, I am not familiar with *nix or the workings of CPanel... What should I do to get the sites back online?
so my server dies every day and requires human intervention to fully restart all service to have my site work properly. i suspect sigterm issues as it fails to restart all service as website is still down so i always have to reboot it.
Tried recompile apache with no success [Tue Mar 18 06:51:27 2008] [error] [client 203.160.1.39] request failed: erroneous characters after protocol string: If-Modified-Since: Wed, 21 Nov 2007 06:16:52 GMT [Tue Mar 18 10:03:18 2008] [error] Bad pid (7465) in scoreboard slot 16 [Tue Mar 18 10:03:18 2008] [error] Bad pid (27848) in scoreboard slot 17 [Tue Mar 18 10:03:18 2008] [error] Bad pid (27434) in scoreboard slot 18 [Tue Mar 18 10:03:18 2008] [error] Bad pid (30782) in scoreboard slot 19 [Tue Mar 18 10:03:18 2008] [error] Bad pid (7465) in scoreboard slot 16 [Tue Mar 18 10:03:18 2008] [error] Bad pid (27848) in scoreboard slot 17 [Tue Mar 18 10:03:18 2008] [error] Bad pid (27434) in scoreboard slot 18 [Tue Mar 18 10:03:18 2008] [error] Bad pid (30782) in scoreboard slot 19 [Tue Mar 18 10:03:18 2008] [error] Bad pid (7465) in scoreboard slot 16 [Tue Mar 18 10:03:18 2008] [error] Bad pid (27848) in scoreboard slot 17 [Tue Mar 18 10:03:18 2008] [error] Bad pid (27434) in scoreboard slot 18 [Tue Mar 18 10:03:18 2008] [error] Bad pid (30782) in scoreboard slot 19 [Tue Mar 18 10:03:18 2008] [notice] caught SIGTERM, shutting down [Tue Mar 18 10:03:20 2008] [notice] mod_security/1.9.5 configured - Apache/1.3.39 (Unix) PHP/5.2.5 [Tue Mar 18 10:03:20 2008] [notice] Any You Like mod_ssl/2.8.30 OpenSSL/0.9.8g mod_perl/1.29 FrontPage/5.0.2.2510 configured -- resuming normal operations [Tue Mar 18 10:03:20 2008] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Mar 18 10:03:20 2008] [notice] Accept mutex: sysvsem (Default: sysvsem)
I'm finding that my server doesn't like to reboot gracefully. Either selecting "graceful server reboot" in WHM or actually typing "reboot" in SSH, which then tells me the server is shutting down. My server is then incommunicato indefinitely until I actually do a hard reset remotely.
Is this common? Is there some way to find out why this is happening?
So I was trying to run a backup process in Plesk 8.1 and the whole panel froze up on me (it's happened numerous times before).
Anyway, since the panel was all frozen up I just went into SSH and did a simple "reboot" (also, as done before many times). Only problem is, this time after I did the reboot the server never actually came back online... it seems to be locked up or something, I have no idea what.
I called my host and they are looking into it but they have no idea what's going on either and it's taking them forever to figure it out all the meanwhile my sites are down.... this isn't good.
Does anyone have any suggestions or advice as to why this could be occuring?
Just a general question regarding the frequency which you all reboot your linux servers.
Mine has been up for 178 days, and is running sweet as a nut (touch wood). I was just wondering if it's worth giving it a reboot anytime soon, or if not, how long to give it before rebooting?
At the moment every time I reboot my server I have to execute: # iptables --flush # iptables --zero
just to be able to access the server. (Though it does allow SSH to access before executing those).
And I figured out that I must do something to /etc/sysconfig/iptables to permanently be able to access the server without those commands after reboot. Right?
Below is the file's contents:
# Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Firewall-1-INPUT - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT -A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT
We changed our SSH port (for the slight added security that this offers) and updated our CSF config with the new port so that we can accept connections on this port.
We restarted CSF and we could connect successfully on the new port. When the server is rebooted connections are refused on the port until we *RESTART* CSF then it's all good again.
I would think being that we opened the port in CSF's config that on reboot the port would be opened back up but this is not happening and any time the server is rebooted we have to restart the firewall.
Does anybody have any suggestions on how to "fix" this or at least make it so we don't have to manually restart the firewall?
Does anyone have any recommendations for colocation providers in the LA area or recommendations for a PDU that has remote reboot capabilities (small budget, nonprofit organization)? We have a total of 9 servers.
I ordered a leaseweb express server 4 box with windows server 2003 and have been running it, installed some software etc which worked out fine.
Anyways, I wanted to disable tcp/ip filtering which I did and afterwards it prompted me that I would have to reboot the server for the changes to take place, I clicked ok and it rebooted. Now I just can't connect with remote desktop, I tried everything.
I'm guessing it either shut down or didn't reboot properly? I tried sending an email to leaseweb support 2 days ago but still no shadow of any reply..
It says that I can reboot the server using the SSC but when I log in there, I can't really find any reboot option.
I have a Centos 5.2 box with Cpanel/WHM. A couple days ago it rebooted.
I checked /var/log/messages and I can see where it rebooted, but I can't find anything that indicates why.
I'm trying to figure out if this is a hardware issue or software issue/crash.
I do have Nagios istalled, and it seems it saved some data right before the server rebooted. Not sure if this is a simple coincidence.
Dec 4 11:53:35 miles nagios: Auto-save of retention data completed successfully. Dec 4 11:56:14 miles syslogd 1.4.1: restart. Dec 4 11:56:14 miles kernel: klogd 1.4.1, log source = /proc/kmsg started. Dec 4 11:56:14 miles kernel: Linux version 2.6.18-92.1.17.el5PAE (mockbuild@builder16.centos.org) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Tue Nov 4 14:17:52 EST 2008 Dec 4 11:56:14 miles kernel: BIOS-provided physical RAM map: Dec 4 11:56:14 miles kernel: BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
problem on one server with debian, the last month it have a 100% f uptime, but since yesterday automaticly it reboot every 1 hour exactly!
this is a game server , dont have service like httpd , mysql dns , nothing! , I uninstall cron jobs thinking that will solve the problem, but no .....
I install firewall, run rkhunter and chkrootkit, check whell gruop and nothing
logs:
Jan 17 05:20:00 debian -- MARK -- Jan 17 05:40:00 debian -- MARK -- Jan 17 06:00:18 debian syslogd 1.4.1#18: restart. Jan 17 06:00:18 debian kernel: klogd 1.4.1#18, log source = /proc/kmsg started. Jan 17 06:00:18 debian kernel: Bootdata ok (command line is root=/dev/sda1 ro )
I change root password and ssh port but nothing... I think that could be a issue on debian or some exploit cause it, this was happend Suddenly one day to another it is very Strange....
I have an dedicated server 2 x Xeon CPU 3.20GHz (2GB RAM), now 30 minutes ago my admin tryed to make a benchmark test on it and after a period the server was not responding ( SSH or http.. ftp ) we asked DN to reboot the server. After the reboot in Service Status page (WHM) there ware many services down and the load was ~ 45.00 (4 cpus) .. after aprox. 5 - 10 minutes the load has droped:
Server Load 2.61 (4 cpus)
is it normal to have such a higher load 45.00 (4 cpus) after an reboot ? The memory used was 32%.
Is it possible to use a APC remote reboot power strip for a server in a blade?
Like for example, say there are 16 servers in a blade, can you remote reboot them individually?
Because blade servers have only like 3-4 redundant power supplies and I am assuming all the 16 servers are powered by the onboard power supplies in the blade enclosure. So...if thats the case, how is it possible to reboot each individual server?
Is there a script where i can stop counter strike source game at certian time by using .bat? I only need .bat script and not any other software. I don't know where this goes, so put this somewhere admin.