How do I change "uptime"?
 

Being a newbie, I did check for similar threads before posting this message. There is an existing thread that contains a very similar question to mine, but since the existing thread is approx. 7 years old, I thought I would go ahead and post my question.

I am wondering how I can change "uptime" on a Linux 2.6 box. I want to do this to test a complex wireless system that contains multiple Linux boxes.

I am able to change "uptime" on a Solaris or VxWorks box with "lbolt" and "tickSet" commands respectively. But these commands do not work on Linux boxes (no surprise there).

Any ideas out there?

Thanks.

Hi -

That's a bit like a used car salesman asking "How can I set the odometer back?"

I'm not sure you *can* change it; I'm not sure you *should* change it (in the sense "I'm not sure what might break if you tried").

Nevertheless...

Your best bet is to see if you can modify it via "/proc/uptime":

http://www.redhat.com/docs/manuals/e...oc-uptime.html

http://www.redhat.com/docs/manuals/l...e/ch-proc.html

'Hope that helps .. PSM

Thank you for your quick response. You touched on one of my goals for changing "uptime" - to see what does break. This is somewhat of an "adversarial" test to see how the system would handle any changes to "uptime".

Anyway, when logged on as "root", and changing /proc/uptime to have write permissions, I tried to change /proc/uptime with "echo xxxxx > /proc/uptime" (where xxxxx is a number of seconds). Either the echo command does not work or my change is immediately over-written by some application because I do not see the new second value in /proc/uptime.

Perhaps /proc/uptime is not changeable in that configuration changes to this file are not communicated to the kernel?

AFAIK uptime just asks the kernel how long it has been running for.
The kernel replies.
The answer is not configurable. And why should it be? That would be like asking the kernel to lie.

If you want a different uptime result, you'll have to reboot. Then your uptime will start from the time the kernel's uptime routine was launched.

I do not understand what this has to do with testing "a complex wireless system that contains multiple Linux boxes."

What, exactly, are you trying to do?

Hi,

The intent behind changing "uptime" is to walk through various age points and observe system behavior. For example, here are a couple of the defined "magic" age points that are used in my test script:

Power of 2 Integer Value Age Pt (Days) Age Pt (Seconds)
2^7 128 5.3333333333 460800
2^8 256 10.6666666667 921600

For each age point, certain components have uptime set 90 minutes prior to that age point, then the script sleeps for 2.5 hours to let the system run through that age point. After the 2.5 hours expires, the uptime is set to the next age point
(minus 90 minutes). The age points above could be associated with timers using a char vs. an unsigned char, and the goal here would be to catch improper use of a char for storing a timer value. So I would like to be able to increase the uptime counter to be able to walk through the data points (and several others) listed above.

Hope that clarifies a bit. Our test systems get booted periodically so the uptime values we see in our test labs don't really reflect what may (or should) be seen in the field.

No, not at all. Your post makes no sense.

Again, I ask What are you trying to do?

Please try to explain your situation better. Some details would be good.

Hi,

Instead of 'uptime' why not use 'hwclock' to control your events.

The RTC would allow you to do what you have presented so far.

I don't believe you can (easily) do what you want - unless you can convince your application(s) to use another (munged) time reference.
/proc is not a "normal" filesystem in that it (usually) has no persistence. The data you see by reading /proc/uptime is created in response to you reading it. That particular "file" is read only - as are most. The code that provides the data ignores any attempt to update the "file", even if it were successful.
The code is quite straightforward ../fs/proc/uptime.c

Playing with the RTC won't help either as that is only read at boot AFAIK.

Thinking this over, I don't see what benefit would it give to be able to change uptime just to get it look like the machine had been running for a different time than it really has. Physically nothing has changed, so you're in a way making up results if something seems to change (i.e. the reason for that change isn't the actual uptime, but a change in plain numbers). And if you're only interested in what happens if your input (uptime) changes, you could just as well make an artificial input, for example a script that returned an "uptime" chosen by you. Your test would not know the difference, because the underlying physical system was exactly the same, the only thing changing the output of "uptime", which you can replace with whatever you like.

I hope I understood you wrong (if I did, please be patient and explain it thouroughly again, thank you), but if I didn't and you really want reliable results, all you can do is run the machines (rebooting if and when needed) to the uptimes you want to check and thus get proper results.

Hi,

I don't see why it would be a problem using the 'hwclock' to setup a period timer;

Somewhat along the lines of what the OP has stipulated. The task would require the sysclock and hwclock to be used along with stored variables.

Uptime isn't what you want then. All uptime does is measure the elapsed time since the last boot - it isn't used for anything.

You want to set the system DATE to some value and see what happens when it crosses that date (jan 1 1970 at 0:00:00 is when the system clock starts, and negative numbers are allowed).

There was a 32 bit overflow in 2038... but that won't overflow on 64 bit systems (ints were changed to 64 bit values during system compilation... and it may even have been changed on 32 bit systems - haven't looked recently).

Applications use the system date - not the uptime for timing things.

Now, in some circumstances, there is a delta time used for timing things (usually very short timing). But again, the uptime is not used to compute the short timing interval.

One last thing: a reference to the UNIX time (used by Linux):

http://en.wikipedia.org/wiki/Unix_time