[Cialug] uptime

[Daniel A. Ramaley]

On Friday 07 July 2006 15:23, D. Joe Anderson wrote:
>Heh.  I thought one needed to reboot, too, but kept my mouth
>shut on this one for a while because for a time there was a
>project I saw referred to as "two-kernel monte" that would allow
>you to start a new kernel from a running one.  That was back in
>the 2.4 days, at least, maybe earlier, and I hadn't heard much
>about it since.  I thought it was defunct, but then you never
>know.  LVM hit a rough patch there for a while, and now it seems
>to be common enough, for example.
>
>Anyway, my expectation is that even with something like that
>going, the uptime counter would reset anyway.

I remember hearing about that as well. If i remember correctly, it would 
basically load the new kernel into memory, make the new one take over 
operations of the old kernel, then remove the old kernel. Both kernels 
had to have been compiled with the proper extension to make it happen, 
though. And i don't think it could be loaded as a module.

One thing that i've thought is that perhaps if the system undergoes a 
scheduled reboot that it should write the uptime to a file and then 
when the system boots reload the old uptime and continue keeping time 
from there. What is really important for most machines is not how long 
it has been since last reboot, but how long it has been since the last 
*unscheduled* reboot. I'm not sure how all the details would work to 
make this happen. I would guess that some kernel code would have to be 
modified to allow setting the uptime value on boot. And some other 
system changes would be necessary. For example, if you used "at", 
"cron" or "shutdown -t" to schedule a reboot, then the uptime would 
have to be written somewhere in /var. On boot, if the uptime file was 
present the uptime would have to be read and the file deleted. There is 
probably a better way; i just thought of this. But i've wondered why no 
one has done such a thing (of if they have why it isn't more widely 
known since lots of people like high uptimes). The big downside, of 
course, is that you'd have someone who would mess with the uptime 
statistic and have a machine that reports a 30 year uptime! Which would 
be kind of neat, but would make one start to question the value of 
keeping uptime statistics at all.
-- 
------------------------------------------------------------------------
Dan Ramaley                            Dial Center 118, Drake University
Network Programmer/Analyst             2407 Carpenter Ave
+1 515 271-4540                        Des Moines IA 50311 USA