Fedora 10 stops allowing connections and date-time changes

Slowfamily · 06-03-2010, 12:40 PM

Hello,

I have a very strange problem I'm hoping someone might be able to shed some light on.

I have Fedora 10 set up as a server. Occasionally it will stop allowing connections, such as ssh, http, and samba. This continues until someone hits a key on the keyboard, and then it seems to come back to life and accept connections. At this point, the date and time will be wrong. Judging from monit messages that inform me when it stops allowing connections, I think the time freezes at whatever time it is when it stops allowing said connections.

Power Management has it set for the computer to never turn off. Sleep mode is also disabled in the BIOS.

I thought it was possibly the CMOS battery, but that has been replaced and the issue persists.

Someone previously thought it might have been Network Manager, but that is disabled due to issues it has with a static IP.

I'm really stumped here. Any ideas would be much appreciated.

Thanks!

rweaver · 06-03-2010, 12:58 PM

It ~really~ sounds like a suspend/hibernation issue of some sort, what do you have running on startup?

Code:

chkconfig --list

I'll mention also-- fedora is NOT suitable for a server OS where you want any degree of uptime and reliability. It's a bleeding edge distribution best suited for desktops... CentOS would be a better option really long term.

John VV · 06-03-2010, 01:05 PM

fedora 10 is past it's END OF LIFE
please install the current -- fedora 13 , then in 5.5 months fedora 14 then 6 months after that fedora 15 ... and so on...

use a long life distro for a server , one with 5 to 7 YEARS of support.

Slowfamily · 06-04-2010, 02:15 PM

Thanks for the responses.

This is not a production server, so not being the most reliable isn't the biggest deal. Our production servers run RHEL, so having something somewhat similar is nice. And for usage this server gets, upgrading every six months just isn't worth the effort.

Here's my chkconfig output. Let me know if you see any culprits:

Code:

NetworkManager  0:off   1:off   2:off   3:off   4:off   5:off   6:off
anacron         0:off   1:off   2:on    3:off   4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off
bluetooth       0:off   1:off   2:off   3:on    4:on    5:on    6:off
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
cups            0:off   1:off   2:on    3:on    4:on    5:on    6:off
dc_client       0:off   1:off   2:off   3:off   4:off   5:off   6:off
dc_server       0:off   1:off   2:off   3:off   4:off   5:off   6:off
dnsmasq         0:off   1:off   2:off   3:off   4:off   5:off   6:off
dovecot         0:off   1:off   2:off   3:off   4:off   5:off   6:off
firstboot       0:off   1:off   2:off   3:off   4:off   5:off   6:off
gpm             0:off   1:off   2:on    3:on    4:on    5:on    6:off
haldaemon       0:off   1:off   2:off   3:on    4:on    5:on    6:off
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
ip6tables       0:off   1:off   2:on    3:on    4:on    5:on    6:off
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
irda            0:off   1:off   2:off   3:off   4:off   5:off   6:off
irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off
kerneloops      0:off   1:off   2:off   3:on    4:on    5:on    6:off
livesys         0:off   1:off   2:off   3:on    4:on    5:on    6:off
livesys-late    0:off   1:off   2:off   3:on    4:on    5:on    6:off
lm_sensors      0:off   1:off   2:off   3:off   4:off   5:off   6:off
mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
messagebus      0:off   1:off   2:on    3:on    4:on    5:on    6:off
microcode_ctl   0:off   1:off   2:on    3:on    4:on    5:on    6:off
monit           0:off   1:off   2:on    3:on    4:on    5:on    6:off
multipathd      0:off   1:off   2:off   3:off   4:off   5:off   6:off
mysqld          0:off   1:off   2:on    3:on    4:on    5:on    6:off
netconsole      0:off   1:off   2:off   3:off   4:off   5:off   6:off
netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
netplugd        0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
nfs             0:off   1:off   2:off   3:off   4:off   5:off   6:off
nfslock         0:off   1:off   2:off   3:on    4:on    5:on    6:off
nmb             0:off   1:off   2:on    3:on    4:on    5:on    6:off
nscd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
ntpd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
ntpdate         0:off   1:off   2:off   3:off   4:off   5:off   6:off
openvpn         0:off   1:off   2:off   3:off   4:off   5:off   6:off
portreserve     0:off   1:off   2:on    3:on    4:on    5:on    6:off
proftpd         0:off   1:off   2:on    3:on    4:on    5:on    6:off
psacct          0:off   1:off   2:off   3:off   4:off   5:off   6:off
rdisc           0:off   1:off   2:off   3:off   4:off   5:off   6:off
restorecond     0:off   1:off   2:off   3:off   4:off   5:off   6:off
rpcbind         0:off   1:off   2:on    3:on    4:on    5:on    6:off
rpcgssd         0:off   1:off   2:off   3:on    4:on    5:on    6:off
rpcidmapd       0:off   1:off   2:off   3:on    4:on    5:on    6:off
rpcsvcgssd      0:off   1:off   2:off   3:off   4:off   5:off   6:off
rsyslog         0:off   1:off   2:on    3:on    4:on    5:on    6:off
saslauthd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
sendmail        0:off   1:off   2:on    3:on    4:on    5:on    6:off
setroubleshoot  0:off   1:off   2:off   3:on    4:on    5:on    6:off
smartd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
smb             0:off   1:off   2:off   3:on    4:off   5:on    6:off
smolt           0:off   1:off   2:on    3:on    4:on    5:on    6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
udev-post       0:off   1:on    2:on    3:on    4:on    5:on    6:off
winbind         0:off   1:off   2:off   3:off   4:off   5:off   6:off
wpa_supplicant  0:off   1:off   2:off   3:off   4:off   5:off   6:off
ypbind          0:off   1:off   2:off   3:off   4:off   5:off   6:off

rweaver · 06-04-2010, 02:42 PM

Unfortunately I don't see a culprit directly that I know causes problems. Is hibernate also turned off? Have you tried turning acpi entirely off also?

On the subject of distribution, you should look at centos-- binary compatible and follows the release cycle of RH and maintains compatibility. Spectacular distribution for test machines and such if you're a redhat shop and don't want to spring for licenses for things like that.

Also you're going to want to run ntpdate if your time is slipping that much, ntpd doesn't keep time well when there are huge jumps... ntpdate is made for clearing the big jumps, ntpd does the fine tuning and keeps it there.

John VV · 06-04-2010, 03:32 PM

Quote:

And for usage this server gets, upgrading every six months just isn't worth the effort.

just keep in mind That there will NEVER BE ANY MORE SECURITY UPDATES TO 10 EVER, NONE ,ZIP. AND THERE HAS NOT BEEN ANY SECURITY UPDATES FOR THE LAST 6 MONTHS

cpuspeed
you might want to turn that off if the hardware doe not support it .
smartd - AND THIS SHOULD BE ON!!!!!!

? have you read up on the services in fedora ?
10 is OLD and there have been MANY changes so..
this is for 11 but MIGHT work for 10 ( last updated 19 November 2009 )
http://www.mjmwired.net/resources/mjm-services-f11.html

forrestt · 06-04-2010, 03:45 PM

There won't just not be any more security updates, there won't be any more bug fix updates at all, security or functionality based. This may in fact be a known bug in some app that has been fixed, but you don't have it because the fix was done 4 months ago. The only way you would get it is to upgrade.

HTH

Forrest

p.s. the '4 months ago' was an example, I have no idea about the actual cause of the problem.

Slowfamily · 06-14-2010, 06:12 PM

I seem to have figured it out. There was a BIOS option to enable/disable IPCA function. Disabling this seemed to do the job. Apparently this wasn't an issue with the previous version of Fedora we had on there, but is with Fedora 10. Regardless, disabling this has caused this issue to not occur for a week.

John VV · 06-14-2010, 07:18 PM

you do know that fedora 10 is past it's EOL
there has been and never will be any security updates to 10 - never, no bug fixes, nothing

IF YOU ARE GOING TO USE FEDORA STAY CURRENT
AND INSTALL 13 , THEN IN 6 MONTHS INSTALL FEDORA 14 ...

Slowfamily · 06-15-2010, 11:04 AM

Thanks for the input, John. Still, there may be others using Fedora 10, and now if they run in to a similar problem, maybe this thread will help.

I'm thinking I might actually switch back to Fedora 8. It apparently worked better with my BIOS, and it seemed to work pretty well for all my other needs as well.

forrestt · 06-15-2010, 11:18 AM

Before you choose to go back to 8, why not try 13?

Forrest

rweaver · 06-15-2010, 01:06 PM

or... centos, debian, slackware, freebsd, or ubuntu-server.

That being said, i still run across Fedora 4 (why I see 4 specifically so much I'm unsure) in the field that no one has updated in many years... usually around the time they get a nasty root kit because anything that hasn't had updated in >6 mo likely is sitting around with remote exploits waiting for the right people to make it into a botnet or use it for spamming. Actually 2/3 root kits I see are from outdated fedora or gentoo (... yes, on a server *wince*). The rest are usually bad passwords.

I would put "install an outdated, non-supported, non-update-able distribution" (eg: Fedora <12) as the worst idea I've heard in months. Right there with dist upgrades on critical servers without backups.

Nothing like giving people attempting to exploit your network a nice comfy base of operations.