Slashdot Mirror
OpenBSD 3.9 Adds Sensor Framework
wbglinks writes to tell us ZDNet is reporting that the newest version of OpenBSD will include a sensor framework to help system administrators keep tabs on the environmental conditions of their servers. From the article: "At present, there are a number of commercial products that allow the environmental conditions of servers to be monitored, but different brands of server require different products. For example, Dell PowerEdge servers use the Embedded Server Management tool, while Sun Fire Servers use Sun's Remote System Control. This can make server management tricky when running a heterogeneous architecture. OpenBSD 3.9, which is scheduled for release on 1 May, includes support for the sensors and the sensor management tools used on a number of architectures."
Finally some use for BeOS' is_computer_on_fire() function!
Well if you don't shell out money for shifts and stand by calls don't expect work to get done 24/7. Well at least in most european countries it works this way, don't know about the rest of the world.
what's the situation in Linux? Is this the same thing as the 'hardware sensors' modules in the kernel?
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Ehm, in that part of the interview he's talking about "randomised memory allocation", not about sensors.
If you RTFA, you can see that that quotation was taken out of context. Theo was discussing fully random memory allocation to prevent buffer overflow. As far as I know, sensor monitoring is available quite easily in Linux.
If by "functionality" you mean hodge-podge of barely compatible tools written by some high scool kid in his mum's basement and that fail to actually define a sensible engineered framework, then yes I suppose so. Jesus Tap Dancing Christ, Linux sucks ass.
... they add support for BMC and IPMI?
Which, while fine in itself, is hardly a groundbreaking achievment for an OS, or is it? At least Windows has done that for years, and I believe Linux does as well (at least we have a working "sensor" implementation on a few RedHat / HP servers).
There's lots of niche features which are in the main branch of the kernel.
/dev/tempsensor1 for the tempature of my motherboard or CPU. Might even be able to do something useful with it.
NUMA, OMAP, powerPC, and the list goes on and on.
However, I think it would be VERY cool to be able to query
Cheers,
Ben
cat /proc/acpi/thermalzone/THRM1/temperature
Remember when you could go back to work on Monday and find a disaster that would take you three weeks of painstaking work to fix because you had no way of knowing a fan died?
*blinking cursor*
Ah, the good old days!
"There is a significant new sensor framework [in OpenBSD 3.9], which supports voltage sensors, fan sensors, temperature sensors, and so on," said de Raadt. "Such a feature is still missing in Linux and other major operating systems."
There we go
Um, it's not there... /proc/acpi doesnt have thermalzone...
Oh well, its the thought that counts :)
Ben
weird... I guess you don't have ACPI compiled in. My point was that you CAN do that sort of thing already :P
IIRC Intel's ACPI code was included in Kernel long time ago. It's just ACPI has nothing to do with sensors. (http://acpi.sourceforge.net/)
Sensors it's LM78 project. But. Not on single Linux instalation I've had luck with sensor installation. )-: Most of the time lm78 reported me nothing - given it found any sensors at all...
P.S. Overall, due to separate development of kernel and libc, Linux development rarely results in any kind of API or framework. (Well, except the even rarer case when both developers - libc & kernel ones - happen to be employed by Red Hat.)
All hope abandon ye who enter here.
Don't you just hand over to the team in Singapore? When a fan fails they call a chap in Paris to call the on-call site engineer. Oh.
And that's the ACPI thing, you've a sysfs interface for other sensors.
Have I been missing this section this whole time, or is this something new?
Any fool can criticise, condemn, and complain, and most fools do. - Benjamin Franklin
Sensor management or no sensor management it's pretty the same thing... instead of the server dialing / paging you there can be a human dialing / paging you anyway. And of course YOU CAN switch off your cell phone if it's bothering...
This reminds me of some time back when I used to tech support for a telco logging system. I was out with my friends BBQ-ing in a weekend when I get this strange phone call (all after some beers and stuff):
Other end: "Hello, there's a mess in here... air conditioning broke up, the heat pipe from the next level is also broken, all the servers room is flooded"
Me: "Who the fuck are you? Where the fuck are you? And what do I have to do with this mess?"
Other end: "We're on [Street Name] and [repeats again the whole thing]"
Me: "And what's on the [Street Name] and what do I have to do with that?"
Other end: "We're at [Street Name] and like I said [repeats the whole thing again]
Me (finally realizing the address matches one of my customers): "Ah... [Firm Name]? And who the hell told you to call me? Am I listed by any chance by mistake in the plumbers section of yellow pages? Did anyone make a joke or something?"
Other end: "Well... I work here and the only contact I could find there or in my contacts list is your phone no... was posted on a sticky on one of the server boxes"
Turns out that in a fucking really big enterprise... no one knew who to call in case of any kind of emergency or something like that... so the poor guy just took a chance with the first phone no he saw. Not his boss, not a guy working there, but me, a contractor for servicing a particular piece of software running on one of the damn boxes... It doesn't matter how many alarms, logging, notifications one sets up as long as there's not a procedure for dealing with it and people don't know who to call for each of them.
I'm still wandering what would have happened if I would just say "OK... I know, I'm just entering the building... I'll take care of that, don't bother"
"NO U!"
Change is certain; progress is not obligatory.
cat /proc/acpi/thermal_zone/THRM/temperature
is the spot for me on an Gentoo amd64 laptop
temperature: 48 C
for those curious as to it's output)
The truth about Led Zep should never be told on
Sensor management means that you will be aware of problems as they are in the nascent stages of development, before they become a crisis. It provides you the time needed to research and repair, instead of the panicked "fix it now!" when systems stop working.
It has been here for years, but there's rarely a story posted in it :-)
I don't remember just how I got this working in the first place, but lm_sensors works great on my Linux machine. I think it's supposed to work with some particular sensor models that don't go through ACPI... so if you've been doing all your Linux installations on machines with different types of sensors you'll probably have to look somewhere else. On the other hand, I have a laptop running FreeBSD and it seems like on there all the sensor-type stuff is handled through ACPI. So maybe if you have the right setup the sensor information will be available to you that way.
Lucky you! Last job I was on call every 5th week, for 7 days, 24 hours a day and got a page (to which I had 20 minutes to respond) every 15 minutes or less. Which is why it was my previous job. The pay was nowhere near enough to make up for losing 7 days of sleep.
And, as far as salary goes, funny how salaried US employees tend to work a lot of those 80 hour weeks, and very few of the 20 hour versions.
Boys from the City. Not yet caught by the Whirlwind of Progress. Feed soda pop to the thirsty pigs.
for me (my whole world is snmp, it seems) I'd want to know if there is any good progress on getting remote mgmt via snmp working better than it has, in the past.
for example, sun has the 'platform mib' and 'entity mib' and in these two (as a sum) you can get voltage and fan speed and temperature and even alerts (traps) when thresholds are reached.
I have not seen the entity mib (for example) on ANY lower end unix platform (freebsd, linux, etc). maybe I have to be the one to write one...
getting sensor data has always been there, at least on linux. lmsensors worked for me when I used to run linux (I'm now a freebsd guy, though). the trick was getting it in a MIB so that remote polling and trapping could be done in a standard way using standard NMS tools.
--
"It is now safe to switch off your computer."
I think I may code an AI script that will learn how to have conversations based on the content of slashdot. After the program has digested a few thousand posts it will surely pass the
I imagine a conversation would run like this:
Human: "I'm impressed with this new Linux distro. This may actually be an operating system my grandmother can use without any problems!"
Slashdotbot: "Heh. Your mother should use Debian. If she uses Ubuntu she is going to get p0wn3d."
Human: "I use BSD personally on my servers, but I don't think my Grandmother has much to worry about on her computer."
Human: "Um... okay... I guess that made a little sense -- if I cross my eyes and think real hard. I wonder what will happen when I say this: I've been running YourMomOS on my laptop and she is humming away beautifully."
Human: "I think I'm on to you. Hey guy, tell me about your girl."
Human: "Wait. Proves nothing. But that response is suspicious. Hey guy, tell me about your 7545121116577545454."
Human: "This is a computer program, but I was nearly fooled. Another thousand posts and it will be absolutely indistinguishable from the average slashdot poster. You merely need to dumb down its grammar, interject more spelling mistakes, and give it more pop culture references (i.e. the mention of the word 'Ballmer' should trigger the 'make_joke_about_chairs()' subroutine) and this AI construct will truly be perfect."
Some are taking a more external route, and are more concerned with data-center level monitoring than system-level. Degree Controls (www.degreec.com) has a new product/service initiative called Adaptivcool which works to monitor and control (intelligently) airflow in a datacenter. Good stuff.
The 2.6.X linux kernels all have support for 1wire sensors through a built in kernel module.
For those of you who aren't familiar with 1wire networking, I suggest checking out www.ibuttonlink.com for examples of those devices.
Navicula hydraulica plena anguilarum est. Omnes castelli tuus nostri sunt. Ed elli avea del cul fatto trombetta.
Being all-powerful, I'm sure Jesus would be pretty good at tap dancing if he felt like it :-)
That said, although 'lm_sensors' and such can be a royal pain to manage at a low level when starting out, many higher-level tools exist to manage entire networks of Linux machines and their status data.
See the related apps page on the rrdtool homepage.
- Michael T. Babcock (Yes, I blog)
The hardware sensors stuff is in there. Enable the options (i2c /dev interface if you want /dev nodes, or I think it might have been renamed in new kernels), install lm-sensors for the userspace stuff, and you can get things like gkrellm monitors if you want.
I am trolling
I thought Slashdot readers were opposed to sensorship. (*Rimshot*)
My Freakin Blog
You know, the Linux sensor developers ARE Linux developers (in charge of a given subsystem>), it's not a "third party group" where "changes still have to be imported" - in Linux the hardware monitoring features, IPMI etc have been in the mainline tree - and shipped in distros with commercial support etc - for years.
I really don't see the difference, except that OpenBSD seems to be the one who is catching up.
The new thing with 3.9 is support for more hardware monitoring interfaces, notably IPMI.
That's on my Epia VE5000 box btw, no need to fret about the 0 RPM fans
Error: password can't contain reverse spelling of ancient Chinese emperor
Wow, this latest move is sure to rocket OpenBSD to the top.
I mean, the network performace will likely still suck, especially compared to the competition, but at least now we can monitor our servers!
Big Brother's given us this capability for years. Nothing to see here, move along.
This "New Sensor Framework" has been in the mainline kernel since 3.5, and working quite well, thank you. I certainly wish other OSes would get this stuff built-in (of course OpenBSD is also lacking a lot of good features that FreeBSD/Linux DO have).
Setting up lmsensors was an infuriating and disgusting mess on Linux. After an hour of kernel recompliations, and i2c/lmsensors version mis-matches, I just gave-up. I decided to simply parse the output of mbmon (most trivial setup, EVER!).
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
...quoth the anonymous coward. The irony is delicious, especially with steak sauce.
Use the openmanage stuff. It doesn't deal much with the lm_sensors stuff (which in imo sucks a lot), but it will let you read the sensors via snmp.