updatedb liefert Fehler

[FuxDerFinguin]

Hallo!
Ich lasse täglich per Cron-job updatedb laufen, um immer eine aktuelle DB für locate zu haben.
Leider funktioniert das ganz nicht, da updatedb immer den folgenden Fehler zurückliefert:

Code: Alles auswählen

/usr/bin/find: /proc/10154/fd/4: Datei oder Verzeichnis nicht gefunden
/usr/bin/find: /proc/10154/fd/4: Datei oder Verzeichnis nicht gefunden
/usr/bin/find: /proc/10154/fd/4: Datei oder Verzeichnis nicht gefunden
/usr/bin/find: /proc/10154/fd/4: Datei oder Verzeichnis nicht gefunden
updatedb: new database would be empty

Die o.g. Verzeichnisse existieren überhaupt nicht, wie kommt updatedb auf die wahnwitzige Idee, danach zu suchen?

Auch in der /etc/updatedb.conf stehen diese Pfade nicht...

hat jemand eine Idee

CU
Fux

[Savar]

PRUNEFS="NFS nfs nfs4 afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf"

wie sieht denn die obige Zeile bei dir in der /etc/updatedb.conf aus?
Was gibt dir

Code: Alles auswählen

mount

?

Und das du das Verzeichnis nicht findest ist klar die /proc/NUMMER ist die ProzessID.. das heißt wenn der Prozess zu Ende ist, dann ist auch das Verzeichnis weg..

Aber laut der PRUNEFS sollte updatedb gar nicht unter /proc suchen..

[FuxDerFinguin]

Hi!
Also die updatedb.conf sieht so aus:

Code: Alles auswählen

# This file sets environment variables which are used by updatedb

# Global options for invocations of find(1)
FINDOPTIONS='-ignore_readdir_race'
export FINDOPTIONS
# filesystems which are pruned from updatedb database
PRUNEFS="NFS nfs nfs4 afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf"
export PRUNEFS
# paths which are pruned from updatedb database
PRUNEPATHS="/tmp /usr/tmp /var/tmp /afs /amd /alex /var/spool /sfs /media"
export PRUNEPATHS
# netpaths which are added
NETPATHS=""
export NETPATHS
# run find as this user
LOCALUSER="nobody"
export LOCALUSER
# cron.daily/find: run at this priority -- higher number means lower priority
# (this is relative to the default which cron sets, which is usually +5)
NICE=10
export NICE

Somit sollte er also nicht unter /proc suchen oder?!

CU
Fux

[Savar]

Was gibt dir

Code: Alles auswählen

mount

?

??

Ach und was gibt dir

Code: Alles auswählen

ls -ld /proc

[FuxDerFinguin]

Hi!
Mount:

Code: Alles auswählen

/dev/sda1 on / type reiserfs (rw)
usbfs on 7proc/bus/usb type usbfs (rw,mode=0666)
tmpfs on /dev/shm type tmpfs (rw)
tmpfs on /dev type tmpfs (rw,size=10M,mode=9755)
automount(pid5323) on 7mnt/auto type autofs 8rw,fd=4,pgrp=5323,minproto=2,maxproto=4)

ls -ld /proc:

Code: Alles auswählen

dr-xr-wr-w 169 root root 0 2007-04-10 23:05 /proc

Man bist Du schnell

Fux

P.S.: Lasse updatedb gerade laufen, habe in der updatedb.conf /proc unter PRUNEPATHS eingetragen... bisher keine Fehlermeldung... mal sehen

Nachtrag: Anpassung der updatedb.conf hat nichts gebracht

[Savar]

hmm..

mein mount:

s@hosenscheisser:~$ mount
/dev/sda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sda2 on /home type ext3 (rw,errors=remount-ro)
/dev/sda3 on /mnt/windows type fuseblk (rw,nosuid,nodev,noexec,noatime,allow_other,default_permissions,blksize=4096)
s@hosenscheisser:~$

da dir die PROC Zeile fehlt, erkennt er das nicht.. warum dir die fehlt weiß ich nicht (wie sieht deine /etc/fstab aus?) und hast du mal neugestartet zwischendurch?

[FuxDerFinguin]

Hi!
Neustart ist zwischendurch erfolgt, komischer Weise steht in der /etc/fstab folgendes:

Code: Alles auswählen

proc /proc proc defaults 0 0

Was läuft da nur falsch?

CU
Fux

[Savar]

keine Ahnung (der Eintrag ist ok!) ich weiß es nicht..

[meandtheshell]

Zum eigentlichen Problem:
- imho ist das /proc Problem eines welches nach einem reboot verschwunden ist (proc in der fstab ist sicher falsch - lösche das)
- eine etwas bessere Variante http://www.debian-administration.org/articles/387

Anmerkung:
mount liefert generell einen imho unlesbaren output (keine Ausrichtung nach Spalten) - folgendes ist viel schöner

Code: Alles auswählen

markusgattol@pc1:~/.emacs_misc/elisp_files/muse$ di -h
Filesystem         Mount               Size     Used    Avail %Used fs Type
/dev/md0           /                  22.9G     9.5G    12.2G  47%  ext3   
/dev/hda1          /boot             448.4M    22.0M   402.5M  10%  ext3   
udev               /dev               10.0M   100.0k     9.9M   1%  tmpfs  
tmpfs              /dev/shm          506.0M       0    506.0M   0%  tmpfs  
/dev/hdb2          /home/markusgat    32.1G    12.2G    18.3G  43%  ext3   
tmpfs              /lib/init/rw      506.0M       0    506.0M   0%  tmpfs  
/dev/mapper/kim    /media/usb0       233.6G    95.0G   138.7G  41%  xfs    
/dev/mapper/alan   /media/usb1       372.5G   323.5G    49.0G  87%  xfs    
/dev/hda5          /tmp                9.2G    32.2M     8.7G   5%  ext3   
markusgattol@pc1:~/.emacs_misc/elisp_files/muse$ 

Markus

/edit
IM Auszug

Code: Alles auswählen

(20:00:11) own_jabber@debianforum.de: Das verhalten von dem (seinen) System ist so oder so bizarr - darauf in deterministischer Art und Weise zu antworten ist daher erst mal nicht möglich. Nächster Vorschlag von mir wäre einen neuen Kernel zu installieren (so Zeug habe ich mit buggy Kernels schon mehrmals gesehen). Wenn das auch nichts hilft ist das fs oder die Disk schuld.
(20:00:48) the_other_one: jo... schreib ihm das :) (gut er wird dadurch auch verwirrt.. aber wenigstens in die richtige Richtung *lol* )
(20:00:52) own_jabber@debianforum.de: Es war sowieso der Kernel. Es ist immer der Kernel. Es muss einfach der Kernel sein.
(20:01:18) own_jabber@debianforum.de: the fucking kernel did it ;]

[garibaldi]

(proc in der fstab ist sicher falsch - lösche das)

Bist du sicher? Das steht bei mir genauso drin; und der Eintrag stammt garantiert nicht von mir, sondern vom Debian-Installer.

Gruß, garibaldi

[Spasswolf]

proc in der fstab scheint zumindest unnötig zu sein, denn das proc Filesytem wird vom initscript /etc/init.d/mountkernfs.sh. gemountet. Falls man proc aber mit zusätzlichen Optionen mounten möchte, kann man die in die fstab eintragen, da das Skript die fstab auswertet.
Aber für ein mounten von proc mit den Standardoptionen (nodev, noexec, nosuid) muss die fstab noch nicht mal existieren.

[garibaldi]

Aha, danke für die Erläuterung. Insofern ist der Eintrag dann allerdings nicht falsch, sondern überflüssig, wenn ich's recht verstehe. Dann kann der Eintrag nicht Ursache für das Ausgangsproblem sein.

[meandtheshell]

Das Bedarf einer Richtigstellung.
Der Eintrag von proc in /etc/fstab ist _nicht_ falsch aber in debian (nur debian) theoretisch überflüssig. Das wurde alles schon gesagt.

Die Reihenfolge in welcher /etc/rcS.d/S02mountkernfs.sh bzw. /etc/fstab ihre Wirkung zeigen ist evtl. interessant

/etc/rcS.d/S02mountkernfs.sh also vor /etc/fstab darum wäre es theoretisch mögich sich den proc entry in /etc/fstab zu sparen. Ein System könnte sogar ganz ohne /proc leben - der Nachteil wäre das viele Tools die Information aus aus /proc lesen nicht mehr funktionieren würden.

Hier noch ein kleiner Chat von #debian-boot der evtl. interessant ist

Code: Alles auswählen

(23:04:43) meandtheshell: hi folks - who actually writes the /proc line entry to /etc/fstab - must be the installer - yes?
(23:05:29) vorlon: meandtheshell: yes
(23:06:27) meandtheshell: well, since I figured that /etc/rcS.d/S02mountkernfs.sh actually mounts proc to /proc, why does the installer still write the proc entry to /etc/fstab?
(23:06:38) meandtheshell: to override some settings from /etc/rcS.d/S02mountkernfs.sh ?
(23:07:21) vorlon: to not rely on init scripts mounting things that aren't part of the fstab, I think
(23:07:59) meandtheshell: can you elaborate that please? 
(23:08:22) meandtheshell: who should rely on what at what stage in the boot process?
(23:08:46) vorlon: not sure what needs elaborating?  The fact that S02mountkernfs.sh mounts it is not part of any documented API.
(23:09:41) meandtheshell: I see - so the /etc/rcS.d/S02mountkernfs.sh case is unique to debian?
(23:09:59) vorlon: yes, definitely
(23:10:17) meandtheshell: ah - ok - that clarifies a lot here
(23:11:30) meandtheshell: but the installer is (so to say) unique to debian too - why is there a need to ensure that proc gets mounted twice
(23:11:30) meandtheshell: - once with /etc/rcS.d/S02mountkernfs.sh and the other time with
(23:11:30) meandtheshell: - /etc/fstab
(23:12:32) meandtheshell: wouldn't /etc/rcS.d/S02mountkernfs.sh be enough?
(23:16:10) vorlon: yes, but that doesn't mean it's a documented API that the installer should depend on
(23:16:43) meandtheshell: vorlon: or let me put it that way - is there a documented API telling about the need for /etc/fstab to hold the /proc entry - I assume so ... - yes?
(23:18:55) vorlon: meandtheshell: well, there's fstab(5)
(23:20:09) meandtheshell: ok - yes - right
(23:25:56) meandtheshell: vorlon: well, where does fstab(5) explicitly say /etc/fstab must have a line dedicated to proc?
(23:28:33) meandtheshell: well, one might figure it from the whole context yes ...
23:30
(23:33:24) vorlon: it doesn't say that, but it doesn't say anything to the contrary, and neither does anything else unless you peek inside the script you mentioned
(23:36:10) meandtheshell: right - well, thx then and have fun 8-]

FAZIT
Bezüglich des Ursprungs Problems denke ich noch immer, das der Kernel was damit zu tun hat. Welchen hast du (OP)?

Markus

[FuxDerFinguin]

Bezüglich des Ursprungs Problems denke ich noch immer, das der Kernel was damit zu tun hat. Welchen hast du (OP)?

Das System basiert augf Knoppix 5.2 mit 'nem 2.6er Kernel.

CU
Fux