[lm-sensors] Getting alarms using lm-sensors

[lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

Hello, All.

	I have been trying to configure lm_sensors to provide alarms for
failing fans, high temperatures, etc.  I get a reasonable output from the
sensors command, but when I deliverately create an alarm condition, it does
not report as an alarm.  For example, I just pulled the fan on the OPT_FAN3
sensor, and the speed dropped from 1800 RPM to 0, but `sensors` does not
report any alarm:

RAID-Server:/usr/share/sensors# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1:       +40.0°C  (crit = +75.0°C)                  

atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage:      +1.42 V  (min =  +0.85 V, max =  +1.60 V)
+12V Voltage:      +12.03 V  (min = +10.20 V, max = +13.80 V)
+5V Voltage:        +4.92 V  (min =  +4.50 V, max =  +5.50 V)
+3.3V Voltage:      +3.30 V  (min =  +2.97 V, max =  +3.63 V)
DDR2:               +2.00 V  (min =  +1.71 V, max =  +2.09 V)
HT:                 +1.28 V  (min =  +1.08 V, max =  +1.32 V)
SB:                 +1.30 V  (min =  +0.99 V, max =  +1.21 V)
BR:                 +1.23 V  (min =  +1.08 V, max =  +1.32 V)
VDDA:               +2.61 V  (min =  +2.25 V, max =  +2.75 V)
DDR2 TERM.:         +0.98 V  (min =  +0.85 V, max =  +1.04 V)
VDDNB:              +1.20 V  (min =  +1.17 V, max =  +1.43 V)
CPU_FAN FAN Speed: 2227 RPM  (min =  800 RPM)
CHA_FAN1 FAN Speed:2766 RPM  (min =  800 RPM)
CHA_FAN2 FAN Speed:2766 RPM  (min =  800 RPM)
OPT_FAN1 FAN Speed:   0 RPM  (min =  800 RPM)
OPT_FAN2 FAN Speed:   0 RPM  (min =  800 RPM)
OPT_FAN3 FAN Speed:   0 RPM  (min =  800 RPM)
PWR_FAN FAN Speed: 1180 RPM  (min =  800 RPM)
CHA_FAN3 FAN Speed:   0 RPM  (min =  800 RPM)
CPU Temperature:    +41.0°C  (high = +60.0°C, crit = +95.0°C)  
MB Temperature:     +45.0°C  (high = +45.0°C, crit = +95.0°C)  
OPT1:                +0.0°C  (high = +45.0°C, crit = +95.0°C)  
OPT2:                +0.0°C  (high = +45.0°C, crit = +95.0°C)  
OPT3:                +0.0°C  (high = +45.0°C, crit = +95.0°C)  

k10temp-pci-00c3
Adapter: PCI adapter
temp1:       +32.5°C  (high = +70.0°C, crit = +70.0°C)  

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 3502 bytes --]

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Guenter Roeck]

On Fri, Nov 16, 2012 at 12:16:48AM -0600, Leslie Rhorer wrote:
> Hello, All.
> 
> 	I have been trying to configure lm_sensors to provide alarms for
> failing fans, high temperatures, etc.  I get a reasonable output from the
> sensors command, but when I deliverately create an alarm condition, it does
> not report as an alarm.  For example, I just pulled the fan on the OPT_FAN3
> sensor, and the speed dropped from 1800 RPM to 0, but `sensors` does not
> report any alarm:
> 
> RAID-Server:/usr/share/sensors# sensors
> acpitz-virtual-0
> Adapter: Virtual device
> temp1:       +40.0°C  (crit = +75.0°C)                  
> 
> atk0110-acpi-0
> Adapter: ACPI interface
> Vcore Voltage:      +1.42 V  (min =  +0.85 V, max =  +1.60 V)
> +12V Voltage:      +12.03 V  (min = +10.20 V, max = +13.80 V)
> +5V Voltage:        +4.92 V  (min =  +4.50 V, max =  +5.50 V)
> +3.3V Voltage:      +3.30 V  (min =  +2.97 V, max =  +3.63 V)
> DDR2:               +2.00 V  (min =  +1.71 V, max =  +2.09 V)
> HT:                 +1.28 V  (min =  +1.08 V, max =  +1.32 V)
> SB:                 +1.30 V  (min =  +0.99 V, max =  +1.21 V)
> BR:                 +1.23 V  (min =  +1.08 V, max =  +1.32 V)
> VDDA:               +2.61 V  (min =  +2.25 V, max =  +2.75 V)
> DDR2 TERM.:         +0.98 V  (min =  +0.85 V, max =  +1.04 V)
> VDDNB:              +1.20 V  (min =  +1.17 V, max =  +1.43 V)
> CPU_FAN FAN Speed: 2227 RPM  (min =  800 RPM)
> CHA_FAN1 FAN Speed:2766 RPM  (min =  800 RPM)
> CHA_FAN2 FAN Speed:2766 RPM  (min =  800 RPM)
> OPT_FAN1 FAN Speed:   0 RPM  (min =  800 RPM)
> OPT_FAN2 FAN Speed:   0 RPM  (min =  800 RPM)
> OPT_FAN3 FAN Speed:   0 RPM  (min =  800 RPM)
> PWR_FAN FAN Speed: 1180 RPM  (min =  800 RPM)
> CHA_FAN3 FAN Speed:   0 RPM  (min =  800 RPM)
> CPU Temperature:    +41.0°C  (high = +60.0°C, crit = +95.0°C)  
> MB Temperature:     +45.0°C  (high = +45.0°C, crit = +95.0°C)  
> OPT1:                +0.0°C  (high = +45.0°C, crit = +95.0°C)  
> OPT2:                +0.0°C  (high = +45.0°C, crit = +95.0°C)  
> OPT3:                +0.0°C  (high = +45.0°C, crit = +95.0°C)  
> 
> k10temp-pci-00c3
> Adapter: PCI adapter
> temp1:       +32.5°C  (high = +70.0°C, crit = +70.0°C)  

All those drivers don't support alarms.

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: Friday, November 16, 2012 12:37 AM
> To: Leslie Rhorer
> Cc: lm-sensors@lm-sensors.org
> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> 
> On Fri, Nov 16, 2012 at 12:16:48AM -0600, Leslie Rhorer wrote:
> > Hello, All.
> >
> > 	I have been trying to configure lm_sensors to provide alarms for
> > failing fans, high temperatures, etc.  I get a reasonable output from
> the
> > sensors command, but when I deliverately create an alarm condition, it
> does
> > not report as an alarm.  For example, I just pulled the fan on the
> OPT_FAN3
> > sensor, and the speed dropped from 1800 RPM to 0, but `sensors` does not
> > report any alarm:
> >
> > RAID-Server:/usr/share/sensors# sensors
> > acpitz-virtual-0
> > Adapter: Virtual device
> > temp1:       +40.0°C  (crit = +75.0°C)
> >
> > atk0110-acpi-0
> > Adapter: ACPI interface
> > Vcore Voltage:      +1.42 V  (min =  +0.85 V, max =  +1.60 V)
> > +12V Voltage:      +12.03 V  (min = +10.20 V, max = +13.80 V)
> > +5V Voltage:        +4.92 V  (min =  +4.50 V, max =  +5.50 V)
> > +3.3V Voltage:      +3.30 V  (min =  +2.97 V, max =  +3.63 V)
> > DDR2:               +2.00 V  (min =  +1.71 V, max =  +2.09 V)
> > HT:                 +1.28 V  (min =  +1.08 V, max =  +1.32 V)
> > SB:                 +1.30 V  (min =  +0.99 V, max =  +1.21 V)
> > BR:                 +1.23 V  (min =  +1.08 V, max =  +1.32 V)
> > VDDA:               +2.61 V  (min =  +2.25 V, max =  +2.75 V)
> > DDR2 TERM.:         +0.98 V  (min =  +0.85 V, max =  +1.04 V)
> > VDDNB:              +1.20 V  (min =  +1.17 V, max =  +1.43 V)
> > CPU_FAN FAN Speed: 2227 RPM  (min =  800 RPM)
> > CHA_FAN1 FAN Speed:2766 RPM  (min =  800 RPM)
> > CHA_FAN2 FAN Speed:2766 RPM  (min =  800 RPM)
> > OPT_FAN1 FAN Speed:   0 RPM  (min =  800 RPM)
> > OPT_FAN2 FAN Speed:   0 RPM  (min =  800 RPM)
> > OPT_FAN3 FAN Speed:   0 RPM  (min =  800 RPM)
> > PWR_FAN FAN Speed: 1180 RPM  (min =  800 RPM)
> > CHA_FAN3 FAN Speed:   0 RPM  (min =  800 RPM)
> > CPU Temperature:    +41.0°C  (high = +60.0°C, crit = +95.0°C)
> > MB Temperature:     +45.0°C  (high = +45.0°C, crit = +95.0°C)
> > OPT1:                +0.0°C  (high = +45.0°C, crit = +95.0°C)
> > OPT2:                +0.0°C  (high = +45.0°C, crit = +95.0°C)
> > OPT3:                +0.0°C  (high = +45.0°C, crit = +95.0°C)
> >
> > k10temp-pci-00c3
> > Adapter: PCI adapter
> > temp1:       +32.5°C  (high = +70.0°C, crit = +70.0°C)
> 
> All those drivers don't support alarms.
> 
> Guenter

Oi.  Thanks, anyway.

Well, OK, then.  I've started working on a cron script that will send
e-mails when a parameter falls out of bounds or shut down the shelf if it is
critical, so on a related note, what sensors, exactly, are acpitz-virtual-0
and k10temp-pci-00c3?  It's very nice they are in bounds, but if they should
drift out of bounds, what should I believe is getting too hot?


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Guenter Roeck]

On Fri, Nov 16, 2012 at 09:48:59PM -0600, Leslie Rhorer wrote:
> > -----Original Message-----
> > From: Guenter Roeck [mailto:linux@roeck-us.net]
> > Sent: Friday, November 16, 2012 12:37 AM
> > To: Leslie Rhorer
> > Cc: lm-sensors@lm-sensors.org
> > Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> > 
> > On Fri, Nov 16, 2012 at 12:16:48AM -0600, Leslie Rhorer wrote:
> > > Hello, All.
> > >
> > > 	I have been trying to configure lm_sensors to provide alarms for
> > > failing fans, high temperatures, etc.  I get a reasonable output from
> > the
> > > sensors command, but when I deliverately create an alarm condition, it
> > does
> > > not report as an alarm.  For example, I just pulled the fan on the
> > OPT_FAN3
> > > sensor, and the speed dropped from 1800 RPM to 0, but `sensors` does not
> > > report any alarm:
> > >
> > > RAID-Server:/usr/share/sensors# sensors
> > > acpitz-virtual-0
> > > Adapter: Virtual device
> > > temp1:       +40.0°C  (crit = +75.0°C)
> > >
> > > atk0110-acpi-0
> > > Adapter: ACPI interface
> > > Vcore Voltage:      +1.42 V  (min =  +0.85 V, max =  +1.60 V)
> > > +12V Voltage:      +12.03 V  (min = +10.20 V, max = +13.80 V)
> > > +5V Voltage:        +4.92 V  (min =  +4.50 V, max =  +5.50 V)
> > > +3.3V Voltage:      +3.30 V  (min =  +2.97 V, max =  +3.63 V)
> > > DDR2:               +2.00 V  (min =  +1.71 V, max =  +2.09 V)
> > > HT:                 +1.28 V  (min =  +1.08 V, max =  +1.32 V)
> > > SB:                 +1.30 V  (min =  +0.99 V, max =  +1.21 V)
> > > BR:                 +1.23 V  (min =  +1.08 V, max =  +1.32 V)
> > > VDDA:               +2.61 V  (min =  +2.25 V, max =  +2.75 V)
> > > DDR2 TERM.:         +0.98 V  (min =  +0.85 V, max =  +1.04 V)
> > > VDDNB:              +1.20 V  (min =  +1.17 V, max =  +1.43 V)
> > > CPU_FAN FAN Speed: 2227 RPM  (min =  800 RPM)
> > > CHA_FAN1 FAN Speed:2766 RPM  (min =  800 RPM)
> > > CHA_FAN2 FAN Speed:2766 RPM  (min =  800 RPM)
> > > OPT_FAN1 FAN Speed:   0 RPM  (min =  800 RPM)
> > > OPT_FAN2 FAN Speed:   0 RPM  (min =  800 RPM)
> > > OPT_FAN3 FAN Speed:   0 RPM  (min =  800 RPM)
> > > PWR_FAN FAN Speed: 1180 RPM  (min =  800 RPM)
> > > CHA_FAN3 FAN Speed:   0 RPM  (min =  800 RPM)
> > > CPU Temperature:    +41.0°C  (high = +60.0°C, crit = +95.0°C)
> > > MB Temperature:     +45.0°C  (high = +45.0°C, crit = +95.0°C)
> > > OPT1:                +0.0°C  (high = +45.0°C, crit = +95.0°C)
> > > OPT2:                +0.0°C  (high = +45.0°C, crit = +95.0°C)
> > > OPT3:                +0.0°C  (high = +45.0°C, crit = +95.0°C)
> > >
> > > k10temp-pci-00c3
> > > Adapter: PCI adapter
> > > temp1:       +32.5°C  (high = +70.0°C, crit = +70.0°C)
> > 
> > All those drivers don't support alarms.
> > 
> > Guenter
> 
> Oi.  Thanks, anyway.
> 
> Well, OK, then.  I've started working on a cron script that will send
> e-mails when a parameter falls out of bounds or shut down the shelf if it is
> critical, so on a related note, what sensors, exactly, are acpitz-virtual-0
> and k10temp-pci-00c3?  It's very nice they are in bounds, but if they should
> drift out of bounds, what should I believe is getting too hot?
> 
k10temp is the AMD CPU temperature as reported by the CPU itself. It isn't
really accurate. acpitz-virtual is, as the name says, a virtual device.
acpitx is short for "ACPI thermal zone". It may also reflect the CPU
temperature, but I don't know for sure.

Guenter
> 

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> > > > SB:                 +1.30 V  (min =  +0.99 V, max =  +1.21 V)

> > > > MB Temperature:     +45.0°C  (high = +45.0°C, crit = +95.0°C)


> k10temp is the AMD CPU temperature as reported by the CPU itself. It isn't
> really accurate. acpitz-virtual is, as the name says, a virtual device.
> acpitx is short for "ACPI thermal zone". It may also reflect the CPU
> temperature, but I don't know for sure.
> 
> Guenter

	OK, thanks once again.  I guess I will ignore them.  I hope you
don't mind me asking all these questions, but I do have a couple more.  Note
the two reports above.  Where is the sensors routine getting its limit
values?  Both the SouthBridge voltage and the chip array temperature are
reported out of bounds, yet I am not overclocking, at all.  The manual says
the motherboard offers legitimate OC values of 1.10, 1.12, 1.14, 1.16, 2.98,
and 3.00 VDC.  Given that, I shouldn't think 1.3V would be out of bounds.

	That, and 45C is just not really that hot.  The chipset often rises
to well over 60C, and I don't really believe it to be a problem.

	Finally, and this one I admit is really getting close to being
totally off-topic, but the script I am writing reports the out of bounds
values to me via mail.  The degree character gets mangled, though, making
the text look funny.  It's really not a big deal, but it is a bit annoying.
The text above comes out as:

+40.0°C (high = +60.0°C, crit = +95.0°C)

All I do is store the text of the `sensors` command to a variable and then
pass the variables to mail.  (This is a bash script.)

	SID=$( echo $line | cut -d ":" -f1 )		# $SID = Sensor ID
	AID=$(echo $line | cut -d ":" -f4 )		# $AID = Sensor Name
	TID=$(echo $line | cut -d ":" -f5 )		# $TID = Text Name
for e-mail
	FIELDS=$( sensors | grep "$AID:" )		# $FIELDS = Text
from `sensors`
	F2=$( echo $FIELDS | cut -d ":" -f2 )		# $F2 = Description
from `sensors`
	CVAL=${F2% (*}					# $CVAL = Current
Sensor Value

...

echo "$TID $ATEXT  Value: $F2" | mail -a From:sensor_monitor -s "RAID-Server
Sensor Event Notification" xxxxxxxxxx@yyyyyyyyy.com


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Jean Delvare]

On Fri, 16 Nov 2012 22:45:05 -0600, Leslie Rhorer wrote:
> > > > > SB:                 +1.30 V  (min =  +0.99 V, max =  +1.21 V)
> 
> > > > > MB Temperature:     +45.0°C  (high = +45.0°C, crit = +95.0°C)
> 
> 
> > k10temp is the AMD CPU temperature as reported by the CPU itself. It isn't
> > really accurate. acpitz-virtual is, as the name says, a virtual device.
> > acpitx is short for "ACPI thermal zone". It may also reflect the CPU
> > temperature, but I don't know for sure.
> > 
> > Guenter
> 
> 	OK, thanks once again.  I guess I will ignore them.  I hope you
> don't mind me asking all these questions, but I do have a couple more.  Note
> the two reports above.  Where is the sensors routine getting its limit
> values?  Both the SouthBridge voltage and the chip array temperature are
> reported out of bounds, yet I am not overclocking, at all.  The manual says
> the motherboard offers legitimate OC values of 1.10, 1.12, 1.14, 1.16, 2.98,
> and 3.00 VDC.  Given that, I shouldn't think 1.3V would be out of bounds.

The limits are set by the BIOS itself. Note that ATK0110 is a virtual
(ACPI) device so there is no guarantee that the limits reported by the
driver have actually been programmed into the underlying monitoring
chip. They may be purely informative.

Given that (0.99 + 1.21) / 2 = 1.10, it seems clear to me that the
nominal value for SB is supposed to be 1.10 V. This is also in line
with the documented OC values of 1.10, 1.12, 1.14 and 1.16 V. The
documented values of 2.98 and 3.00 V OTOH are odd... You never
overclock a nominal voltage to more than +25%. I can't actually believe
that your BIOS offers to overclock +1.10V to +3.00V.

So it is well possible that you have a real problem here. It would be
interesting to see if another user with the same board sees similar
values. If not, maybe your PSU has an issue or you have wrong settings
in your BIOS. You may also look for a BIOS update, as the ATK0110 ACPI
code comes with the BIOS.

> 	That, and 45C is just not really that hot.  The chipset often rises
> to well over 60C, and I don't really believe it to be a problem.

I agree that 45°C isn't that hot, and also it is curious to consider
45°C as hot when the critical limit is set as high as 95°C. This would
either be a BIOS bug or a misconfiguration - it is possible that you
can change this limit manually in the BIOS. Alternatively, it could be
that the "high" point is set to enable some form of cooling and there's
nothing wrong with the temperature being above that point.

> 	Finally, and this one I admit is really getting close to being
> totally off-topic, but the script I am writing reports the out of bounds
> values to me via mail.  The degree character gets mangled, though, making
> the text look funny.  It's really not a big deal, but it is a bit annoying.
> The text above comes out as:
> 
> +40.0°C (high = +60.0°C, crit = +95.0°C)
> 
> All I do is store the text of the `sensors` command to a variable and then
> pass the variables to mail.  (This is a bash script.)
> 
> 	SID=$( echo $line | cut -d ":" -f1 )		# $SID = Sensor ID
> 	AID=$(echo $line | cut -d ":" -f4 )		# $AID = Sensor Name
> 	TID=$(echo $line | cut -d ":" -f5 )		# $TID = Text Name for e-mail
> 	FIELDS=$( sensors | grep "$AID:" )		# $FIELDS = Text from `sensors`
> 	F2=$( echo $FIELDS | cut -d ":" -f2 )		# $F2 = Description from `sensors`
> 	CVAL=${F2% (*}					# $CVAL = Current Sensor Value
> 
> ...
> 
> echo "$TID $ATEXT  Value: $F2" | mail -a From:sensor_monitor -s "RAID-Server
> Sensor Event Notification" xxxxxxxxxx@yyyyyyyyy.com

This is an UTF8 vs. non-UTF8 issue. You are running "sensors" with an
UTF8 locale, but the e-mail you send apparently lacks proper encoding
information. This can be solved in two ways: either set the locale to
non-UTF8 when you run "sensors" (LANG=en_US sensors), or add some
encoding parameter to the mail command (my version claims utf-8 to be
the default but apparently that's not your case.)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org]
> Sent: Saturday, November 17, 2012 2:13 AM
> To: Leslie Rhorer
> Cc: 'Guenter Roeck'; lm-sensors@lm-sensors.org
> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> 
> On Fri, 16 Nov 2012 22:45:05 -0600, Leslie Rhorer wrote:
> > > > > > SB:                 +1.30 V  (min =  +0.99 V, max =  +1.21 V)
> >
> > > > > > MB Temperature:     +45.0°C  (high = +45.0°C, crit = +95.0°C)
> >
> >
> > > k10temp is the AMD CPU temperature as reported by the CPU itself. It
> isn't
> > > really accurate. acpitz-virtual is, as the name says, a virtual
> device.
> > > acpitx is short for "ACPI thermal zone". It may also reflect the CPU
> > > temperature, but I don't know for sure.
> > >
> > > Guenter
> >
> > 	OK, thanks once again.  I guess I will ignore them.  I hope you
> > don't mind me asking all these questions, but I do have a couple more.
> Note
> > the two reports above.  Where is the sensors routine getting its limit
> > values?  Both the SouthBridge voltage and the chip array temperature are
> > reported out of bounds, yet I am not overclocking, at all.  The manual
> says
> > the motherboard offers legitimate OC values of 1.10, 1.12, 1.14, 1.16,
> 2.98,
> > and 3.00 VDC.  Given that, I shouldn't think 1.3V would be out of
> bounds.
> 
> The limits are set by the BIOS itself. Note that ATK0110 is a virtual

	"Limits" in terms of what?  The chip apparently does not have any
alarming capability.  Do you mean the text is produced by the BIOS?  Odd,
indeed, if so, since the text inside the BIOS utility is quite different.

> Given that (0.99 + 1.21) / 2 = 1.10, it seems clear to me that the
> nominal value for SB is supposed to be 1.10 V. This is also in line
> with the documented OC values of 1.10, 1.12, 1.14 and 1.16 V. The

	The documentation just takes a shortcut.  There are a ton of
available values in the setup utility, starting with 1.10V and going al the
way to 3.0V in .02V increments.  I did select a value of 1.24V in the BIOS,
but the output of `sensors` does not reflect any change.  That may be
because overclocking is disabled, however.

> documented values of 2.98 and 3.00 V OTOH are odd... You never
> overclock a nominal voltage to more than +25%. I can't actually believe
> that your BIOS offers to overclock +1.10V to +3.00V.

Those are the selectable values.


> So it is well possible that you have a real problem here. It would be
> interesting to see if another user with the same board sees similar
> values. If not, maybe your PSU has an issue or you have wrong settings
> in your BIOS. You may also look for a BIOS update, as the ATK0110 ACPI
> code comes with the BIOS.

The latest BIOS released by the manufacturer is installed - 2702 released
05/30/2011.  It is an Asus Crosshair II Formula motherboard.

> This is an UTF8 vs. non-UTF8 issue. You are running "sensors" with an

I thought it was something like that.

> UTF8 locale, but the e-mail you send apparently lacks proper encoding
> information. This can be solved in two ways: either set the locale to
> non-UTF8 when you run "sensors" (LANG=en_US sensors), or add some
> encoding parameter to the mail command (my version claims utf-8 to be
> the default but apparently that's not your case.)

I don't see anything obvious in the man page, but I will look through the
config files, or perhaps I can specify the language coding when I run mail.
OTOH, in actuality, the use of the degree symbol is incorrect.  The term
45.0°C implies a DIFFERENCE in temperature of 45°C between two bodies.  The
absolute temperature is referenced as 45C.  Thus, there is a huge difference
between 45C and 45K (273.15°), but 45°C and 45°K mean precisely the same
thing.

Anyway, thanks, again.


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Jean Delvare]

On Sat, 17 Nov 2012 03:19:34 -0600, Leslie Rhorer wrote:
> OTOH, in actuality, the use of the degree symbol is incorrect.  The term
> 45.0°C implies a DIFFERENCE in temperature of 45°C between two bodies.  The
> absolute temperature is referenced as 45C.  Thus, there is a huge difference
> between 45C and 45K (273.15°), but 45°C and 45°K mean precisely the same
> thing.

No. From Wikipedia:

"The degree Celsius (°C) can refer to a specific temperature on the
Celsius scale as well as a unit to indicate a temperature interval, a
difference between two temperatures (...)"

The use of "C" to designate degrees Celsius is simply wrong.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org]
> Sent: Saturday, November 17, 2012 5:01 AM
> To: Leslie Rhorer
> Cc: 'Guenter Roeck'; lm-sensors@lm-sensors.org
> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> 
> On Sat, 17 Nov 2012 03:19:34 -0600, Leslie Rhorer wrote:
> > OTOH, in actuality, the use of the degree symbol is incorrect.  The term
> > 45.0°C implies a DIFFERENCE in temperature of 45°C between two bodies.
> The
> > absolute temperature is referenced as 45C.  Thus, there is a huge
> difference
> > between 45C and 45K (273.15°), but 45°C and 45°K mean precisely the same
> > thing.
> 
> No. From Wikipedia:
> 
> "The degree Celsius (°C) can refer to a specific temperature on the
> Celsius scale as well as a unit to indicate a temperature interval, a
> difference between two temperatures (...)"
> 
> The use of "C" to designate degrees Celsius is simply wrong.
> 
> --
> Jean Delvare

	OK, I looked it up, and apparently the definition has changed (in
1989) since the days (late 1970s) when I worked as a physicist in a low
temperature laboratory.  That, or my memory is just failing me.  In any
case, the sky won't fall if my email employs C instead of °C.



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Luca Tettamanti]

T24gU2F0LCBOb3YgMTcsIDIwMTIgYXQgMTA6MTkgQU0sIExlc2xpZSBSaG9yZXIgPGxyaG9yZXJA
bXlncmFuZGUubmV0PiB3cm90ZToKPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4gPiBG
cm9tOiBKZWFuIERlbHZhcmUgW21haWx0bzpraGFsaUBsaW51eC1mci5vcmddCj4gPiBTZW50OiBT
YXR1cmRheSwgTm92ZW1iZXIgMTcsIDIwMTIgMjoxMyBBTQo+ID4gVG86IExlc2xpZSBSaG9yZXIK
PiA+IENjOiAnR3VlbnRlciBSb2Vjayc7IGxtLXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKPiA+IFN1
YmplY3Q6IFJlOiBbbG0tc2Vuc29yc10gR2V0dGluZyBhbGFybXMgdXNpbmcgbG0tc2Vuc29ycwo+
ID4KPiA+IE9uIEZyaSwgMTYgTm92IDIwMTIgMjI6NDU6MDUgLTA2MDAsIExlc2xpZSBSaG9yZXIg
d3JvdGU6Cj4gPiA+ID4gPiA+ID4gU0I6ICAgICAgICAgICAgICAgICArMS4zMCBWICAobWluID0g
ICswLjk5IFYsIG1heCA9ICArMS4yMSBWKQo+ID4gPgo+ID4gPiA+ID4gPiA+IE1CIFRlbXBlcmF0
dXJlOiAgICAgKzQ1LjDCsEMgIChoaWdoID0gKzQ1LjDCsEMsIGNyaXQgPSArOTUuMMKwQykKPiA+
ID4KPiA+ID4KPiA+ID4gPiBrMTB0ZW1wIGlzIHRoZSBBTUQgQ1BVIHRlbXBlcmF0dXJlIGFzIHJl
cG9ydGVkIGJ5IHRoZSBDUFUgaXRzZWxmLiBJdAo+ID4gaXNuJ3QKPiA+ID4gPiByZWFsbHkgYWNj
dXJhdGUuIGFjcGl0ei12aXJ0dWFsIGlzLCBhcyB0aGUgbmFtZSBzYXlzLCBhIHZpcnR1YWwKPiA+
IGRldmljZS4KPiA+ID4gPiBhY3BpdHggaXMgc2hvcnQgZm9yICJBQ1BJIHRoZXJtYWwgem9uZSIu
IEl0IG1heSBhbHNvIHJlZmxlY3QgdGhlIENQVQo+ID4gPiA+IHRlbXBlcmF0dXJlLCBidXQgSSBk
b24ndCBrbm93IGZvciBzdXJlLgo+ID4gPiA+Cj4gPiA+ID4gR3VlbnRlcgo+ID4gPgo+ID4gPiAg
ICAgT0ssIHRoYW5rcyBvbmNlIGFnYWluLiAgSSBndWVzcyBJIHdpbGwgaWdub3JlIHRoZW0uICBJ
IGhvcGUgeW91Cj4gPiA+IGRvbid0IG1pbmQgbWUgYXNraW5nIGFsbCB0aGVzZSBxdWVzdGlvbnMs
IGJ1dCBJIGRvIGhhdmUgYSBjb3VwbGUgbW9yZS4KPiA+IE5vdGUKPiA+ID4gdGhlIHR3byByZXBv
cnRzIGFib3ZlLiAgV2hlcmUgaXMgdGhlIHNlbnNvcnMgcm91dGluZSBnZXR0aW5nIGl0cyBsaW1p
dAo+ID4gPiB2YWx1ZXM/ICBCb3RoIHRoZSBTb3V0aEJyaWRnZSB2b2x0YWdlIGFuZCB0aGUgY2hp
cCBhcnJheSB0ZW1wZXJhdHVyZSBhcmUKPiA+ID4gcmVwb3J0ZWQgb3V0IG9mIGJvdW5kcywgeWV0
IEkgYW0gbm90IG92ZXJjbG9ja2luZywgYXQgYWxsLiAgVGhlIG1hbnVhbAo+ID4gc2F5cwo+ID4g
PiB0aGUgbW90aGVyYm9hcmQgb2ZmZXJzIGxlZ2l0aW1hdGUgT0MgdmFsdWVzIG9mIDEuMTAsIDEu
MTIsIDEuMTQsIDEuMTYsCj4gPiAyLjk4LAo+ID4gPiBhbmQgMy4wMCBWREMuICBHaXZlbiB0aGF0
LCBJIHNob3VsZG4ndCB0aGluayAxLjNWIHdvdWxkIGJlIG91dCBvZgo+ID4gYm91bmRzLgo+ID4K
PiA+IFRoZSBsaW1pdHMgYXJlIHNldCBieSB0aGUgQklPUyBpdHNlbGYuIE5vdGUgdGhhdCBBVEsw
MTEwIGlzIGEgdmlydHVhbAo+Cj4gICAgICAgICAiTGltaXRzIiBpbiB0ZXJtcyBvZiB3aGF0PyAg
VGhlIGNoaXAgYXBwYXJlbnRseSBkb2VzIG5vdCBoYXZlIGFueQo+IGFsYXJtaW5nIGNhcGFiaWxp
dHkuICBEbyB5b3UgbWVhbiB0aGUgdGV4dCBpcyBwcm9kdWNlZCBieSB0aGUgQklPUz8KClllcywg
dGhlIGRyaXZlciBqdXN0IHNob3dzIHRoZSBsYWJlbHMgYXMgcmV0dXJuZWQgYnkgdGhlIEJJT1Mu
Cgo+ICBPZGQsCj4gaW5kZWVkLCBpZiBzbywgc2luY2UgdGhlIHRleHQgaW5zaWRlIHRoZSBCSU9T
IHV0aWxpdHkgaXMgcXVpdGUgZGlmZmVyZW50LgoKWW91IGNhbiB0cnkgbG9hZGluZyB0aGUgbW9k
dWxlIGZvcmNpbmcgdGhlIHVzZSBvZiBhIGRpZmZlcmVudCBBQ1BJIGludGVyZmFjZToKcm1tb2Qg
YXN1c19hdGswMTEwCm1vZHByb2JlIGFzdXNfYXRrMDExMCBuZXdfaWY9MQoKTAoKX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5n
IGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5v
cmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> -----Original Message-----
> From: Luca Tettamanti [mailto:kronos.it@gmail.com]
> Sent: Saturday, November 17, 2012 9:51 AM
> To: Leslie Rhorer
> Cc: Jean Delvare; LM Sensors
> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> 
> > indeed, if so, since the text inside the BIOS utility is quite
> different.
> 
> You can try loading the module forcing the use of a different ACPI
> interface:
> rmmod asus_atk0110
> modprobe asus_atk0110 new_if=1

No, that didn't work.  Loading the module with the new_if=1 parm issues an
error:

FATAL: Error inserting asus_atk0110
(/lib/modules/2.6.32-5-amd64/kernel/drivers/hwmon/asus_atk0110.ko): Unknown
symbol in module, or unknown parameter (see dmesg)

And from dmesg:

[25982.929792] asus_atk0110: Unknown parameter `new_if'


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Luca Tettamanti]

On Sat, Nov 17, 2012 at 5:01 PM, Leslie Rhorer <lrhorer@mygrande.net> wrote:
>
>
>> -----Original Message-----
>> From: Luca Tettamanti [mailto:kronos.it@gmail.com]
>> Sent: Saturday, November 17, 2012 9:51 AM
>> To: Leslie Rhorer
>> Cc: Jean Delvare; LM Sensors
>> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
>>
>> > indeed, if so, since the text inside the BIOS utility is quite
>> different.
>>
>> You can try loading the module forcing the use of a different ACPI
>> interface:
>> rmmod asus_atk0110
>> modprobe asus_atk0110 new_if=1
>
> No, that didn't work.  Loading the module with the new_if=1 parm issues an
> error:
>
> FATAL: Error inserting asus_atk0110
> (/lib/modules/2.6.32-5-amd64/kernel/drivers/hwmon/asus_atk0110.ko): Unknown
> symbol in module, or unknown parameter (see dmesg)
>
> And from dmesg:
>
> [25982.929792] asus_atk0110: Unknown parameter `new_if'

What kernel are you using?

L

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org]
> Sent: Saturday, November 17, 2012 2:13 AM
> To: Leslie Rhorer
> Cc: 'Guenter Roeck'; lm-sensors@lm-sensors.org
> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> >
> > echo "$TID $ATEXT  Value: $F2" | mail -a From:sensor_monitor -s "RAID-
> Server
> > Sensor Event Notification" xxxxxxxxxx@yyyyyyyyy.com
> 
> This is an UTF8 vs. non-UTF8 issue. You are running "sensors" with an
> UTF8 locale, but the e-mail you send apparently lacks proper encoding
> information. This can be solved in two ways: either set the locale to
> non-UTF8 when you run "sensors" (LANG=en_US sensors), or add some
> encoding parameter to the mail command (my version claims utf-8 to be
> the default but apparently that's not your case.)
> 
> --
> Jean Delvare

OK, this works:

mail -a "Content-Type: text/plain; charset=UTF-8" -a From:sensor_monitor -s
"RAID-Server Sensor Event Notification" ...

Would you guys be interested in me posting the script for future reference?
 



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> -----Original Message-----
> From: Luca Tettamanti [mailto:kronos.it@gmail.com]
> Sent: Saturday, November 17, 2012 10:10 AM
> To: Leslie Rhorer
> Cc: Jean Delvare; LM Sensors
> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> 
> On Sat, Nov 17, 2012 at 5:01 PM, Leslie Rhorer <lrhorer@mygrande.net>
> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Luca Tettamanti [mailto:kronos.it@gmail.com]
> >> Sent: Saturday, November 17, 2012 9:51 AM
> >> To: Leslie Rhorer
> >> Cc: Jean Delvare; LM Sensors
> >> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> >>
> >> > indeed, if so, since the text inside the BIOS utility is quite
> >> different.
> >>
> >> You can try loading the module forcing the use of a different ACPI
> >> interface:
> >> rmmod asus_atk0110
> >> modprobe asus_atk0110 new_if=1
> >
> > No, that didn't work.  Loading the module with the new_if=1 parm issues
> an
> > error:
> >
> > FATAL: Error inserting asus_atk0110
> > (/lib/modules/2.6.32-5-amd64/kernel/drivers/hwmon/asus_atk0110.ko):
> Unknown
> > symbol in module, or unknown parameter (see dmesg)
> >
> > And from dmesg:
> >
> > [25982.929792] asus_atk0110: Unknown parameter `new_if'
> 
> What kernel are you using?
> 
> L

2.6.32-5-amd64



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Jean Delvare]

On Sat, 17 Nov 2012 10:10:31 -0600, Leslie Rhorer wrote:
> OK, this works:
> 
> mail -a "Content-Type: text/plain; charset=UTF-8" -a From:sensor_monitor -s
> "RAID-Server Sensor Event Notification" ...
> 
> Would you guys be interested in me posting the script for future reference?

Sure, why not. Our reference script is:
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/daemon/healthd.sh
but it assumes the chip and driver report alarms on out-of-bounds
conditions.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> -----Original Message-----
> From: Jean Delvare [mailto:khali@linux-fr.org]
> Sent: Saturday, November 17, 2012 10:35 AM
> To: Leslie Rhorer
> Cc: 'Guenter Roeck'; lm-sensors@lm-sensors.org
> Subject: Re: [lm-sensors] Getting alarms using lm-sensors
> 
> On Sat, 17 Nov 2012 10:10:31 -0600, Leslie Rhorer wrote:
> > OK, this works:
> >
> > mail -a "Content-Type: text/plain; charset=UTF-8" -a From:sensor_monitor
> -s
> > "RAID-Server Sensor Event Notification" ...
> >
> > Would you guys be interested in me posting the script for future
> reference?
> 
> Sure, why not. Our reference script is:
> http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/daemon/healthd.sh
> but it assumes the chip and driver report alarms on out-of-bounds
> conditions.
> 
> --
> Jean Delvare

OK, well here is one that supports a chip or drive that does not report OOB
conditions.  Comments and bug reports most welcome.  First, there must exist
a colon-delimited table named "sensetab" unique to the output of `sensors`
on the system in question.  Here is an example from this system:

V01:.85:1.6:Vcore Voltage:Vcore:alarm:boot:is low:is critical. Shutting
down...
V02:10.2:13.8:+12V Voltage:+12V:alarm:boot:is out of bounds:is critical.
Shutting down...
V03:4.5:5.5:+5V Voltage:+5V:alarm:boot:is out of bounds:is critical.
Shutting down...
V04:2.97:3.63:+3.3V Voltage:+3.3V:alarm:boot:is out of bounds:is critical.
Shutting down...
V05:1.71:2.09:DDR2:Memory Voltage:alarm:boot:is out of bounds:is critical.
Shutting down...
V06:1.08:1.32:HT:HyperThreading Voltage:alarm:boot:is out of bounds:is
critical. Shutting down...
V07:.99:1.61:SB:SouthBridge Voltage:alarm:boot:is out of bounds:is critical.
Shutting down...
V08:1.08:1.32:BR:BR Voltage:alarm:boot:is out of bounds:is critical.
Shutting down...
V09:2.25:2.85:VDDA:VDDA Voltage:alarm:boot:is out of bounds:is critical.
Shutting down...
V10:.85:1.04:DDR2 TERM.:Memory Termination:alarm:boot:is out of bounds:is
critical. Shutting down...
V11:1.14:1.43:VDDNB:NorthBridge Voltage:alarm:boot:is out of bounds:is
critical. Shutting down...
F01:800::CPU_FAN FAN Speed:CPU Fan:alarm::is failing:
F02:800::CHA_FAN1 FAN Speed:Rear Fan #1::alarm:is failing:
F03:800::CHA_FAN2 FAN Speed:Rear Fan #2::alarm:is failing:
F04:::OPT_FAN1 FAN Speed::alarm::is failing
F05:::OPT_FAN2 FAN Speed::alarm::is failing
F06:::OPT_FAN3 FAN Speed:Water Cooler Fan:alarm::is failing
F07:800::PWR_FAN FAN Speed:Power Supply Fan:alarm::is failing
F08:::CHA_FAN3 FAN Speed:Water Cooler Pump:alarm::is failing
T01:50:85:CPU Temperature:CPU Temperature:alarm:boot:is too high.:is
critical.  Shutting down...
T02:53:85:MB Temperature:Motherboard Temperature:alarm:boot:is too high.:is
critical.  Shutting down... 
T03:::OPT1:Coolant Level:alarm::is too low.  Add coolant.:
T04:::OPT2:::::
T05:::OPT3::::: 
T06:::temp1:::::

In this version, the fields are:
F1 - SensorID
F2 - First boundary value
F3 - Second boundary value
F4 - Name of sensor output by `sesnors`
F5 - Name of sensor sent in e-mail
F6 - Action to take if first boundary is violated ( alarm or boot )
F7 - Action to take if second boundary is violated ( alarm or boot )
F8 - Failure text to send in e-mail if first boundary is violated
F9 - Failure text to send in e-mail if second boundary is violated

These fields can easily be moved, added, or deleted by assigning the -f
values at the top of the script.  Blank fields are ignored, but all fields
should exist on every line.

Now the script itself:

#! /bin/bash

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8

SenseDir=/usr/share/sensors	# Location of files
SenseTab=$SenseDir/sensetab	# Lookup table
SenseStat=$SenseDir/alarm_stat	# Status file containing active alarms, when
the last e-mail was sent in epoch time, and the action taken.
NOTIFY=1200			# Number of seconds between e-mail
notifications for each event

# Field number position identifiers in $SenseTab.  Modify to add, delete, or
move fields in the table
PosSID="-f1"
PosLVAL="-f2"
PosHVAL="-f3"
PosAID="-f4"
PosTID="-f5"
PosBRL1="-f6"
PosBRH1="-f7"
PosBRL2="-f8"
PosBRH2="-f9"

cd $SenseDir

# Check the lower boundary for violations.
lo_check()
{
	if [[ $MINMAX -eq 0 ]]
	then
		(( $(echo "$CVAL > $LVAL" | bc -l) )) && BERRL=1
	else
		(( $(echo "$CVAL < $LVAL" | bc -l) )) && BERRL=2
	fi
	[[ $BERRL -gt 0 ]] && action_check $PosBRL1 $PosBRL2
}

# Check the upper boundary for violations.
hi_check()
{
	(( $(echo "$CVAL > $HVAL" | bc -l) )) && BERRH=1
	[[ $BERRH -gt 0 ]] && action_check $PosBRH1 $PosBRH2
}

# Set the ACTION directive.  1 = Send Alarm  2 = Shutdown
action_check ()
{
	ACTION=1
	[[ $(echo $line | cut -d ":" $1 ) == "boot" ]] && ACTION=2
	ATEXT=$(echo $line | cut -d ":" $2 )		# $ATEXT = Text
action for e-mail
}

# Check if the alarm is already active and if so how long ago the e-mail was
sent.
# Do nothing if the alarm is already active and $NOTIFY seconds or less have
passed.
# Send e-mail and update $SenseStat if more than $NOTIFY seconds have
passed.
alarm_email ()
{
	WRITE=1
	touch $SenseStat				# Make sure the file
exists.
	STATL=$( grep $SID $SenseStat )			# See if the alarm
exists.
	if [[ -n $STATL ]]				# If so, check how
old it is.
	then
		ESEC=$( date +%s )			# Get epoch time.
		SSEC=$( echo $STATL | cut -d ":" -f2 )	# Get elapsed time.
		TSEC=$((ESEC - SSEC))			# Compute the
difference.
		if [[ $TSEC -gt $NOTIFY ]]		# If more than
$NOTIFY seconds have passed, upodate the file
		then
			WRITE=0				# Set up for e-mail
notification
			grep -v $SID $SenseStat > $SenseStat.tmp
			mv $SenseStat.tmp $SenseStat
		fi
	else
		WRITE=0					# Alarm is not yet
active, so set up to send the e-mail and update $SenseStat
	fi

	if [[ $WRITE -eq 0 ]]				# If $WRITE is
reset, send the e-mail and update $SenseStat
	then
		echo "$TID $ATEXT  Value: $F2" | mail -a "Content-Type:
text/plain; charset=UTF-8" -a From:sensor_monitor -s "Server Sensor Event
Notification" xxxxxxxxxxxxx@myemail1.com yyyyyyyyyyyy@myemail2.net
		echo "$SID:$ESEC:$ACTION" >> $SenseStat
		sleep 1
	fi
}

while read line						# Read and process
one line of $SenseTab at a time
do
	SCAN=0
	SID=$( echo $line | cut -d ":" $PosSID )	# $SID = Sensor ID
	AID=$(echo $line | cut -d ":" $PosAID )		# $AID = Sensor Name
	TID=$(echo $line | cut -d ":" $PosTID )		# $TID = Text Name
for e-mail
	FIELDS=$( sensors | grep "$AID:" )		# $FIELDS = Text
from `sensors`
	F2=$( echo $FIELDS | cut -d ":" -f2 )		# $F2 = Description
from `sensors`
	CVAL=${F2% (*}					# $CVAL = Current
Sensor Value
	CVAL=${CVAL//[A-Z°+]/ }
	LVAL=$(grep $SID $SenseTab | cut -d ":" $PosLVAL )	# $LVAL =
Lower Configured Value
	HVAL=$(grep $SID $SenseTab | cut -d ":" $PosHVAL )	# $HVAL =
Higher Configured Value
	AVAL=${FIELDS#* =}				# $AVAL = Lower
Default Value
	AVAL=${AVAL%,*}
	AVAL=${AVAL//[A-Z°+) ]/ }
	BVAL=${FIELDS##* = }				# $BVAL = Higher
Default Value
	BVAL=${BVAL//[A-Z°+) ]/ }
	[[ -n $LVAL ]] && SCAN=1			# $SCAN: 1 - Lower
value only
	[[ -n $HVAL ]] && SCAN=2			# $SCAN: 2 - Higher
value only
	[[ -n $LVAL && -n $HVAL ]] && SCAN=3		# $SCAN: 3 - Lower &
Higher value
	MINMAX=1					# $MINMAX: 1 -
Minimum & Maximum
	echo $F2 | grep -q crit && MINMAX=0		# $MINMAX: 0 - High
& Critical
	BERRL=0						# $BERRL: 0 - No
Alarm, 1 - Above High, 2 - Below Minimum
	BERRH=0						# $BERRH: 0 - No
Alarm, 1 - Above Maximum / Critical
	ACTION=0					# $ACTION: 0 - Do
Nothing, 1 - Send e-mail, 2 - Shutdown

	case "$SCAN" in		# Check low boundary, high boundary, or both
based upon whether they are defined in $SenseStat.
  	1)
		lo_check	# Check low boundary.
	;;
	2)
		hi_check	# Check high boundary.
	;;
	3)
		lo_check	# Check both.
		hi_check
	;;
	esac

	case "$ACTION" in	# Perform action based upon values in
$SenseTab.  alarm = send e-mail  boot = shutdown
	0)			# Take no action, except to clear the alarm
in $SenseStat, if it is active.
		grep -q $SID $SenseStat
		if [[ $? -eq 0 ]]
		then
			grep -v $SID $SenseStat > $SenseStat.tmp
			mv $SenseStat.tmp $SenseStat
		fi
	;;
	2)			# Shutdown, allowing enough time for the
e-mail to be sent
		shutdown -py 30 &
	;&
	1)			# Send the e-mail
		alarm_email
	;;
	esac
done < $SenseTab


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

> exists.
> 	if [[ -n $STATL ]]				# If so, check how
> old it is.
> 	then
> 		ESEC=$( date +%s )			# Get epoch time.
> 		SSEC=$( echo $STATL | cut -d ":" -f2 )	# Get elapsed time.
> 		TSEC=$((ESEC - SSEC))			# Compute the
> difference.
> 		if [[ $TSEC -gt $NOTIFY ]]		# If more than
> $NOTIFY seconds have passed, upodate the file
> 		then
> 			WRITE=0				# Set up for e-mail
> notification
> 			grep -v $SID $SenseStat > $SenseStat.tmp
> 			mv $SenseStat.tmp $SenseStat
> 		fi
> 	else
> 		WRITE=0					# Alarm is not yet
> active, so set up to send the e-mail and update $SenseStat
> 	fi
> 
> 	if [[ $WRITE -eq 0 ]]				# If $WRITE is
> reset, send the e-mail and update $SenseStat
> 	then
> 		echo "$TID $ATEXT  Value: $F2" | mail -a "Content-Type:
> text/plain; charset=UTF-8" -a From:sensor_monitor -s "Server Sensor Event
> Notification" xxxxxxxxxxxxx@myemail1.com yyyyyyyyyyyy@myemail2.net
> 		echo "$SID:$ESEC:$ACTION" >> $SenseStat
> 		sleep 1
> 	fi
> }
> 
> while read line						# Read and
process
> one line of $SenseTab at a time

Ugh.  That looks terrible.  Is there a way to prevent the mail system from
wrapping the text, or would it be better served to make them attachments?


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Leslie Rhorer]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

	OK, I'm sending this back out.  I've made a couple of changes,
anyway.  There is a little bug in the script, but I've beaten myself around
the head and can't figure out what is causing it.  If someone can tell me
what it is, I will happily fix it.  I put a little trap in the code which
checks to make sure the sensor name in the sensetab file matches a line from
the output of `sensors`.  If not, it sends an e-mail and jumps to the next
sensor.  For some reason, it is sending out two e-mails.
 


[-- Attachment #2: sensetab --]
[-- Type: application/octet-stream, Size: 1786 bytes --]

V01:.85:1.6:Vcore Voltage:Vcore:alarm:boot:is low:is critical. Shutting down...
V02:10.2:13.8:+12V Voltage:+12V:alarm:boot:is out of bounds:is critical. Shutting down...
V03:4.5:5.5:+5V Voltage:+5V:alarm:boot:is out of bounds:is critical. Shutting down...
V04:2.97:3.63:+3.3V Voltage:+3.3V:alarm:boot:is out of bounds:is critical. Shutting down...
V05:1.71:2.09:DDR2:Memory Voltage:alarm:boot:is out of bounds:is critical. Shutting down...
V06:1.08:1.32:HT:HyperThreading Voltage:alarm:boot:is out of bounds:is critical. Shutting down...
V07:.99:1.61:SB:SouthBridge Voltage:alarm:boot:is out of bounds:is critical. Shutting down...
V08:1.08:1.32:BR:BR Voltage:alarm:boot:is out of bounds:is critical. Shutting down...
V09:2.25:2.85:VDDA:VDDA Voltage:alarm:boot:is out of bounds:is critical. Shutting down...
V10:.85:1.04:DDR2 TERM.:Memory Termination:alarm:boot:is out of bounds:is critical. Shutting down...
V11:1.14:1.43:VDDNB:NorthBridge Voltage:alarm:boot:is out of bounds:is critical. Shutting down...
F01:800::CPU_FAN FAN Speed:CPU Fan:alarm::is failing:
F02:800::CHA_FAN1 FAN Speed:Rear Fan #1::alarm:is failing:
F03:800::CHA_FAN2 FAN Speed:Rear Fan #2::alarm:is failing:
F04:::OPT_FAN1 FAN Speed::alarm::is failing
F05:::OPT_FAN2 FAN Speed::alarm::is failing
F06:::OPT_FAN3 FAN Speed:Water Cooler Fan:alarm::is failing
F07:800::PWR_FAN FAN Speed:Power Supply Fan:alarm::is failing
F08:::CHA_FAN3 FAN Speed:Water Cooler Pump:alarm::is failing
T01:50:85:CPU Temperature:CPU Temperature:alarm:boot:is too high.:is critical.  Shutting down...
T02:53:85:MB Temperature:Motherboard Temperature:alarm:boot:is too high.:is critical.  Shutting down... 
T03:::OPT1:Coolant Level:alarm::is too low.  Add coolant.:
T04:::OPT2:::::
T05:::OPT3::::: 
T06:::temp1:::::

[-- Attachment #3: alarm_scan --]
[-- Type: application/octet-stream, Size: 5087 bytes --]

#! /bin/bash

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8

SenseDir=/usr/share/sensors	# Location of files
SenseTab=$SenseDir/sensetab	# Lookup table
SenseStat=$SenseDir/alarm_stat	# Status file containing active alarms, when the last e-mail was sent in epoch time, and the action taken.
NOTIFY=1200			# Number of seconds between e-mail notifications for each event

# Field number position identifiers in $SenseTab.  Modify to add, delete, or move fields in the table.
PosSID="-f1"
PosLVAL="-f2"
PosHVAL="-f3"
PosAID="-f4"
PosTID="-f5"
PosBRL1="-f6"
PosBRH1="-f7"
PosBRL2="-f8"
PosBRH2="-f9"

cd $SenseDir

# Command to send mail.  Modify to suit individual needs.
mail_out ()
{
	echo $1 | mail -a "Content-Type: text/plain; charset=UTF-8" -a From:sensor_monitor -s "$(hostname) Sensor Event Notification" xxxxxxxxx@myemaill1.com yyyyyyyy@myemail2.com 
}


# Check the lower boundary for violations.
lo_check()
{
	if [[ $MINMAX -eq 0 ]]
	then
		(( $(echo "$CVAL > $LVAL" | bc -l) )) && BERRL=1
	else
		(( $(echo "$CVAL < $LVAL" | bc -l) )) && BERRL=2
	fi
	[[ $BERRL -gt 0 ]] && action_check $PosBRL1 $PosBRL2
}

# Check the upper boundary for violations.
hi_check()
{
	(( $(echo "$CVAL > $HVAL" | bc -l) )) && BERRH=1
	[[ $BERRH -gt 0 ]] && action_check $PosBRH1 $PosBRH2
}

# Set the ACTION directive.  1 = Send Alarm  2 = Shutdown
action_check ()
{
	ACTION=1
	[[ $(echo $line | cut -d ":" $1 ) == "boot" ]] && ACTION=2
	ATEXT=$(echo $line | cut -d ":" $2 )		# $ATEXT = Text action for e-mail
}

# Check if the alarm is already active and if so how long ago the e-mail was sent.
# Do nothing if the alarm is already active and $NOTIFY seconds or less have passed.
# Send e-mail and update $SenseStat if more than $NOTIFY seconds have passed.
alarm_email ()
{
	WRITE=1
	touch $SenseStat				# Make sure the file exists.
	STATL=$( grep $SID $SenseStat )			# See if the alarm exists.
	if [[ -n $STATL ]]				# If so, check how old it is.
	then
		ESEC=$( date +%s )			# Get epoch time.
		SSEC=$( echo $STATL | cut -d ":" -f2 )	# Get elapsed time.
		TSEC=$((ESEC - SSEC))			# Compute the difference.
		if [[ $TSEC -gt $NOTIFY ]]		# If more than $NOTIFY seconds have passed, upodate the file
		then
			WRITE=0				# Set up for e-mail notification
			grep -v $SID $SenseStat > $SenseStat.tmp
			mv $SenseStat.tmp $SenseStat
		fi
	else
		WRITE=0					# Alarm is not yet active, so set up to send the e-mail and update $SenseStat
	fi

	if [[ $WRITE -eq 0 ]]				# If $WRITE is reset, send the e-mail and update $SenseStat
	then
		mail_out "$TID $ATEXT  Value: $F2"
		echo "$SID:$ESEC:$ACTION" >> $SenseStat
		sleep 1
	fi
}

while read line						# Read and process one line of $SenseTab at a time
do
	SCAN=0
	SID=$( echo $line | cut -d ":" $PosSID )	# $SID = Sensor ID
	AID=$(echo $line | cut -d ":" $PosAID )		# $AID = Sensor Name
	TID=$(echo $line | cut -d ":" $PosTID )		# $TID = Text Name for e-mail
	FIELDS=$( sensors | grep "$AID:" )		# $FIELDS = Text from `sensors`

	if [[ -z $FIELDS ]]				# Check to make sure $AID is a valid line from the output of `sensors`.
	then
		mail_out "$AID field not found in output of sensors on $(hostname)"
		continue
	fi

	F2=$( echo $FIELDS | cut -d ":" -f2 )		# $F2 = Description from `sensors`
	CVAL=${F2% (*}					# $CVAL = Current Sensor Value
	CVAL=${CVAL//[A-Z°+]/ }
	LVAL=$(grep $SID $SenseTab | cut -d ":" $PosLVAL )	# $LVAL = Lower Configured Value
	HVAL=$(grep $SID $SenseTab | cut -d ":" $PosHVAL )	# $HVAL = Higher Configured Value
	AVAL=${FIELDS#* =}				# $AVAL = Lower Default Value
	AVAL=${AVAL%,*}
	AVAL=${AVAL//[A-Z°+) ]/ }
	BVAL=${FIELDS##* = }				# $BVAL = Higher Default Value
	BVAL=${BVAL//[A-Z°+) ]/ }
	[[ -n $LVAL ]] && SCAN=1			# $SCAN: 1 - Lower value only
	[[ -n $HVAL ]] && SCAN=2			# $SCAN: 2 - Higher value only
	[[ -n $LVAL && -n $HVAL ]] && SCAN=3		# $SCAN: 3 - Lower & Higher value
	MINMAX=1					# $MINMAX: 1 - Minimum & Maximum
	echo $F2 | grep -q crit && MINMAX=0		# $MINMAX: 0 - High & Critical
	BERRL=0						# $BERRL: 0 - No Alarm, 1 - Above High, 2 - Below Minimum
	BERRH=0						# $BERRH: 0 - No Alarm, 1 - Above Maximum / Critical
	ACTION=0					# $ACTION: 0 - Do Nothing, 1 - Send e-mail, 2 - Shutdown

	case "$SCAN" in		# Check low boundary, high boundary, or both based upon whether they are defined in $SenseStat.
  	1)
		lo_check	# Check low boundary.
	;;
	2)
		hi_check	# Check high boundary.
	;;
	3)
		lo_check	# Check both.
		hi_check
	;;
	esac

	case "$ACTION" in	# Perform action based upon values in $SenseTab.  alarm = send e-mail  boot = shutdown
	0)			# Take no action, except to clear the alarm in $SenseStat, if it is active.
		grep -q $SID $SenseStat
		if [[ $? -eq 0 ]]
		then
			grep -v $SID $SenseStat > $SenseStat.tmp
			mv $SenseStat.tmp $SenseStat
		fi
	;;
	2)			# Shutdown, allowing enough time for the e-mail to be sent
		shutdown -py 30 &
	;&
	1)			# Send the e-mail
		alarm_email
	;;
	esac
done < $SenseTab

[-- Attachment #4: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Luca Tettamanti]

On Sat, Nov 17, 2012 at 5:13 PM, Leslie Rhorer <lrhorer@mygrande.net> wrote:
>> >> You can try loading the module forcing the use of a different ACPI
>> >> interface:
>> >> rmmod asus_atk0110
>> >> modprobe asus_atk0110 new_if=1
>> >
>> > No, that didn't work.  Loading the module with the new_if=1 parm issues
>> an
>> > error:
>> >
>> > FATAL: Error inserting asus_atk0110
>> > (/lib/modules/2.6.32-5-amd64/kernel/drivers/hwmon/asus_atk0110.ko):
>> Unknown
>> > symbol in module, or unknown parameter (see dmesg)
>> >
>> > And from dmesg:
>> >
>> > [25982.929792] asus_atk0110: Unknown parameter `new_if'
>>
>> What kernel are you using?
>
> 2.6.32-5-amd64

Ah, it's too old, it does not support the override. Can you send me a
copy of this file:
/sys/firmware/acpi/tables/DSDT (or /proc/acpi/dsdt if you don't have
the sysfs file).
I'll see if there might be a problem with the detection heuristic.

Luca

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Getting alarms using lm-sensors

[Luca Tettamanti]

On Tue, Nov 20, 2012 at 2:42 PM, Luca Tettamanti <kronos.it@gmail.com> wrote:
> On Sat, Nov 17, 2012 at 5:13 PM, Leslie Rhorer <lrhorer@mygrande.net> wrote:
>>> >> You can try loading the module forcing the use of a different ACPI
>>> >> interface:
>>> >> rmmod asus_atk0110
>>> >> modprobe asus_atk0110 new_if=1
>>> >
>>> > No, that didn't work.  Loading the module with the new_if=1 parm issues
>>> an
>>> > error:
>>> >
>>> > FATAL: Error inserting asus_atk0110
>>> > (/lib/modules/2.6.32-5-amd64/kernel/drivers/hwmon/asus_atk0110.ko):
>>> Unknown
>>> > symbol in module, or unknown parameter (see dmesg)
>>> >
>>> > And from dmesg:
>>> >
>>> > [25982.929792] asus_atk0110: Unknown parameter `new_if'
>>>
>>> What kernel are you using?
>>
>> 2.6.32-5-amd64
>
> Ah, it's too old, it does not support the override. Can you send me a
> copy of this file:
> /sys/firmware/acpi/tables/DSDT (or /proc/acpi/dsdt if you don't have
> the sysfs file).
> I'll see if there might be a problem with the detection heuristic.

Nope, there's only one interface (GITM), the BIOS probably has
hard-coded labels and does not read the ACPI table.

Luca

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors