find: WARNING: Hard link count is wrong for /proc/1

[d4z_c0nf]

Ragazzi da circa 3 giorni (forse più forse meno), se faccio un ricerca con find del tipo;

find /proc -name "blablabla"

find fa il suo lavoro ma mi restituisce anche questo messaggio:

Codice: Seleziona tutto

find: WARNING: Hard link count is wrong for /proc/1: this may be a bug in your filesystem driver.  Automatically turning on find's -noleaf option.  Earlier results may have failed to include directories that should have been searched.

Ora, ho letto il man e l'opzione citata è necessaria se sono montati dei filesystem che non seguono la "convenzione" Unix, ossia quella che in ogni dir ci siano almeno due "subdir" cioè "." e "..", serve per non far assumere a find che quelle subdir ci siano, ora è vero che io ho fs non unix-like montati, ma il problema è che l'errore mi venga dato su /proc/1 (in sostanza SOLO su tutte le SUBDIR di proc,), a questo punto penso davvero che ci sia qualche problema "serio".

Avete idea di cosa possa essere?

PS.
ovviamente con l'opzione -noleaf non da più quell'errore.
Prima che me lo chiediate, le subdir di proc sono ovviamente popolate e contengono "." ".." (ho controllato )

[d4z_c0nf]

Ulteriori info
kernel=2.6.25.1 (da me compilato)

Ho provato a bootare il kernel huge della 12.1 e il problema non si verifica.. ergo o è un problema dell'ultimo kernel oppure dipende da qualche opzione con ho configurato.

Idee?

rock

[conraid]

Non so quanto sia "colpa" del kernel. /proc è un filesystem virtuale, magari cambia mentre fai find.
Io non userei find per cercare in /proc, anche perché a volte non c'è niente dentro i file, e solo quando fai cat il kernel restituisce un valore.
Il tutto IMVHO

[d4z_c0nf]

Non so quanto sia "colpa" del kernel. /proc è un filesystem virtuale, magari cambia mentre fai find.
Io non userei find per cercare in /proc, anche perché a volte non c'è niente dentro i file, e solo quando fai cat il kernel restituisce un valore.
Il tutto IMVHO

Conraid ora sto su un'altra postazione dove ho kernel huge della distro
ti faccio vedere il risultato:

Codice: Seleziona tutto

root@localhost:/home/d4z_c0nf#find /proc/1 -name "exe"
/proc/1/task/1/exe
/proc/1/exe

Ora la stessa cosa l'ho provata sul pc che ho a casa (quello che mi da l'errore con il kernel compilato da me), utilizzando il kernel huge della distro e non mi da problemi..

rock

[Mario Vanoni]

Ha ragione conraid, /proc e` un file system sempre in evoluzione.

Su una macchina stracarica di processi,
due processori con 0.0%id nel top:

cd /proc
ls -alR | less
ls -alR 2> /dev/null | less
ls -alR | wc -l
12542
ls -alR 2> /dev/null | wc -l
12542
ls -alR 2>&1 | wc -l
12666

Mario Vanoni

[d4z_c0nf]

Ha ragione conraid, /proc e` un file system sempre in evoluzione.

Su una macchina stracarica di processi,
due processori con 0.0%id nel top:

cd /proc
ls -alR | less
ls -alR 2> /dev/null | less
ls -alR | wc -l
12542
ls -alR 2> /dev/null | wc -l
12542
ls -alR 2>&1 | wc -l
12666

Mario Vanoni

Non lo metto in dubbio ma perchè con il kernel huge non succede?

rock

[Mario Vanoni]

Non lo metto in dubbio ma perchè con il kernel huge non succede?

Non lo so, ma permetti il dubbio?
Esiste da quando hanno introdotto /proc nel kernel, sempre visto.

Prova sul kernel huge
cd /proc
ls -alR 2>&1 | grep 'No such'
magari piu` volte di seguito.

Mario Vanoni

[Mario Vanoni]

Rileggendo il titolo ed il primo post:

- sto giocando con penne/stick USB da 8GB con ext2
- mi fanno storie, anche se non no-name e ... carucce
- errori simili ai tuoi, simili, non uguali al 100%
- forse ho una traccia, sono al quinto esperimento/giro
- l'ultimo, dopo un e2fsck -f /device sembra andare
- facendolo con molta calma, risultato forse domani

Mario Vanoni

[d4z_c0nf]

Rileggendo il titolo ed il primo post:

- sto giocando con penne/stick USB da 8GB con ext2
- mi fanno storie, anche se non no-name e ... carucce
- errori simili ai tuoi, simili, non uguali al 100%
- forse ho una traccia, sono al quinto esperimento/giro
- l'ultimo, dopo un e2fsck -f /device sembra andare
- facendolo con molta calma, risultato forse domani

Mario Vanoni

Ok.
comunque ho provato sia con l'huge che con l'attuale e gli ultimi comandi che mi hai dato da digitare (li ho provati in un for per 10 volte di seguito) non hanno restituito nulla

rock

[Mario Vanoni]

Rileggendo il titolo ed il primo post:

- sto giocando con penne/stick USB da 8GB con ext2
- mi fanno storie, anche se non no-name e ... carucce
- errori simili ai tuoi, simili, non uguali al 100%
- forse ho una traccia, sono al quinto esperimento/giro
- l'ultimo, dopo un e2fsck -f /device sembra andare
- facendolo con molta calma, risultato forse domani

Mario Vanoni

Ok.
comunque ho provato sia con l'huge che con l'attuale e gli ultimi comandi che mi hai dato da digitare (li ho provati in un for per 10 volte di seguito) non hanno restituito nulla

rock

Quindi se ls(1) non segnala niente verso stderr,
neanche find(1) dovrebbe farlo, logica UNIX.

Mario Vanoni

[d4z_c0nf]

Rileggendo il titolo ed il primo post:

- sto giocando con penne/stick USB da 8GB con ext2
- mi fanno storie, anche se non no-name e ... carucce
- errori simili ai tuoi, simili, non uguali al 100%
- forse ho una traccia, sono al quinto esperimento/giro
- l'ultimo, dopo un e2fsck -f /device sembra andare
- facendolo con molta calma, risultato forse domani

Mario Vanoni

Ok.
comunque ho provato sia con l'huge che con l'attuale e gli ultimi comandi che mi hai dato da digitare (li ho provati in un for per 10 volte di seguito) non hanno restituito nulla

rock

Quindi se ls(1) non segnala niente verso stderr,
neanche find(1) dovrebbe farlo, logica UNIX.

Mario Vanoni

Sì capisco che intendi ma infatti i file speciali "." e ".." ci sono (come ho scritto nel primo post..vedi PS)

[Mario Vanoni]

Sì capisco che intendi ma infatti i file speciali "." e ".." ci sono (come ho scritto nel primo post..vedi PS)

man 5 proc | less

cerca
/pwd

leggi le 3 righe seguenti

e divertiti a capirle, hint pthread_exit(3).
I kernel attuali sono multithread!
Un processo muore, un altro nasce.

Mario Vanoni

[d4z_c0nf]

Sì capisco che intendi ma infatti i file speciali "." e ".." ci sono (come ho scritto nel primo post..vedi PS)

man 5 proc | less

cerca
/pwd

leggi le 3 righe seguenti

e divertiti a capirle, hint pthread_exit(3).
I kernel attuali sono multithread!
Un processo muore, un altro nasce.

Mario Vanoni

Bene, ho letto ho capito il fatto del multithread e delle dir proc/[0-9]+ , e quindi mi rendo conto che è lecito che mi dia il problema proprio su quelle dir "dinamiche", il problema però rimane, nel senso che comunque come un kernel huge ( non vecchissimo, ma quello della 12.1, che fino a prova contraria è multithreading) il problema non sussiste, ergo nonostante la "specialità" del filesystem virtuale proc, ci dev'essere necessariamente qualche opzione da configurare nel kernel per far sì che quel messaggio non venga mostrato, mi rendo comunque conto che non si tratti di un grande problema, anche perchè è inutile fare un find per cercare cose in quelle dir quando le posso navigare e visualizzarne il contenuto con cat e more.
rock

[Mario Vanoni]

Sì capisco che intendi ma infatti i file speciali "." e ".." ci sono (come ho scritto nel primo post..vedi PS)

man 5 proc | less

cerca
/pwd

leggi le 3 righe seguenti

e divertiti a capirle, hint pthread_exit(3).
I kernel attuali sono multithread!
Un processo muore, un altro nasce.

Mario Vanoni

Bene, ho letto ho capito il fatto del multithread e delle dir proc/[0-9]+ , e quindi mi rendo conto che è lecito che mi dia il problema proprio su quelle dir "dinamiche", il problema però rimane, nel senso che comunque come un kernel huge ( non vecchissimo, ma quello della 12.1, che fino a prova contraria è multithreading) il problema non sussiste, ergo nonostante la "specialità" del filesystem virtuale proc, ci dev'essere necessariamente qualche opzione da configurare nel kernel per far sì che quel messaggio non venga mostrato, mi rendo comunque conto che non si tratti di un grande problema, anche perchè è inutile fare un find per cercare cose in quelle dir quando le posso navigare e visualizzarne il contenuto con cat e more.
rock

Domanda/curiosita`:

la macchina che segnala su stderr e` carica al massimo o idle?
Piu` processi attivi allo stesso tempo, piu` files temporari su /proc.
Find(1) li vede al primo impatto, quando li vuole leggere sono scomparsi.
I due kernel hanno lo stesso valore, 100Hz, 250, 300 o 1000Hz in
make menuconfig -> Processor type and features -> Timer frequency?

Mario Vanoni

[d4z_c0nf]

Domanda/curiosita`:

la macchina che segnala su stderr e` carica al massimo o idle?
Piu` processi attivi allo stesso tempo, piu` files temporari su /proc.
Find(1) li vede al primo impatto, quando li vuole leggere sono scomparsi.
I due kernel hanno lo stesso valore, 100Hz, 250, 300 o 1000Hz in
make menuconfig -> Processor type and features -> Timer frequency?

Mario Vanoni

Ho provato la cosa anche sulla stessa macchina e nelle stesse condizioni (appena fatto il login in init3),
Il timer frequency è lo stesso per i due config, l'huge però ha settato come Processor Family -> Pentium Pro
io avendo un Pentium 4 nel mio config ho selezionato la voce adatta.