2

RHEL 6.3

We just rebooted last night and I have many many processes showing they have been running FOREVER. Examples:

root        11     2 99 Feb23 ?        212429-04:31:07 [kworker/0:1]    
root         1     0 99 Feb23 ?        216-01:38:15 /sbin/init

NTP looks sane:

Feb 23 18:13:58 hostA ntpd[7539]: ntpd 4.2.4p8@1.1612-o Tue Jul  6 21:50:26 UTC 2010 (1)
Feb 23 18:13:58 hostA ntpd[7540]: precision = 0.126 usec
Feb 23 18:13:58 hostA ntpd[7540]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Feb 23 18:13:58 hostA ntpd[7540]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Feb 23 18:13:58 hostA ntpd[7540]: Listening on interface #1 lo, 127.0.0.1#123 Enabled
Feb 23 18:13:58 hostA ntpd[7540]: Listening on interface #2 em1, 192.168.1.9#123 Enabled
Feb 23 18:13:58 hostA ntpd[7540]: Listening on interface #3 em2, <ip.addr.scrubbed>#123 Enabled
Feb 23 18:13:58 hostA ntpd[7540]: Listening on routing socket on fd #20 for interface updates
Feb 23 18:13:58 hostA ntpd[7540]: kernel time sync status 2040
Feb 23 18:13:58 hostA ntpd[7540]: getaddrinfo: "::1" invalid host address, ignored
Feb 23 18:13:58 hostA ntpd[7540]: frequency initialized 27.053 PPM from /var/lib/ntp/drift
Feb 23 18:17:08 hostA ntpd[7540]: synchronized to LOCAL(0), stratum 10
Feb 23 18:17:08 hostA ntpd[7540]: kernel time sync status change 2001
Feb 23 18:17:18 hostA ntpd[7540]: synchronized to <ip.addr.scrubbed>, stratum 1
Feb 23 18:22:43 hostA ntpd[7540]: synchronized to <ip.addr.scrubbed>, stratum 1
Feb 23 18:25:57 hostA ntpd[7540]: synchronized to <ip.addr.scrubbed> stratum 1
Feb 23 18:32:21 hostA ntpd[7540]: time reset -0.192626 s

PID files in proc look to have sane timestamps ( all from today or yesterday ).

Where does ps/htop get their time field from ?

Anyone run into this before?

Andrew Schulman
  • 8,811
  • 21
  • 32
  • 47
J.D. Smith
  • 21
  • 1
  • Can you post the results of `/proc/1/stat`? – Matthew Ife Feb 24 '14 at 18:11
  • cat /proc/1/stat 1 (init) S 0 1 1 0 -1 4202752 2986 1045439571 19 31771 282462664 5121043945 448850057261 1075984391569 20 0 1 0 22 19873792 275 18446744073709551615 140030057205760 140030057345908 140735448905200 140735448904280 140030038908131 0 0 4096 536962595 18446744071580414009 0 0 0 2 0 0 20 0 0 – J.D. Smith Feb 25 '14 at 21:50
  • Very large stime in there. – J.D. Smith Feb 26 '14 at 01:53

2 Answers2

1

It doesn't have same issue,but in my case if size of /proc/stat increased from 64KB it start showing weird STIME output.The reason for that it's harcoded inside the code

procps-3.2.8/ps/global.c 
359 void reset_global(void){
360   static proc_t p;
361   reset_selection_list();
362   look_up_our_self(&p);
363   set_screen_size();
364   set_personality();
365   int fd;
366   char *buf[BUFFSIZE];
367   const char *b;
368 
369   /* get boot time from /proc/stat */
370   fd = open("/proc/stat", O_RDONLY, 0);
371   if (fd != -1) {
372     buf[BUFFSIZE-1] = 0;
373     read(fd, buf, BUFFSIZE-1);
374     b = strstr(buf, "btime ");
375     if (b) {
376       sscanf(b, "btime %lu", &time_of_boot);

RedHat already have internal bug related to this issue https://bugzilla.redhat.com/show_bug.cgi?id=867906

Prashant Lakhera
  • 713
  • 2
  • 10
  • 25
  • Unfortunately I don't have a valid account on their bugzilla. btime in /proc/stat does concur with my reboot time though. 1393204316 – J.D. Smith Feb 26 '14 at 01:10
0

Check your server's BIOS and hardware clock.

If this is a physical server, make sure that the time is set properly in the BIOS or that you sync your NTP-acquired time to the hardware clock.

Is this is a virtual machine, check the time status of the host/hypervisor.

ewwhite
  • 197,159
  • 92
  • 443
  • 809