| Age | Commit message (Collapse) | Author |
|---|
|
that the time always goes forward, so reports are neither duplicated nor lost.
Report state changes stabilised through dampening immediately, instead of delay-
ing them until the next reporting window; previously, it was common for check()
to lag one second behind report(), hence the initial report was delayed one
extra minute (this then reduces the number of sleep(3)/nanosleep(2) calls, too).
ok ckuethe; some man-page suggestions jmc
|
|
ckuethe@
|
|
- it doesn;t make sense to list esm(4) in SEE ALSO
|
|
without regard for the specific value. It's a big heavy binary hammer...
ok & style feedback from cnst
|
|
ok mbalmer
|
|
you might want to toggle an error light when a sensor is not OK. Perhaps
you might want to schedule a shutdown if a sensor is reporting bad news.
Now you can do this, and cancel that pending shutdown (or turn off the error
light) if the sensor decides all is well.
ok mbalmer (who came up with an almost identical diff months ago)
useful feedback and generally positive responses from deraadt, henning, msf
|
|
partly spotted by bluhm@ grunk@; ok grunk@
|
|
|
|
|
|
document how values are parsed in sensorsd.conf(5).
ok deraadt@; man-page ok/help jmc@
|
|
the impression that alerts are only issued when things go wrong, not when they
come back to specification -- but this was never the case with sensorsd.
Whilst here, also zip some useless examples, as we now have so many.
Discussed with jmc@
|
|
mechanism; ok jmc@ henning@
|
|
even if it is present in certain dictionaries (it is). Also, it doesn't add
that much to .Nd anyhow. Requested by jmc@
|
|
fix description of when the command is executed (it was wrong from the start);
say a few more words about automatic monitoring of all sensors that keep state.
ok henning@
|
|
* add myself to the copyright; remove unneeded synopsis
* invalid sensors can now be monitored as such (since c2k7)
* manual boundaries for smart sensors are no longer ignored (since c2k7)
* populate history with 4.1 and 4.2 additions
* add caveats section documenting a long-standing misconception and a workaround
some help jmc@; ok jmc@
|
|
|
|
|
|
|
|
more consistent with the current sensors framework, conserves some memory,
and will make it easier to implement hotplugging and other nifty features
in the future. This does not change any other functionality ATM.
OK henning@, beck@.
|
|
|
|
Improves support for both 'smart' (those providing sensor status) and
'old-style' sensors.
Due to re-design, the following improvements are now present and many
flaws are now gone:
== for smart sensors ==
* automatically monitor all sensors that provide status by themselves,
with the possibility to ignore certain individual sensors or sensors
of certain type (appropriate template for sensorsd.conf is included)
* report actual sensor status as provided by the driver. Previously,
WARN, CRITICAL and UNKNOWN statuses were considered the same, but
now they are different and will be reported separately. This also
improves readability of the log-files and consistency with sysctl
output.
* ability to ignore status provided by the driver with the 'istatus'
keyword ("ignore automatic status" or "I set the status"), with the
possibility to set your own settings for acceptable limits.
Previously, it was not possible to set any kind of user limits for
those sensors that had their own status facilities.
== for old-style sensors ==
* previously, lm(4)-style fans that were flagged SENSOR_FINVALID during
sensorsd startup were completely ignored, but now their invalid status
is appropriately reported, and they are monitored again when they come
out of their invalid mode
* previously, a sensor that had an empty entry in the configuration file
was reported to be "within limits", but now it will not be monitored
at all (unless, of cause, it provides its own status)
As a bonus, sensorsd syslog entries should now be shorter, and the
majority of them will fit on one line on 80-column terminals.
ok beck@, henning@, deraadt@
|
|
usable by default, where we will monitor all sensors that automatically
provide status, and this watch_cnt won't make much sense. Besides, upon
startup, sensorsd already shows all sensors that it is going to monitor,
making this watch_cnt rather unimportant.
ok henning@
|
|
|
|
complete sysctl name does not yield anything; ok henning, otto
|
|
if a sensor is always bad, but sometimes goes OK for only a few seconds,
we want to ignore that bogus change as well
also fix setting if last_val.
from Constantine, ok mickey
|
|
|
|
from cnst+openbsd@bugmail.mojo.ru
|
|
|
|
|
|
provide dampenning for negative events and simultaneously increase
polling frequency accordingly to provide same rate of reporting.
mbalmer@ beck@ deraadt@ ok
|
|
parser; deraadt@ ok
|
|
|
|
|
|
raid controllers; marco@ ok
|
|
ok dlg
|
|
there were no gaps ever. these days, we can have holes or start later.
so on start scan 0..255 and do not abort if there's no entry, probe 'em
all.
found and analyzed by Sam Chill <samchill@gmail.com>, ok theo
|
|
change sensor_status to sensorsd_status
ok deraadt@
|
|
|
|
fails with something else than ENOENT.
suggested by tedu@ ok henning@
|
|
the last sensor and don't monitor sensors, which are marked invalid.
ok henning@
|
|
ok jsg@ deraadt@
|
|
ok grange@
|
|
ok grange@, dlg@, henning@
|
|
|
|
|
|
from michael knudsen;
ok henning@
|
|
|
|
moritz@; while around take care of snprintf return values
help and ok moritz@, henning@
|
|
change an article;
|
|
|
