Hi all,

I'm trying to find out if there's a way to force the value of a Linux system's uptime to a specific value?

I tried the couple of basics like changing the system clock, writing to /proc/uptime etc but no luck.

I read over the man pages for sysinfo and tried looking around the forums but it seems to be an unusual request.

The reason is I'd like to be able to confirm whether a patch we will apply to Oracle 10g will indeed be fixed. The bug occurs after the system has been running for more than 249 days (and I don't want to have to wait that long!).

Thanks in advance.

Soliax.

in all honesty i doubt the bug actually has to do with the value 'uptime' returnes! that would be very very unlikely.
your best bet would anyway be to let oracle know of the issue and when you have noticed it to show up.

Better to use the clock approach. Stop NTP (and make sure it doesn't start on reboot), then change the time and reboot. Shutdown should write the time back into the BIOS - if not, do it manually.
Let it come up as normal with a fudged date and do your testing. Simply starting NTPD should set everything back to normal I would expect.

oracle is the most stable database i know of. i connot understand why you guys think it could have anything to do with the clock or the update of the system. i seriously cannot imagine that being the case, unless you mean by 'bug' that your update license has expired, which is not how oracle works iirc!
rather if oracle has run for that long, not the system itself (neither if the system claims to have run for that long).
think of full /var/log or other stuff (which should not cause oracle to crash)
there are countless things that could be the cause of a bug after a system ran for a longer amount of time, though it could also be that if under heavier load the bug appears way earlier(?).
again - i cannot repeat this often enough - i highly doubt it has to do with the system time or uptime!

It's an official bug with Oracle 10g. Google for "patch 4612267". The last message on the following thread:

http://forums.oracle.com/forums/thre...sageID=2333424

Indicates Oracle uses a signed integer instead of an unsigned one for the return from times(). For 2.4 kernels (which I'm using, Oracle's component gets into an infinite loop after 248 days, so it technically doesn't crash but rather just stop responding). I haven't looked into the specifics of the bug, but was wondering also out of curiousity what would be involved in forcing a specific uptime, wether by modifying the sysinfo()'s returned value of uptime or playing with the jifffies / HZ values.

wow - this is sad! my opinioin on oracle as just sunk drastically! :-(

What happened when you tried to write to /proc/uptime? Did you get an error message?

In my very limited way of looking at things, I thought that should 'work' in changing the uptime, although it might do something nasty - like crash - the system in doing so.

...you can say that again...the only reason that I read this thread was because I coudn't think of any reason that anyone would want to do that, so now I am, at least, better informed.

Nothing. I didn't get any errors (I just went echo X X > /proc/uptime) nor did anything get written to /proc/uptime (the original values stayed there).

The approach I'm doing now is recompiling the kernel after having modified it's sysinfo() implementation to return sysinfo struct type with the member uptime with it's real value added to a base of 249 days (in seconds).

I'm having other issues with getting the kernel to compile with the driver for our RAID adaptor so need to get that fixed first...

I was able to figure it out by myself eventually.

I am running RHEL 3 with kernel 2.4.21-50.EL. I modified the kernel source (kernel/sys.c) so that that the times() function would return a value big enough to cause the Oracle bug. Note, this doesn't change the actual output of uptime if you run the uptime command.

asmlinkage long sys_times(struct tms * tbuf)
{
struct tms times;
/*
* In the SMP world we might just be unlucky and have one of
* the times increment as we use it. Since the value is an
* atomically safe type this is just fine. Conceptually its
* as if the syscall took an instant longer to occur.
*/
if (tbuf) {
times.tms_utime = kernel_timeval_to_clock_t(&current->utime);
times.tms_stime = kernel_timeval_to_clock_t(&current->stime);
times.tms_cutime = kernel_timeval_to_clock_t(&current->cutime);
times.tms_cstime = kernel_timeval_to_clock_t(&current->cstime);
if (copy_to_user(tbuf, &times, sizeof(struct tms)))
return -EFAULT;
}
//return jiffies;
return jiffies + (21513600 * 100); /* plus 249 days */
}