New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Does anyone else experiencing high rates of linux server crashes today?
just found this
http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today/
anyone have the same problems ?
thanks
Thanked by 1djvdorp
Comments
wow, what is that? leap second causing so much headache :P ?
Haven't had any problems here yet... but running OS based on RHEL.
I've heard that leap second could cause Linux crash before.
Actually I consider it a joke at first, but it became true now...
Yes, 2 servers :-(
Thankful for no issues here. CentOS on everything mission critical, not particularly a preference but just how it ended up.
lol Debian lol
No, no issues here.
edit: I guess I should have said "lol ntpd lol". I don't put that on production servers either.
It's sad for the IT industry that such a thing still causes problems. I'm really afraid of the year the unix time will overflow 32 bit integers. (2039 or smth)
@subigo why don't you use ntpd?
See: All the people having issues right now.
I never install a service for something a simple cron can do.
NTPD isn't needed. A cron can do its job. @subigo has a point - its a useless service. Lol.
Everyone will be using 64 bit by then?
Well lets hope that :P
We'de have a problem if we still use 32bit/64bit in 2039. LOL.
Well 64bit shouldn't be a problem, theres plently of space to expand
However i don't linke to make any assumptions about 2039, just think back on what the world thought about computing in 1985.
No crashes, Just 2 Failed drives.
That is one of the dumbest things I've ever read here, which is saying a lot.
Back that statement up. I say putting NTP on production servers is one of the dumbest things ever.
I say there are environments where having closely synchronized clocks is a requirement. Kerberos-based environments for example. Coordination with external partners where time is significant is another. Not all environments like a brute-force daily time change where the clock jumps forward a half-second or two.
PAD said it is "useless" which means there are absolutely no uses whatsoever.
I think he's just saying there's no reason to use a service to get and set time, when you already have a service installed that can do it for you (cron).
I've had so many issues with NTP in the past that I refuse to ever use it on an important production server again. Instead, I have a series of pages across the Internet like this one: http://94.249.244.181/date.php
...then on production servers I just setup a cron to grab that page and set the date every ten minutes.
ntpd does the job, and it does it well. Using cron for this, on the other hand, is a hackish solution, at best.
4 Debian Squeeze boxes here running the standard kernel & ntpd (2 hardware boxes, 2 KVM). No issues.
If I'm reading correctly, the leap second gets inserted sometime during the day on June 30, UTC. It's now July 1 UTC....
Bullshit. NTP has had so many bugs over the years it's retarded. One of my first VPS nodes crashed daily for about a week and it ended up being a fast clock that NTP choked on while trying to sync. You realize NTP is a cron that does nothing more than grab the time from other servers, correct?
edit: I'm just going to leave this here: buglist
Well, this is how Ubuntu 12.04 with NTP installed handled it on my laptop (from syslog):
656 Jun 30 19:59:59 laptop kernel: [72245.253499] Clock: inserting leap second 23:59:60 UTC
Went off without a hitch. I don't know why people think Debian is more stable than Ubuntu. Ubuntu, even in non-LTS releases, has always been more stable for me, and they accomplish this in 2 months of beta testing compared to Debian's 6-7 months.
@subigo what are you trying to say by linking the buglist? software has bugs.... surprised?
if you think your php solution is better than ntp.... that's kinda funny.
https://bugs.php.net/bug.php?id=50696
If you don't want to use ntp, rdate out of cron is probably simpler than parsing php.
Yeah, but software with hundreds of open bugs, most of which are over a year old, is retarded when that software is nothing more than a time sync.
And don't be stupid. Did you even read that PHP bug report (yeah, I saw it on Hacker News too)? Are you going to tell me that using date(); and pulling that number via a bash script is somehow more complex than NTP? I do in 10 lines of code what NTP does in tens of thousands.
10 lines of code excluding the webserver and php code.
Including the PHP code... it's just "date()".
And who says you have to use your own server to pull data from? There's a million places to pull official atomic time and NTP time (like, I don't know, maybe the NTP pool servers)... or if you don't like that: http://tycho.usno.navy.mil/cgi-bin/timer.pl
Seriously people... do you even know what NTPd is doing? It's pinging one of the external pool servers and then setting the OS time. That's it. Nothing else.
Actually, it's a little more complicated than that. It measures the delay between your server and the ntp server, and a bunch of other stuff. ntpd is almost always going to more accurate than anything you're going to claim is "just as good".
Right... it pings the NTP pool and takes the average of the most similar times in the pool and then sets the OS time accordingly.
So you're installing an entire service package so you can sync your system up with a pool... great. And then if your clock happens to be out of sync too much, ntpd will refuse to set the time (unless you override it) and sometimes goes into a loop, crashing your server. Or one of the other hundreds of bugs that happen when ntpd doesn't feel like running correctly.
I run a simple cron to keep my network in sync and it has worked for years. Over the course of a year, my time might (MIGHT) be off by 1-2 minutes when compared to the NTP pool. And if I really cared about syncing up with the NTP pool (which I do not), I could simply run ntpd on the server that my crons pull from. If you did that, you'd be in sync with the pool and you wouldn't even have to run the ntpd service.
I don't care who you are or what you say... running an entire buggy service to keep in sync with another network pool will never be as safe and as simple as: