asg
push it, don´t hype
Hallo.
Der eine oder ander hat sicher schon FreeBSD 5 auf seiner Box am rennen, und freut sich des Lebens.
Na dann ruft mal "ps aux" auf....
#ps aux
%ps aux
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 11 1.5 0.0 0 12 ?? RL 1Jan70 12:06.94 (idle)
root 10 0.0 0.0 0 12 ?? DL 1Jan70 0:00.00 (ktrace)
root 1 0.0 0.1 712 228 ?? ILs 1Jan70 0:00.02 /sbin/init --
root 12 0.0 0.0 0 12 ?? WL 1Jan70 0:04.15 (swi6: tty:sio clock)
root 14 0.0 0.0 0 12 ?? WL 1Jan70 0:00.21 (swi1: net)
root 2 0.0 0.0 0 12 ?? DL 1Jan70 0:00.17 (g_event)
root 3 0.0 0.0 0 12 ?? DL 1Jan70 0:02.49 (g_up)
root 4 0.0 0.0 0 12 ?? DL 1Jan70 0:03.65 (g_down)
root 15 0.0 0.0 0 12 ?? DL 1Jan70 0:00.50 (random)
root 17 0.0 0.0 0 12 ?? WL 1Jan70 0:00.00 (swi3: cambio)
root 19 0.0 0.0 0 12 ?? WL 1Jan70 0:00.00 (swi5: acpitaskq)
root 5 0.0 0.0 0 12 ?? IL 1Jan70 0:00.00 (acpi_task0)
root 6 0.0 0.0 0 12 ?? IL 1Jan70 0:00.00 (acpi_task1)
root 7 0.0 0.0 0 12 ?? IL 1Jan70 0:00.00 (acpi_task2)
root 22 0.1 0.0 0 12 ?? WL 1Jan70 0:05.91 (irq14: ata0)
root 23 0.0 0.0 0 12 ?? WL 1Jan70 0:00.00 (irq15: ata1)
root 24 0.0 0.0 0 12 ?? DL 1Jan70 0:00.00 (usb0)
root 25 0.0 0.0 0 12 ?? DL 1Jan70 0:00.00 (usbtask)
root 26 0.0 0.0 0 12 ?? DL 1Jan70 0:00.00 (usb1)
root 27 0.0 0.0 0 12 ?? WL 1Jan70 0:00.23 (irq11: xl0)
[...]
Ooops. Das sieht aber nicht nach dem Jahr 2003 aus, ganz und gar nicht.
Um es vorweg zu nehmen, dieser "bug" ist nicht weiter problematisch, die Prozesse mit dem Datum 1970 gehören alle zum kernel oder sind low-level Systemprozesse.
Wie kommt es nun aber zu diesem Fehler in der Datumsanzeige?
Die Prozesse mit dem falschen Datum werden alle gestartet bevor der Kernel die Zeit, und somit auch das Datum initialsieren konnte. Dies liegt daran, dass FreeBSD zu allererst auf die Platte zugreift bevor es Daten von der Uhr im Rechner bekommt, und so nicht sagen kann ob es sich um UTC oder die lokale Zeit handelt.
Soweit so gut. Wie ist es nun aber möglich doch die richtige Zeit auch für diese Prozesse nagzeigt zu bekommen.
Dag-Erling Smorgrav hat in der freebsd-current Liste einen hack dazu veröffnetlicht, ob dieser funktioniert oder nicht, ich weiss es noch nicht, daher, Benutzung auf eigene Gefahr. Aber ich denke das es in absehbarer Zeit einen offiziellen Fix geben wird.
Hier der hack:
Index: kern_proc.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.179
diff -u -r1.179 kern_proc.c
--- kern_proc.c 18 Apr 2003 20:17:05 -0000 1.179
+++ kern_proc.c 24 Apr 2003 01:01:37 -0000
@@ -673,6 +673,8 @@
}
if ((p->p_sflag & PS_INMEM) && p->p_stats) {
kp->ki_start = p->p_stats->p_start;
+ if (kp->ki_start == 0)
+ kp->ki_start = boottime;
kp->ki_rusage = p->p_stats->p_ru;
kp->ki_childtime.tv_sec = p->p_stats->p_cru.ru_utime.tv_sec +
p->p_stats->p_cru.ru_stime.tv_sec;
Viel Spass beim kompilieren und testen.
Falls sich jemand berufen fühlt diesen hack einmal auszuprobieren, und damit auf die Schnauze fällt, oder wenn er funktioniert, so wäre es interessant dieses hier zu lesen.
Der eine oder ander hat sicher schon FreeBSD 5 auf seiner Box am rennen, und freut sich des Lebens.
Na dann ruft mal "ps aux" auf....
#ps aux
%ps aux
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 11 1.5 0.0 0 12 ?? RL 1Jan70 12:06.94 (idle)
root 10 0.0 0.0 0 12 ?? DL 1Jan70 0:00.00 (ktrace)
root 1 0.0 0.1 712 228 ?? ILs 1Jan70 0:00.02 /sbin/init --
root 12 0.0 0.0 0 12 ?? WL 1Jan70 0:04.15 (swi6: tty:sio clock)
root 14 0.0 0.0 0 12 ?? WL 1Jan70 0:00.21 (swi1: net)
root 2 0.0 0.0 0 12 ?? DL 1Jan70 0:00.17 (g_event)
root 3 0.0 0.0 0 12 ?? DL 1Jan70 0:02.49 (g_up)
root 4 0.0 0.0 0 12 ?? DL 1Jan70 0:03.65 (g_down)
root 15 0.0 0.0 0 12 ?? DL 1Jan70 0:00.50 (random)
root 17 0.0 0.0 0 12 ?? WL 1Jan70 0:00.00 (swi3: cambio)
root 19 0.0 0.0 0 12 ?? WL 1Jan70 0:00.00 (swi5: acpitaskq)
root 5 0.0 0.0 0 12 ?? IL 1Jan70 0:00.00 (acpi_task0)
root 6 0.0 0.0 0 12 ?? IL 1Jan70 0:00.00 (acpi_task1)
root 7 0.0 0.0 0 12 ?? IL 1Jan70 0:00.00 (acpi_task2)
root 22 0.1 0.0 0 12 ?? WL 1Jan70 0:05.91 (irq14: ata0)
root 23 0.0 0.0 0 12 ?? WL 1Jan70 0:00.00 (irq15: ata1)
root 24 0.0 0.0 0 12 ?? DL 1Jan70 0:00.00 (usb0)
root 25 0.0 0.0 0 12 ?? DL 1Jan70 0:00.00 (usbtask)
root 26 0.0 0.0 0 12 ?? DL 1Jan70 0:00.00 (usb1)
root 27 0.0 0.0 0 12 ?? WL 1Jan70 0:00.23 (irq11: xl0)
[...]
Ooops. Das sieht aber nicht nach dem Jahr 2003 aus, ganz und gar nicht.
Um es vorweg zu nehmen, dieser "bug" ist nicht weiter problematisch, die Prozesse mit dem Datum 1970 gehören alle zum kernel oder sind low-level Systemprozesse.
Wie kommt es nun aber zu diesem Fehler in der Datumsanzeige?
Die Prozesse mit dem falschen Datum werden alle gestartet bevor der Kernel die Zeit, und somit auch das Datum initialsieren konnte. Dies liegt daran, dass FreeBSD zu allererst auf die Platte zugreift bevor es Daten von der Uhr im Rechner bekommt, und so nicht sagen kann ob es sich um UTC oder die lokale Zeit handelt.
Soweit so gut. Wie ist es nun aber möglich doch die richtige Zeit auch für diese Prozesse nagzeigt zu bekommen.
Dag-Erling Smorgrav hat in der freebsd-current Liste einen hack dazu veröffnetlicht, ob dieser funktioniert oder nicht, ich weiss es noch nicht, daher, Benutzung auf eigene Gefahr. Aber ich denke das es in absehbarer Zeit einen offiziellen Fix geben wird.
Hier der hack:
Index: kern_proc.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_proc.c,v
retrieving revision 1.179
diff -u -r1.179 kern_proc.c
--- kern_proc.c 18 Apr 2003 20:17:05 -0000 1.179
+++ kern_proc.c 24 Apr 2003 01:01:37 -0000
@@ -673,6 +673,8 @@
}
if ((p->p_sflag & PS_INMEM) && p->p_stats) {
kp->ki_start = p->p_stats->p_start;
+ if (kp->ki_start == 0)
+ kp->ki_start = boottime;
kp->ki_rusage = p->p_stats->p_ru;
kp->ki_childtime.tv_sec = p->p_stats->p_cru.ru_utime.tv_sec +
p->p_stats->p_cru.ru_stime.tv_sec;
Viel Spass beim kompilieren und testen.
Falls sich jemand berufen fühlt diesen hack einmal auszuprobieren, und damit auf die Schnauze fällt, oder wenn er funktioniert, so wäre es interessant dieses hier zu lesen.