Hi,
When I query a RedHat EL 3 system which has been up for 8 hours, 57 minutes, using an snmp query for uptime, I get back a value of :
3220881
My understanding is this is in 1/100ths of a second, so about 32,208 seconds, which is about 536 minutes (32,208/60), which is 8.94 hours (536/60). OK, that looks right.
I then query a FreeBSD system with the same query, only it has been up for 349 days. I get back a value of 11908608. Supposedly that is also in 1/100ths of seconds, so 119,086 seconds, which is 1,984 minutes (119,086/60), which is 33 hours, which is obviously not even close.
Then I query a RedHat 7.3 system which has been up for 2 days, 9h, 32m. I get an answer of 1227. I don't even have to start to try and calculate that one. The numbers don't line up.
I realized that the numbers returned by an snmp uptime query don't refer to the system uptime, but to the snmp daemon process uptime. I only recently installed it on all of the systems, and in fact only installed it on the last one in the middle of writing this message. The first system is correct, as I installed snmp on it yesterday and rebooted it just this morning, so the snmp daemon process uptime would match the system uptime.
This isn't really a question, just an observation, and post for others who might also be wondering why the results of the 'uptime' command and the snmp uptime query don't always match. This doesn't seem like the best way for the snmpd process to determine system uptime, since on Linux/FreeBSD/Windows, the OS provides this info.
SNMP uptime query observation
Moderators: Developers, Moderators
Your FreeBSD uptime counter likely has rolled over a time or two, hence the too small number.
| Scripts: Monitor processes | RFC1213 MIB | DOCSIS Stats | Dell PowerEdge | Speedfan | APC UPS | DOCSIS CMTS | 3ware | Motorola Canopy |
| Guides: Windows Install | [HOWTO] Debug Windows NTFS permission problems |
| Tools: Windows All-in-one Installer |
That's what I thought might be happening also. But that isn't the problem.
SNMP's uptime shows the time the snmpd daemon has been running, and here is the proof:
qmail# ./snmp_uptime.pl localhost
SNMP::Info::_global uptime : sysUpTime.0
uptime: 17057898
qmail# /usr/local/etc/rc.d/snmpd.sh stop
Stopping snmpd.
Waiting for PIDS: 28827.
qmail# /usr/local/etc/rc.d/snmpd.sh start
Starting snmpd.
qmail# ./snmp_uptime.pl localhost
SNMP::Info::_global uptime : sysUpTime.0
uptime: 347
You'll see the same behavior on RHEL3 and RedHat 7.3 also. This is not the case with OSX, which I'm still not sure where it is getting its numbers.
I realize this is not a Cacti issue. Just an observation I thought worth sharing.
SNMP's uptime shows the time the snmpd daemon has been running, and here is the proof:
qmail# ./snmp_uptime.pl localhost
SNMP::Info::_global uptime : sysUpTime.0
uptime: 17057898
qmail# /usr/local/etc/rc.d/snmpd.sh stop
Stopping snmpd.
Waiting for PIDS: 28827.
qmail# /usr/local/etc/rc.d/snmpd.sh start
Starting snmpd.
qmail# ./snmp_uptime.pl localhost
SNMP::Info::_global uptime : sysUpTime.0
uptime: 347
You'll see the same behavior on RHEL3 and RedHat 7.3 also. This is not the case with OSX, which I'm still not sure where it is getting its numbers.
I realize this is not a Cacti issue. Just an observation I thought worth sharing.
-
- Cacti User
- Posts: 311
- Joined: Tue Jun 29, 2004 12:52 pm
- Location: Indiana
From: http://www.alvestrand.no/objectid/1.3.6.1.2.1.1.3.html
OID value: 1.3.6.1.2.1.1.3
OID description:
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The time (in hundredths of a second) since the
network management portion of the system was last
re-initialized."
OID value: 1.3.6.1.2.1.1.3
OID description:
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The time (in hundredths of a second) since the
network management portion of the system was last
re-initialized."
Who is online
Users browsing this forum: No registered users and 2 guests