Linux: ps / htop mostra processos em execução por centenas ou milhares de dias, embora o host tenha sido reinicializado

2

RHEL 6.3

Nós apenas reinicializamos ontem à noite e eu tenho muitos processos mostrando que eles estão rodando FOREVER. Exemplos:

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

O NTP parece sensato:

Feb 23 18:13:58 hostA ntpd[7539]: ntpd [email protected] 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

Os arquivos PID no proc parecem ter timestamps sãos (todos de hoje ou ontem).

De onde o ps / htop obtém seu campo de tempo?

Alguém se deparou com isso antes?

    
por J.D. Smith 24.02.2014 / 18:10

2 respostas

1

Ele não tem o mesmo problema, mas no meu caso, se o tamanho de / proc / stat aumentou de 64KB, ele começa a mostrar a estranha saída STIME. A razão para isso é codificada dentro do código

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);

O RedHat já tem um bug interno relacionado a este problema link

    
por 25.02.2014 / 15:40
0

Verifique o relógio do BIOS e do hardware do seu servidor.

Se este for um servidor físico, verifique se o horário está definido corretamente no BIOS ou se você sincronizou o tempo adquirido pelo NTP com o relógio do hardware.

Esta é uma máquina virtual, verifique o status de hora do host / hipervisor.

    
por 24.02.2014 / 18:16

Tags