Eu tentei consertar a data na máquina que tem o Solaris 8 como sistema operacional.
Com o comando date , recebo a data reparada, mas apenas por 2 segundos e restaurei no tempo que configurei no começo:
Exemplo : Eu configuro o date para data MMddhhmmyyyy a hora é 09:46
então eu recebo a data certa agora, mas ele faz um loop por 2 segundos, então vai para 09:46:02 e redefinir para 09:46:00, isso é tudo.
Acho que esse problema é influenciado pelo comportamento da minha máquina porque é muito lento quando quero reiniciar ou iniciar um aplicativo.
Quando eu inicio o prstat, também tenho isto:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
676 root 4336K 1864K sleep 59 0 0:00.00 0.0% sendmail/1
673 root 7912K 5040K sleep 59 0 0:00.00 0.0% dtgreet/4
654 root 6704K 2856K sleep 10 0 0:00.00 0.0% dtlogin/4
652 root 203M 35M sleep 59 0 0:00.00 0.0% Xsun/1
759 root 1688K 1368K cpu0 58 0 0:00.00 0.0% prstat/1
411 root 5200K 2040K sleep 54 0 0:00.00 0.0% dtlogin/4
743 root 336K 240K sleep 48 0 0:00.00 0.0% sh/1
553 root 1856K 1136K sleep 54 0 0:00.00 0.0% ttymon/1
562 root 1840K 1256K sleep 30 0 0:00.00 0.0% in.rlogind/1
391 root 1944K 1296K sleep 51 0 0:00.00 0.0% nfsd/1
388 root 2816K 2000K sleep 52 0 0:00.00 0.0% mountd/5
524 root 3120K 1872K sleep 51 0 0:00.00 0.0% dmispd/5
314 root 1752K 696K sleep 40 0 0:00.00 0.0% smcboot/1
599 sideral 2576K 1840K sleep 48 0 0:00.00 0.0% bash/1
312 root 1752K 1160K sleep 30 0 0:00.00 0.0% smcboot/1
305 root 1080K 720K sleep 59 0 0:00.00 0.0% utmpd/1
333 root 1056K 272K sleep 0 0 0:00.00 0.0% efdaemon/1
261 root 2024K 1224K sleep 58 0 0:00.00 0.0% cron/1
259 root 4344K 2120K sleep 58 0 0:00.00 0.0% syslogd/8
276 root 2792K 1960K sleep 0 0 0:00.00 0.0% nscd/9
322 root 2744K 2032K sleep 48 0 0:00.00 0.0% vold/6
282 root 3184K 1016K sleep 50 0 0:00.00 0.0% lpsched/1
243 root 1952K 1280K sleep 0 0 0:00.00 0.0% lockd/1
238 root 2504K 1824K sleep 58 0 0:00.00 0.0% inetd/1
245 daemon 2552K 1784K sleep 0 0 0:00.00 0.0% statd/3
295 root 1480K 1064K sleep 30 0 0:00.00 0.0% powerd/5
203 root 2264K 1120K sleep 58 0 0:00.00 0.0% rpcbind/1
68 root 3496K 2648K sleep 52 0 0:00.00 0.0% picld/8
58 root 2288K 1448K sleep 58 0 0:00.00 0.0% syseventd/12
564 sideral 1520K 1120K sleep 58 0 0:00.00 0.0% csh/1
246 root 3816K 1992K sleep 58 0 0:00.00 0.0% automountd/5
561 root 3816K 2808K sleep 0 0 0:00.00 0.0% devfsadm/7
555 root 1856K 1168K sleep 58 0 0:00.00 0.0% ttymon/1
552 root 1864K 1112K sleep 58 0 0:00.00 0.0% sac/1
1 root 864K 312K sleep 58 0 0:00.00 0.0% init/1
Isso é normal? Alguém tem alguma ideia sobre isso?
EDIT : mesmo quando eu mudei a placa-mãe, eu tenho o mesmo problema: Algum outro material de hardware é responsável por esse erro ?? porque como eu sei só a placa mãe é responsável pela configuração da data!
Se isso estiver no SPARC, suspeito que você tenha uma falha de hardware.
Eu já vi antes onde você poderia definir o relógio com date e ele funcionaria por um segundo. Então, no próximo relógio, a data ficaria incerta (no meu caso, por vários anos). Parecia que um único bit falhou e não pôde ser modificado. Isso se encaixaria se meus fracassos estivessem em um nível alto e o seu fosse um pouco baixo.
Em ambos os casos que vi, a substituição da placa-mãe resolveu o problema.
O NTP está em execução? Isso mudaria a hora e, talvez, a sincronização para algo em que o tempo está desativado. O que ntpq -p mostra?
Por que a placa-mãe foi substituída? Um de seus comentários sugere porque a caixa estava lenta, mas nenhuma indicação do que "lento" significa. Os SunBlade 150 não eram terrivelmente robustos e usavam algum hardware comum, então talvez você esteja tentando correr muito na área de trabalho?
A parte mais útil do seu prstat está faltando, que é a última linha que mostra o número de processos, # de lwps e médias de carga. O que é mostrado não indica como um problema de utilização. Talvez um problema de hardware diferente (isto é: falha de disco) ou falta de memória? Portanto, verifique /var/adm/messages e sua taxa de rastreamento em vmstat .