Skip to contentSkip to conversation

2.4.0-x features ?

DISCUSSION Pierre Rousselet 3 participants 5 messages Jan 15, 2001 – Jan 16, 2001

lore
Share & tools
lore

Pierre Rousselet

author
#0 lore raw

Pentium-III 256Mb BE6.
1) top (procps-2.0.7) gives me the messages :
'bad data in /proc/uptime'
'bad data in /proc/loadavg'
cat /proc/uptime
1435.30 904.74
cat /proc/loadavg
0.01 0.21 0.29 1/17 19444
What is wrong ?
2) pppd (2.4.0b4) gives me the message :
'tdb_store failed : Success'
'tdb_store key failed : Success'
What does that mean ?

Signature · 7 lines
------------------------------------------------
 Pierre Rousselet <[email protected]>
------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
#1 lore raw
Quoted 8 lines · Pierre Rousselet

1) top (procps-2.0.7) gives me the messages :
'bad data in /proc/uptime'
'bad data in /proc/loadavg'
cat /proc/uptime
1435.30 904.74
cat /proc/loadavg
0.01 0.21 0.29 1/17 19444
What is wrong ?

Which 2.4.0-x kernel, and how was procps compiled? (the broken gcc again perhaps?)

You might as well get procps-010114.tar.gz (new just yesterday!) and compile it yourself. The top command seems to tolerate Red Hat's fixed gcc, which you should get if you are using Red Hat 7.

http://www.cs.uml.edu/~acahalan/procps/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

#2 lore raw
Quoted 8 lines · Albert D. Cahalan
Quoted 8 lines

1) top (procps-2.0.7) gives me the messages :
'bad data in /proc/uptime'
'bad data in /proc/loadavg'
cat /proc/uptime
1435.30 904.74
cat /proc/loadavg
0.01 0.21 0.29 1/17 19444
What is wrong ?

You probably have locale settings where the decimal point is a comma so scanf on /proc/loadavg etc. doesn't work. The following patch (submitted to RedHat ages ago) fixes that for me.

proc/sysinfo.c +17 -0
diff -u --recursive procps-2.0.7-orig/proc/sysinfo.c procps-2.0.7-hacked/proc/sysinfo.c
@@ -13,6 +13,8 @@
 #include <stdlib.h>
 #include <string.h>
 #include <ctype.h>
+#include <locale.h>
+#include <assert.h>
 
 #include <unistd.h>
 #include <fcntl.h>

@@ -62,12 +64,19 @@
 /***********************************************************************/
 int uptime(double *uptime_secs, double *idle_secs) {
     double up=0, idle=0;
+    char*numeric=setlocale(LC_NUMERIC,0);
+    /* It is necessary to save and restore the numeric locale, because
+    if the locale we're in happens to use , instead of decimal point,
+    we can't sscanf the values in /proc/uptime */
+    setlocale(LC_NUMERIC,"C");
 
     FILE_TO_BUF(UPTIME_FILE,uptime_fd);
     if (sscanf(buf, "%lf %lf", &up, &idle) < 2) {
 	fprintf(stderr, "bad data in " UPTIME_FILE "\n");
 	return 0;
     }
+    setlocale(LC_NUMERIC,numeric);
+
     SET_IF_DESIRED(uptime_secs, up);
     SET_IF_DESIRED(idle_secs, idle);
     return up;	/* assume never be zero seconds in practice */

@@ -171,12 +180,20 @@
 /***********************************************************************/
 int loadavg(double *av1, double *av5, double *av15) {
     double avg_1=0, avg_5=0, avg_15=0;
+    /* It is necessary to save and restore the numeric locale, because
+    if the locale we're in happens to use , instead of decimal point,
+    we can't sscanf the values in /proc/loadavg */
+    char*numeric=setlocale(LC_NUMERIC,0);
+    setlocale(LC_NUMERIC,"C");
     
     FILE_TO_BUF(LOADAVG_FILE,loadavg_fd);
     if (sscanf(buf, "%lf %lf %lf", &avg_1, &avg_5, &avg_15) < 3) {
 	fprintf(stderr, "bad data in " LOADAVG_FILE "\n");
 	exit(1);
+
     }
+    setlocale(LC_NUMERIC,numeric);
+    
     SET_IF_DESIRED(av1,  avg_1);
     SET_IF_DESIRED(av5,  avg_5);
     SET_IF_DESIRED(av15, avg_15);

[...]

Signature · 1 line
	http://www.penguinpowered.com/~vii
author
#3 lore raw
In reply to Albert D. Cahalan
Quoted 12 lines · John Fremlin
Quoted 8 lines · Albert D. Cahalan
Quoted 8 lines

1) top (procps-2.0.7) gives me the messages :
'bad data in /proc/uptime'
'bad data in /proc/loadavg'
cat /proc/uptime
1435.30 904.74
cat /proc/loadavg
0.01 0.21 0.29 1/17 19444
What is wrong ?

Quoted 3 lines

You probably have locale settings where the decimal point is a comma so scanf on /proc/loadavg etc. doesn't work. The following patch (submitted to RedHat ages ago) fixes that for me.

That's it. i persist in setting LANG=fr.

Thank you for the tip.

------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

author
#4 lore raw
In reply to Albert D. Cahalan
Quoted 12 lines · Albert D. Cahalan
Quoted 8 lines · Pierre Rousselet

1) top (procps-2.0.7) gives me the messages :
'bad data in /proc/uptime'
'bad data in /proc/loadavg'
cat /proc/uptime
1435.30 904.74
cat /proc/loadavg
0.01 0.21 0.29 1/17 19444
What is wrong ?

Quoted 6 lines

Which 2.4.0-x kernel, and how was procps compiled? (the broken gcc again perhaps?)

You might as well get procps-010114.tar.gz (new just yesterday!) and compile it yourself. The top command seems to tolerate Red Hat's fixed gcc, which you should get if you are using Red Hat 7.

I did that. Compilation OK with gcc-2.95.2 top still doesn't work ( top > /dev/null tells you 'bad data in ...' just before the screen blanks).
logout after commenting LC_ALL=fr and LANG=fr in /etc/profile login again : top works.

It is a question of '.' and ','

------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/