FreeBSD Basics

Hier ist mein Spickzettel für diverse FreeBSD Befehle / Bedienungshilfen, die sich über die Jahre angesammelt haben. Viele davon muss man nicht auswendig wissen, da man sie einfach zu selten benötigt und hier kann man ja immer wieder nachgucken 😉

Files finden

Nach Filename suchen

Durchsucht wirklich alles ab root Verzeichnis (/)

find / -name "php.core"

Findet einfach alles, was in der locate Datenbank gespeichert ist (siehe updatedb)

locate php.core

Kürzlich geänderte Files finden

Mit diesem Befehl finde ich Files, die innerhalb der letzten 24 Stunden geändert wurden (= -mtime -1,  vor 48 Stunden wäre dann -mtime -2 etc. Das minus (-1) bedeutet VOR. wenn ich -mtime +2 oder -mtime 2 schreiben würde, suche ich nach Files die in der Zukunft geändert wurden 😉 ). Ausserdem werden sie mit -ls so formattiert, dass man auch das Datum sehen kann:

find . -mtime -1 -ls | more

man find Auszug:

-mtime n
       File's  data was last modified n*24 hours ago.  See the comments for -atime to understand how rounding affects the
       interpretation of file modification times.
-ls    True;  list  current  file  in  ls -dils format on standard output.  The block counts are of 1K blocks, unless the
       environment variable POSIXLY_CORRECT is set, in which case 512-byte blocks are used.  See  the  UNUSUAL  FILENAMES
       section for information about how unusual characters in filenames are handled.

updatedb

Wenn man ein File suchen möchte mit locate und dann diese Fehlermeldung bekommt:

locate: database too small: /var/db/locate.database

Ist es an der Zeit die locate Datenbank zu aktualisieren.

Achtung! Dies sollte nicht als root gemacht werden, sondern als User nobody:

su -fm nobody
/usr/libexec/locate.updatedb
exit

Ports

Sehen, welche Ports installiert sind:

pkg_info

Ports inkl. Versionsangabe

pkg_version -v

Ports suchen

Zum Beispiel möchten wir Apache installieren. Suchen wir mal:

cd /usr/ports/
make search name=apache
make search key=apache

Ports deinstallieren

cd /usr/ports/graphics/php4-gd
make deinstall clean

Module aus einem meta-port (z.b. php4-extensions) kann man so nicht deinstallieren. Da solche Ports nur installieren- nicht aber deinstallieren.

 pkg_delete -vdr php4-*

Wahrscheinlich eventuell so wie oben machen – ansonsten so (wenn man z.b. im UPDATEING drin steht, dass man diverse php extensions deinstallieren muss, wenn man php upgraded)

pkg_delete -f php5-pcre-5.2.6
pkgdb -F
portupgrade as usual

falls noch alte configs vorhanden sind, eventuell ebenfalls entfernen

make rmconfig

Ports updaten

Es gibt ja immer wieder mal neue Software Packete / nicht nur neue Versionen bestehender Software. Deshalb muss man den Port Katalog immer wieder mal komplett aktualisieren. Mit Portsnap (weitere Update Möglichkeiten siehe FreeBSD Handbuch)

Erstverwendung von Portsnap:

portsnap fetch
portsnap extract

Wurde portsnap bereits schon einmal ausgeführt, kann die Ports danach regelmässig so updaten

portsnap fetch
portsnap update

Nach dem Update muss man das aktuelle mit den Installierten Versionen vergleichen:

 pkg_version -v

Wenn eine ältere Version gefunden wurde

 pcre-6.3                            <   needs updating (port has 6.4)

gibt es zwei Möglichkeiten, zu Updaten: Entweder upgrade ich alles, was er gefunden hat (-a [all] -i [interactive])

portupgrade -a -i

Oder ich upgrade nur ein bestimmtes Packet

 portupgrade pcre-6.3

Wenn er nach einem OK fragt, einfach Enter drücken

Wenn ich überprüfen möchte, ob jetzt auch wirklich die richtige vers. drauf ist:

pkg_info  | grep ^pcre
pcre-6.4            Perl Compatible Regular Expressions library

Für weitere Infos: Portupgrade Wiki Hidden FreeBSD Handbook/Ports

Versions Updates (Perl etc.)

Wenn z.B. die Perl Version komplett wechselt (von 5.8 auf 5.10 z.B.) muss man auch alle Abhängigen Ports updaten. In der Regel steht die genaue Anleitung dazu im

/usr/ports/UPDATING 

drin. Was aber dabei noch zu berücksichtigen ist, dass wir z.B. Perl mit Thread Support installiert haben. Es wird zwar trotzdem über den Port lang/perl.x.x installiert, der fertig installierte Port heisst allerdings perl-threaded

Wenn also in der Anleitung folgendes drin steht:

20090328:
 AFFECTS: users of lang/perl*
 AUTHOR: skv@FreeBSD.org
 lang/perl5.10 is out. If you want to switch to it from, for example
 lang/perl5.8, that is:
 Portupgrade users:
   0) Fix pkgdb.db (for safety):
       pkgdb -Ff
   1) Reinstall perl with new 5.10:
       portupgrade -o lang/perl5.10 -f perl-5.8.\*
   2) Reinstall everything that depends on Perl:
       portupgrade -fr perl
 Portmaster users:
       portmaster -o lang/perl5.10 lang/perl5.8
       portmaster -r perl\*

mit

pkg_version -v 

jedoch folgendes rauskommt:

perl-threaded-5.8.9

heissen die Befehle wie folgt:

   1) Reinstall perl with new 5.10:
       portupgrade -o lang/perl5.10 -f perl-threaded-5.8.9
   2) Reinstall everything that depends on Perl:
       portupgrade -fr perl-threaded

Man merkt schon, wenn man es richtig oder falsch eingegeben hat. Richtig: Es wird alles nötige installiert bzw. deinstalliert -> es dauert Stunden! Falsch: Nach der Befehlseingabe passiert überhaupt nix.

Stale Dependencies

Fixed man die pkgdb mit

pkgdb -Ff

kommt die Frage, ob man Stale Depencies installieren will bei Paketen, bei denen pkgdb keine Abhängigkeit mehr gefunden hat. Auf die Frage antwortet man wie folgt:

Ich weiss, die Verknüpfung ist veraltet (Target existiert gar nicht mehr) -> yes
Verknüpfung wird noch benötigt -> no (Target wird dann automatisch neu runtergeladen und neu installiert)
Soll ich die neue Verknüpfung runterladen und installieren? (Install stale dependency? ([y]es/[n]o/[a]ll) [yes])

das sieht dann etwa so aus:

 pkgdb -F
--->  Checking the package registry database
Stale dependency: mimedefang-2.68 -> p5-DBD-mysql-4.017 (databases/p5-DBD-mysql):
p5-DBD-mysql50-4.017 (score:75%) ? ([y]es/[n]o/[a]ll) [no] y
Fixed. (-> p5-DBD-mysql50-4.017)
Stale dependency: p5-Mail-SpamAssassin-3.3.1_1 -> p5-DBD-mysql-4.017 (databases/p5-DBD-mysql):
p5-DBD-mysql50-4.017 ? ([y]es/[n]o/[a]ll) [yes] y
Fixed. (-> p5-DBD-mysql50-4.017)
Stale dependency: php5-extensions-1.4 -> php5-fileinfo-5.3.3_2 (sysutils/php5-fileinfo):
php5-filter-5.3.3_2 (score:44%) ? ([y]es/[n]o/[a]ll) [no] no
Install stale dependency? ([y]es/[n]o/[a]ll) [yes] 
** Stale lock file was found. Removed.
** Stale lock file was found. Removed.
[Gathering depends for sysutils/php5-fileinfo ................................................. done]
Fixed. (-> php5-fileinfo-5.3.3_2)

Platz schaffen mit portsclean

Mit der Zeit wird der Platz auf der Festplatte immer kleiner, da kann man zum Beispiel mit pkg_cutleaves die Ports aufräumen oder mit portsclean den Portbaum säubern. Zuerst kann der Portbaum auf den neusten Stand gebracht werden, damit die veralteten Quellcodedateien gelöscht werden können. Dies kann man zum Beispiel mit cvsup machen. Danach einfach folgenden Befehl als root ausführen:

portsclean -CDP

-C Löscht alle Arbeitsverzeichnisse aus dem Portbaum

-D Löscht alle veralteten Quellcodedateien aus dem /usr/ports/distfiles Verzeichnis

-P Löscht alle veralteten Pakete aus dem /usr/ports/packages Verzeichnis

Mehr Informationen zu portsclean in der Manpage portsclean

Die Ports-Sammlung kann sehr viel Plattenplatz verschlingen. Daher sollte man nach der Installation eines Ports make clean ausführen, um die Arbeitsverzeichnisse zu löschen. Das Kommando entfernt das Verzeichnis work nachdem ein Port gebaut und installiert wurde. Die Quelldateien im Verzeichnis distfiles kann man ebenfalls löschen. Entferne nicht mehr benötigte Ports, um weiteren Plattenplatz freizugeben.

Abhängigkeiten anzeigen

Um herauszufinden, welche Ports von den anderen benötigt werden, kann man pkg_info verwenden.

pkg_info xproto-7.0.14
Information for xproto-7.0.14:

Comment:
X11 protocol headers


Required by:
bdftopcf-1.0.1
cairo-1.8.6,1
font-bh-ttf-1.0.0
font-misc-ethiopic-1.0.0
font-misc-meltho-1.0.0_1
libXau-1.0.4
libXdmcp-1.0.2_1
libXfont-1.3.4,1
libfontenc-1.0.4
libxcb-1.1.93
mkfontdir-1.0.4
mkfontscale-1.0.6
pango-1.22.4
rrdtool-1.3.5
xcb-util-0.3.2
xorg-fonts-truetype-7.4


Description:
This package contains X protocol and ancillary headers.

WWW: http://www.freedesktop.org/wiki/Software/xlibs

- Eric Anholt
anholt@FreeBSD.org

Installierte Ports mit pkg_cutleaves ausmisten

Mit der Zeit sammeln sich installierte Ports an, die man vergessen hat oder nicht mehr braucht und von denen kein anderer Port abhängig ist. Zum Glück gibt es da pkg_cutleaves.

Einfach den Port sysutils/pkg_cutleaves installieren:

cd /usr/ports/ports-mgmt/pkg_cutleaves && make install clean

Danach einfach pkg_cutleaves als root starten:

# pkg_cutleaves

pkg_cutleaves führt nun alle Ports auf, von denen kein anderer Port abhängig ist und nun kann jeweils entschieden werden, ob man den Port löschen oder behalten will. Mit folgenden Tasten wird pkg_cutleaves gesteuert:

[Enter]  	Lässt den Port installiert
d 	        Markiert den Port zur Löschung
f 	        Hebt alle Löschmarkierungen auf
a 	        Bricht pkg_cutleaves ab, ohne Ports zu deinstallieren

Die zur Löschung markierten Ports werden deinstalliert, sobald man die Liste aller Ports, von denen kein weiterer abhängig ist, durchgearbeitet hat.

Die vollständige Liste kriegt man mit der -l Option:

# pkg_cutleaves -l

Ports, die in /usr/local/etc/pkg_leaves.exclude aufgeführt sind, werden von pkg_cutleaves nicht berücksichtigt, wenn pkg_cutleaves mit der Option -x aufgerufen wird.:

# pkg_cutleaves -x

Ports manuell reparieren

Es kommt ja öfters vor, dass ich die Hinweise im UPDATING erst lese, nachdem es Probleme gibt. D.h. ich habe dann oft verpasst die (neuen) Abhängigkeiten neu zu setzen vor dem Updaten. Im letzten Fall war es ein Problem, dass bei autoconf und automake die Versionen zusammengeführt wurden. Lösung war einfach alle Packages zu löschen und dann das neue zu installieren und dann die Abhängigkeiten neu zu schreiben:

1) Delete all the existing ports manually:

pkg_delete -f portname

2) Install the new port manually:

cd /usr/ports/devel/portname
make install clean

When you’ve done them all, then …

3) Fix the package database:

pkgdb -L
pkgdb -Fa

Problembehebung

Nach Upgrade können Probleme auftauchen – wenn z.B. Packages buggy sind oder nicht alles korrekt geupdated wurde. Bei folgenden Packages ist vorsicht geboten:

PNG

Wenn auf SHOE die Watermarks auf den Bildern plötzlich nicht mehr angezeigt werden (SHOE Logo oder das Avatar/Mainpic Icon im Admin) macht wahrscheinlich dieses Modul wieder Probleme. Um dem ganzen auf den Grund gehen zu können, erst mal das error_reporting im /images/img.php aktivieren.

error_reporting(6143);
gd-png: fatal libpng error: [00][00][00][00]: unknown critical chunk

Der Fehler sieht dann in der Regel so aus:

[30-Oct-2009 15:27:38] PHP Warning:  imagecreatefrompng() [<a href='function.imagecreatefrompng'>function.imagecreatefrompng</a>]: gd-png:  fatal libpng error: [00][00][00][00]: unknown critical chunk in /usr/data/www/server/SH_includes/class/images.class.php on line 32
[30-Oct-2009 15:27:38] PHP Warning:  imagecreatefrompng() [<a href='function.imagecreatefrompng'>function.imagecreatefrompng</a>]: gd-png error: setjmp returns error condition in /usr/data/www/server/SH_includes/class/images.class.php on line 32
[30-Oct-2009 15:27:38] PHP Warning:  imagecreatefrompng() [<a href='function.imagecreatefrompng'>function.imagecreatefrompng</a>]: '/www/shoe.org/new/images/icons/eye_16.png' is not a valid PNG file in /usr/data/www/server/SH_includes/class/images.class.php on line 32
[30-Oct-2009 15:27:38] PHP Warning:  imagecopy(): supplied argument is not a valid Image resource in /usr/data/www/server/SH_includes/class/images.class.php on line 66
[30-Oct-2009 15:27:38] PHP Warning:  imagecreatefrompng() [<a href='function.imagecreatefrompng'>function.imagecreatefrompng</a>]: gd-png:  fatal libpng error: [00][00][00][00]: unknown critical chunk in /usr/data/www/server/SH_includes/class/images.class.php on line 32
[30-Oct-2009 15:27:38] PHP Warning:  imagecreatefrompng() [<a href='function.imagecreatefrompng'>function.imagecreatefrompng</a>]: gd-png error: setjmp returns error condition in /usr/data/www/server/SH_includes/class/images.class.php on line 32
[30-Oct-2009 15:27:38] PHP Warning:  imagecreatefrompng() [<a href='function.imagecreatefrompng'>function.imagecreatefrompng</a>]: '/www/shoe.org/new/images/icons/mainpic_16.png' is not a valid PNG file in /usr/data/www/server/SH_includes/class/images.class.php on line 32
[30-Oct-2009 15:27:38] PHP Warning:  imagecopy(): supplied argument is not a valid Image resource in /usr/data/www/server/SH_includes/class/images.class.php on line 66

Dieser Fehler wird jedoch leider nicht immer ausgegeben. Manchmal endet es lediglich in einem Apache error und man hat keine Ahnung wo das Problem dann liegt…

[Fri Feb 04 15:35:19 2011] [notice] child pid 11445 exit signal Abort trap (6)

Checken, ob das Problem wirklich beim png liegt:

Lösung:

  • PNG reskursiv nochmals installieren.
portupgrade -fr png-1.2.40
  • oder PNG zur letzten noch funktionierenden Version downgraden (siehe nächstes Kapitel)

Ports Downgraden

Wenn ein neuer Port nicht so will wie er sollte, kann man ihn auch wieder downgraden. Das geht mit dem Port portdowngrade

Install portdowngrade

cd /usr/ports/ports-mgmt/portdowngrade
make install clean

Downgraden mit portdowngrade

portdowngrade graphics/png$ -s:pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs

Wichtig ist, am Ende mit einem „$“ abzuschliessen. machen wir das nämlich nicht, werden alle ports graphics/png* bearbeitet:

             the name of the port. Might be "portname" or "category/portname"
             and  my  optionally  be terminated with a "$" indicating that no
             trailing characters are allowed. So mozilla includes (among oth-
             ers) www/mozilla, www/mozilla-devel and x11-fonts/mozilla-fonts.
             mozilla$ includes only www/mozilla (from the 3 mentioned above),
             while www/mozilla includes www/mozilla and www/mozilla-devel.

Jetzt werden folgende 6 Schritte vom System durchgeführt, sofern man sich auf dem CVS Server erfolgreich eingeloggt hat. Weitere Infos zum CVS hier: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html ps. die Fehlermeldung

cvs checkout: warning: failed to open /root/.cvspass for reading: No such file or directory

kan man einfach ignorieren.

Erst sobald alle 6 Schritte abgeschlossen sind, kann man das Downgrade starten.

Step 1: Checking out port from CVS repository
Step 2: Reading the port history from the CVS repository
Step 3: Analyzing the port history from the CVS repository
Step 4: Load port version numbers and present results
Keys: <space> : next page                      d : details
            p : previous page
      <enter> : leave presentation and downdgrade if wanted
===================================================================================================================================
number         date         portversion  comment
cvs checkout: warning: failed to open /root/.cvspass for reading: No such file or directory
    1  2009/07/16 14:05:30  1.2.37       Update to 1.2.37
cvs checkout: warning: failed to open /root/.cvspass for reading: No such file or directory
    2  2009/03/30 19:33:54  1.2.35       Add MAKE_JOBS_SAFE
cvs checkout: warning: failed to open /root/.cvspass for reading: No such file or directory
    3  2009/02/24 04:01:48  1.2.35       Upgrade to 1.2.35
cvs checkout: warning: failed to open /root/.cvspass for reading: No such file or directory
    4  2009/01/04 18:01:21  1.2.34       Upgrade to 1.2.34
cvs checkout: warning: failed to open /root/.cvspass for reading: No such file or directory
    5  2008/11/13 10:19:40  1.2.33       Upgrade to 1.2.33
cvs checkout: warning: failed to open /root/.cvspass for reading: No such file or directory
    6  2008/09/20 18:24:28  1.2.32       Update to 1.2.32 which includes security fix.
Total lines: 129. Command:

Damit wir jetzt die gewünschte Nummer (3 – Ich will wieder zu version 1.2.35) eingeben können, müssen wir zuerst ENTER drücken:

<Enter>
Enter version number to change port to (0: exit): 3

Jetzt gehts weiter:

Step 5: Checking out choosen date of the port from the CVS repository
Step 6: Modifying the port (Type yes to downgrade the port, or no to abort).

Note: portdowngrade only changes the port, not the installed software!

After 6 steps, the selected port has been set to the selected older version. Continue by install the port. If you have portupgrade installed, use the following command to see the changes in the ports database:

portsdb -Uu

To ‘downgrade’ the installed port, issue command:

portupgrade -f portname

So, jetzt wurde der Port auf die alte Version geändert. Jetzt muss die Software effektiv gedowngraded werden Note: If you run cvsup, the port will be changed back to the latest version!

portsdb -Uu                #index file updaten <- dauert EXTREM lange!
portupgrade -f png         #effektiver downgrade

Hat der Port viele Abhängigkeiten (im oberen Fall benutzt z.B. PHP die pnglib) sollten alle Programme, die von diesem Port abhängig sind, reinstalliert werden:

portupgrade -fr png

(Ps. Apache neu starten, falls PHP changes gemacht wurden)

So, jetzt ist dieser Port definitiv gedowngraded. Übrigens, sobald man cvsup wieder laufen lässt, wird der Port wieder auf die aktuellste Version gesetzt. Wenn der Bug dann gefixt ist, kann man wieder normal upgraden.

Fehlermeldungen

Seeking port lang/php5 … not found

Falls die Ports nicht über die CD installiert wurden, sondern manuell runtergeladen worden sind, existiert keine index File. Dieses müsste zuerst generiert werden:

 make fetchindex

Nun funktioniert auch portdowngrade

User Management

User zu einer Gruppe hinzufügen

User mrsmirror ist der gruppe wheel und www zugeteilt:

root@corky(/)> id mrsmirror
uid=1003(mrsmirror) gid=1003(mrsmirror) groups=1003(mrsmirror),0(wheel),80(www)

so ändern wir die Gruppe:

root@corky(/)> pw usermod mrsmirror -G mysql
root@corky(/)> id mrsmirror
uid=1003(mrsmirror) gid=1003(mrsmirror) groups=1003(mrsmirror),88(mysql)

Soll sie Zugriff auf mehrere Gruppen haben, geht das so:

root@corky(/)> pw usermod mrsmirror -G mysql,www,cyrus
root@corky(/)> id mrsmirror
uid=1003(mrsmirror) gid=1003(mrsmirror) groups=1003(mrsmirror),80(www),88(mysql),60(cyrus)

Permissions

1 = x = eXecute (lesen, schreiben, löschen, ändern, Verzeichnis)
2 = w = Write (erlaube Files zu schreiben / ändern)
4 = r = Read (erlaube Files zu lesen)

Directories müssen immer x Permission haben, damit sie geöffnet werden können. Die Permission Blocks sind wie folgt aufgeteilt:

-rw- --- ---   1 cyrus  cyrus  2093 Mar 26  2008 34031.
1    2   3

1 = owner
2 = group
3 = world

Permissions von allen Directories ändern

Folgender Befehl findet alle Verzeichnisse (und Unterverzeichnisse) im Folder /var/spool/imap/ und ändert die Permission auf 770

find /var/spool/imap/*/ -type d -exec chmod 770 {} \;

Permissions von allen Files in den Directories ändern

find /var/spool/imap/ -type f -exec chmod 660 {} \;

Files im Single User Modus bearbeiten

Wenn man eine HDD ausgetauscht hat und vergessen hat, vorher fstab anzupassen, bootet das System im Single User Modus. In diesem Modus ist dann aber der Editor vi per default nicht verfügbar, da /usr/bin nicht gemounted ist. Somit kann man die Dateien auch nicht einfach bearbeiten.

# vi /etc/fstab
# vi not found

Um das Problem zu lösen, einfach

# mount -a

ausführen. Danach ist vi verfügbar und man kann die nötigen Anpassungen durchführen.

 

Diverse Fehlermeldungen

kernel: g_vfs_done():vtbd2s1d[READ(offset=10503225344, length=131072)]error = 5 g_vfs_done():vtbd2s1d[WRITE(offset=6935674880, length=32768)]error = 5

Während einem Backup sind plötzlich folgende Kernel Fehler aufgetaucht:

May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=10503225344, length=131072)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=10502438912, length=131072)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=10502176768, length=131072)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=10502045696, length=131072)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=10501783552, length=131072)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=10501914624, length=131072)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=10502438912, length=98304)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[WRITE(offset=6935674880, length=32768)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[WRITE(offset=6940459008, length=32768)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[WRITE(offset=6565232640, length=32768)]error = 5
May 25 06:12:14 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=10502537216, length=131072)]error = 5
[...]
May 25 06:14:15 tesla kernel: handle_workitem_freefile: got error 5 while accessing filesystem

Danach hat alles auf dem Server gestoppt (in diesem Fall war MySQL nicht mehr verfügbar: Connection Refused). Als ich mich auf dem Server eingeloggt habe, gabs danach sofort Kernel Panic Messages und der Server hat neu gestartet (obwohl ich das nicht bemerkte während dem Login? Vielleicht hat er auch vor meinem Login neu gebootet aber die Log Messages wurden erst geschrieben als ich mich einloggte?).

Dieses Problem ist sehr ärgerlich, da mir durch den Hard-Reboot alle InnoDB Datenbank Tables gecrashed sind…

Wie auch immer, das war der Output:

May 25 06:14:15 tesla kernel: g_vfs_done():vtbd2s1d[READ(offset=131072, length=32768)]error = 5
May 25 06:14:15 tesla kernel: handle_workitem_freefile: got error 5 while accessing filesystem
May 25 08:38:46 tesla su: teslina to root on /dev/pts/0
May 25 08:41:55 tesla syslogd: kernel boot file is /boot/kernel/kernel
May 25 08:41:55 tesla kernel: panic: softdep_deallocate_dependencies: dangling deps
May 25 08:41:55 tesla kernel: cpuid = 0
May 25 08:41:55 tesla kernel: KDB: stack backtrace:
May 25 08:41:55 tesla kernel: #0 0xffffffff804f5e10 at kdb_backtrace+0x60
May 25 08:41:55 tesla kernel: #1 0xffffffff804c11c4 at panic+0x1b4
May 25 08:41:55 tesla kernel: #2 0xffffffff806ab3db at softdep_deallocate_dependencies+0x1b
May 25 08:41:55 tesla kernel: #3 0xffffffff8053d624 at getnewbuf+0x404
May 25 08:41:55 tesla kernel: #4 0xffffffff8053ec16 at getblk+0x426
May 25 08:41:55 tesla kernel: #5 0xffffffff8054293e at cluster_rbuild+0x24e
May 25 08:41:55 tesla kernel: #6 0xffffffff805433e5 at cluster_read+0x535
May 25 08:41:55 tesla kernel: #7 0xffffffff806c5d98 at ffs_read+0x1f8
May 25 08:41:55 tesla kernel: #8 0xffffffff8075ce92 at VOP_READ_APV+0x52
May 25 08:41:55 tesla kernel: #9 0xffffffff805649a8 at vn_read+0x248
May 25 08:41:55 tesla kernel: #10 0xffffffff805081d8 at dofileread+0xa8
May 25 08:41:55 tesla kernel: #11 0xffffffff805083a7 at kern_preadv+0x77
May 25 08:41:55 tesla kernel: #12 0xffffffff805084a0 at sys_pread+0x50
May 25 08:41:55 tesla kernel: #13 0xffffffff80719317 at amd64_syscall+0x307
May 25 08:41:55 tesla kernel: #14 0xffffffff80704a97 at Xfast_syscall+0xf7
May 25 08:41:55 tesla kernel: Uptime: 18d7h10m48s
May 25 08:41:55 tesla kernel: Automatic reboot in 15 seconds - press a key on the console to abort
May 25 08:41:55 tesla kernel: Rebooting...
May 25 08:41:55 tesla kernel: cpu_reset: Stopping other CPUs
May 25 08:41:55 tesla kernel: Copyright (c) 1992-2012 The FreeBSD Project.
May 25 08:41:55 tesla kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
May 25 08:41:55 tesla kernel: The Regents of the University of California. All rights reserved.
May 25 08:41:55 tesla kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
May 25 08:41:55 tesla kernel: FreeBSD 9.0-STABLE #0: Tue Jan 31 17:26:46 CET 2012
[...]
May 25 08:41:55 tesla kernel: Trying to mount root from ufs:/dev/vtbd0p2 [rw]...
May 25 08:41:55 tesla kernel: WARNING: / was not properly dismounted

Auf der Suche nach einer Lösung hab ich folgende hilfreiche Seiten gefunden:

Anscheinend ein I/O Problem. Lösen kann man dies anscheinend, indem man die Softupdates ausschaltet. Dave hat in seinem Artikel nicht bei der Source, sondern bei der Target Festplatte das Softupdate abgestellt. Da meine Backup Disk per NFS auf einen anderen Server verlinkt ist, könnte dies das Timeout verursachen. Es gibt jetzt zwei Möglichkeiten:

1) Man schaltet die Soft-Updates der Source Platte vtbd2s1d aus. Das wäre allerdings nicht so vorteilhaft, da es sich hier um die /database/ Partition handelt.  Um das machen zu können, müsste erst die database Partition umounted werden, danach Soft Updates per tunefs -n disable /dev/vtbd2s1d abschalten. Danach Partition wieder mounten. (Ob Soft Updates aktiviert oder deaktiviert sind, kann man übrigens mit tunefs -p vtbd2s1d checken)

2) Man schaltet die Soft-Updates auf der Target Platte aus (wie es Dave gemacht hat).  Da es sich bei mir aber um eine NFS Partition handelt, war hier wohl einfach das Problem, dass es ein NFS Timeout gab. Für’s erste werde ich einfach mal die Backups nicht mehr auf dem Mysql Server ausführen, sondern direkt auf dem Server wo sich die Backup Disk befindet. So kann es kein NFS Timeout diesbezüglich mehr geben. Sollte dies das Problem nicht lösen, müsste ich die Softupdates abschalten. Als erstes mal auf der Backup Disk. Wenn das immernoch nicht klappt, auf der Source Disk.

Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl

Diese Nachricht kann manchmal im Security Output Mail angezeigt werden. (Syslog Messages)

corky.shoe.org kernel log messages:
+++ /tmp/security.OPljQkNJ	2010-06-12 05:02:48.000000000 +0200
+Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
+Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
+Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
+pid 35361 (httpd), uid 80: exited on signal 11
+pid 35347 (httpd), uid 80: exited on signal 11

Was ich dazu gefunden habe:

(This is about 7.0-BETA3 amd64)

Can someone explain to someone who isn't a VM guru exactly what 
vm.pmap.shpgperproc does?

My understanding of how the VM system works isn't great but my 
understanding is, if you have a process that's malloc'ed, say, 100MB of 
memory, then it forks, and the child modifies 5MB of it, the total memory 
usage is really 105MB instead of 200MB because unmodified pages used by 
both copies are kept as just a single copy; modified pages are copied on 
write and eventually cause the processes to grow.

For example, having mod_perl2 preload and precompile all scripts, instead 
of doing it on their first hit, should save a ton of memory because the 
children will share the memory from the parent: 
http://www.perl.com/pub/a/2002/07/30/mod_perl.html is an old article 
explaining how I think it works.

On a quad-core box with about 200 mod_perl2 Apache processes, and about 
2000 other much smaller Apache processes with the mod_perl shut off, I get 
"Aproaching the limit on PV entries, consider increasing either the 
vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl" a few times on the 
console after a reboot.  Raising vm.pmap.shpgperproc from the default 200 
up to 500 reduces these but doesn't eliminate them.

My question is, does vm.pmap.shpgperproc affect how much of the parent's 
memory a forked child can share, or does it just affect things like SysV 
SHM where a proces has to explicitly request a shared pool of memory for 
IPC, or is it something else entirely?  Because if it's the former, the 
default of 200 would mean only 800K memory shared between mod_perl 
processes which for this situation is absurdly low -- so I hope I'm wrong 
on how that works. :)

Also, what's the danger of setting it too high, on an amd64 system with 4 
GB memory (soon to be 6 GB), given the process counts above?  I'm 
attempting to run with it set to 2048 right now and not noticing any ill 
effects.  On amd64 it appears to be tunable at runtime, vs i386 where you 
have to tweak PMAP_SHPGPERPROC in the kernel config -- very handy.

I have found some old discussions about PMAP_SHPGPERPROC on Google but 
none of the ones I read really get specific enough for me; they all just 
seem to say "keep raising it til the warnings on the console go away" :)

Side question: Anyone know of a way to profile Apache memory usage on a 
per-module basis?

>  (This is about 7.0-BETA3 amd64)
>
>  Can someone explain to someone who isn't a VM guru exactly what 
>  vm.pmap.shpgperproc does?

In non-technical terms, shpgperproc tells the OS a rough guess of how many
pages will be shared between processes. The pv_entry_max is generated by
multiplying shpgperproc by the maximum number of processes (maxproc) that
was compiled into the kernel and adjusts for the page count. If maxproc was
not hardcoded, then maxproc is also calculated based on the number of pages
available in the computer

When processes shares a physical page, each process may have a different
virtual address for the page. The OS maintains a list of all the processes
that are sharing the managed physical page and virtual address in that process.
This structure also keeps a list of all the managed pages that are currently
being used by this process. The structure that make up these lists is called
a pv_entry.

The new "chunked" pv_entry in FreeBSD 7 and 8 for the amd64/i386 architectures
is very space efficient and IMO could tolerate higher shpgperproc/pv_entry_max
limits.

Raising the pv_entry_max too high, the problem will be getting a page for
the pv_entry chunk, as well as getting physical page to share. More memory
and increasing the pv_entry limits will help you avoid this problem.

--Mark Tinguely
Can someone briefly explain what this is telling me and how to decide
which sysctl to increase? I have found some old postings that predate
the sysctls that suggested increasing shpgperproc in the kernel
configuration, about 50 at a time until the problem goes away, but I
still have no clue what that is accomplishing. 
Re: kernel: Approaching the limit on PV entries...
Click to flag this post

by Mark Tinguely Oct 11, 2008; 04:21am :: Rate this Message: - Use ratings to moderate (?)

Reply | Print | View Threaded | Show Only this Message
>  > vm.pmap.pv_entry_count: 583006
>  > vm.pmap.shpgperproc: 200
>  > vm.pmap.pv_entry_max: 2243305
>  >
>  > The system:
>  > FreeBSD .... 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #0: Wed Oct  1
>  > 07:51:58 UTC 2008
>  > root@...:/usr/obj/usr/src/sys/GENERIC  amd64
>  >
>  > Can someone briefly explain what this is telling me and how to decide
>  > which sysctl to increase? I have found some old postings that predate
>  > the sysctls that suggested increasing shpgperproc in the kernel
>  > configuration, about 50 at a time until the problem goes away, but I
>  > still have no clue what that is accomplishing.
... [show rest of quote]

what (simplified):
the pv_entry helps the virtual memory system track physical pages, so a
physical page can be shared with another process or another virtual address.

In the i386/amd64 the pv_entry entries are allocated in page size "chunks"
on a per process memory map basis. This helps reduce redundant pointers
and overall saves memory.

"shpgperproc" can be read as "the number of shared pages per proceess".
pv_entry_max is calculated from shpgperproc (and on the amd64, shpgperproc
can be derived from setting the vm.pmap.pv_entry_max).

On the amd64, the values can be adjusted by sysctl, but on the i386
the values must be compiled into the kernel.

There are some automatic adjustments in the calculation of the number
of pv_entry, but the warnings are given early enough to help aid in the
tweaking of the value. The advice of slowly increasing vm.pmap.shpgperproc
is probably the best solution. I would adjust up slower than 50 (25%
increase seems to be pretty high).

--Mark Tinguely.

Als Antwort habe ich gefunden, dass man

sysctl kern.ipc.shm_use_phys=1

setzen soll (Default ist 0)

Oder zum Beispiel auch die Value von

vm.pmap.shpgperproc

erhöhen (Default ist 200)

Aktuelle Values anzeigen:

root@corky(/home/)> sysctl vm.pmap
vm.pmap.pmap_collect_active: 0
vm.pmap.pmap_collect_inactive: 0
vm.pmap.pv_entry_spare: 73389
vm.pmap.pv_entry_allocs: 94783346484
vm.pmap.pv_entry_frees: 94782748713
vm.pmap.pc_chunk_tryfail: 0
vm.pmap.pc_chunk_frees: 446470895
vm.pmap.pc_chunk_allocs: 446474890
vm.pmap.pc_chunk_count: 3995
vm.pmap.pv_entry_count: 597771
vm.pmap.shpgperproc: 200
vm.pmap.pv_entry_max: 2244232

root@corky(/home/)> sysctl kern.ipc.shm_use_phys
kern.ipc.shm_use_phys: 0

Lösung

Momentan habe ich diesbezüglich noch NICHTS gemacht (12.06.10). Erstmal abwarten, ob sich diese Fehler häufen.

2.mal vorgekommen: 2010-06-24

Sollten diese Fehler in Zukunft weiterhin auftreten, mal gemäss Mark Tinguely die Values von shpgperproc langsam erhöhen. Am Besten im Step von 25 – bis die Fehler aufhören.

sysctl vm.pmap.shpgperproc=225
...
sysctl vm.pmap.shpgperproc=250
etc.

Auf Patsy habe ich diese Fehler auch erhalten – und per 23.04.2011 angefangen shpgperproc zu erhöhen.

  • *

    Du kannst diese HTML tags verwenden: <a> <abbr> <acronym> <b> <blockquote> <cite> <code> <del> <em> <i> <q> <s> <strike> <strong>

  • Kommentar-Feed für diesen Beitrag
nach oben