poplock.db: Bad file descriptor

m.m.
Posts: 45
Joined: 2009-09-07 19:32

poplock.db: Bad file descriptor

Post by m.m. »

Nachdem aufgrund eines 'unausgereiften' Backup Prozesses (ich hasse Plesk - hier noch 9.2.3 :-& ) die Platte übergelaufen ist (disk quota exceeded auf einem 1und1 vserver mit Suse 10.3 - ja ich weiss, update des Servers ist bestellt, den jetzigen bekommt man nicht mit einem anderen (Suse) Image..) werde ich die folgende Fehlermeldung in Postfix (/var/log/mail.warn) nicht mehr los:

Code: Select all

fatal: open database /var/spool/postfix/plesk/poplock.db: Bad file descriptor

verursacht durch folgenden cron-job der alle 10 Min. läuft (/var/log/messages):

Code: Select all

/usr/sbin/cron[24547]: (root) CMD (/usr/lib64/plesk-9.0/postfix-poplockdb-clean)
poplock DB cleanup[32055]: started
poplock DB cleanup[32055]: fatal error: postmap: fatal: open database /var/spool/postfix/plesk/poplock.db: Bad file descriptor

Die Datei ist 0 byte gross und war zum Zeitpunkt des Plattenproblems geöffnet.

Postfix tut seinen Dienst und hätte ich kein Logfile, hätte ich wahrscheinlich auch kein Problem....hab ich nun aber.... 8-[

Für einen Hinweis wäre ich dankbar. [-o<
Top

m.m.
Posts: 45
Joined: 2009-09-07 19:32

Re: poplock.db: Bad file descriptor

Post by m.m. »

Das nennt man dann wohl 'pädagogisch wertvoll' :wink:

Ich kann mir leider meine Zeit nicht so frei einteilen und der Tag hat nur 24 Stunden daher wird das dann noch 6 bis 8 Wochen warten müssen aber prinzipiell hast Du natürlich Recht.
Top

User avatar
Joe User
Project Manager
Project Manager
Posts: 11518
Joined: 2003-02-27 01:00
Location: Hamburg

Re: poplock.db: Bad file descriptor

Post by Joe User »

Die Reste des fehlgeschlagenen Plesk-Backup beseitigt?
Schon rebootet? Löst so manches Problem, nicht nur unter Windows...
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.
Top

m.m.
Posts: 45
Joined: 2009-09-07 19:32

Re: poplock.db: Bad file descriptor

Post by m.m. »

Die Reste sind beseitigt und selbst VPS hat gestern mittag wieder (allerdings unaufgefordert....) angefangen, ein neues Full Backup anzulegen (23GB Full in etwa 40 Min.) und ist diesmal nicht in einen timeout gelaufen (das hatte ich schon reklamiert da 1und1 die Container anscheinend default auf 3600 stehen hat).

Ich habe also wieder genug Platz, aber weil es eben nicht Windows ist, dachte ich noch nicht an einen Reboot des Servers. Einzig syslog habe ich nach dem Vorfall neu gestartet und alle anderen Services laufen ja auch wie sie sollen (selbst Postfix tut seinen Dienst, abgesehen von der Fehlermeldung im Log).

Aber natuerlich kann ich den Server neu booten. Der ist ja erst seit dem 01.11.09 up und insgesamt ist es der 2.te Reboot überhaupt.
Top

m.m.
Posts: 45
Joined: 2009-09-07 19:32

Re: poplock.db: Bad file descriptor

Post by m.m. »

Ich verbringe am Tag mehr als 30 Minuten mit meinem Server und logdigest ist mir ebenfalls ein Begriff. Ich denke, daß ich meinen root-Server mit der genügenden Sorgfalt betreibe aber auch ich mache das nicht hauptberuflich.

Ich will hier keine Grundsatz Diskussion anstossen. Nach Deinem Maßstab müsste man vermutlich 95% aller Rootserver abklemmen weil sich deren root nicht ausreichend kümmert (geschweige denn Ahnung hat) - und da würde ich Dir nicht widersprechen.

Es sind eher die Vorbereitungen den Umzug betreffend die mich im Moment davon abhalten heute Abend schon damit anzufangen. Genau wie Du sagst muss man vorher sehr genau prüfen, was in der neuen Umgebung angepasst werden muss und der Teufel steckt bekanntlich im Detail.

Wenn es bei 1und1 ein Image mit OpenSUSE 11 für den vserver geben würde, hätte ich den Server schon initialisiert. Seltsamerweise haben Sie für den vserver Bedenken -deswegen gibt es nur ein 10.3 Image-, beim Cloudserver bieten sie es allerdings an (11.1 glaube ich).

Muss ich das verstehen? Nein. Muss ich damit leben? Im Moment jedenfalls, ja. Bin ich damit zufrieden? Nein.

Ich versuche jedenfalls zu verstehen was mit Postfix falsch gelaufen ist und lasse das log nicht nach /dev/null schreiben.
Top

m.m.
Posts: 45
Joined: 2009-09-07 19:32

Re: poplock.db: Bad file descriptor

Post by m.m. »

An postmap habe ich auch gedacht aber es gibt keine poplock.irgendwas aus der die poplock.db erstellt wird (anders als bei transport, smtp_auth etc.). Aber ich werde mir mal die Admindoku vornehmen.

Bzgl: Image: Es gibt für keinen 1und1 vServer ein 11.x Image. Beim Cloudserver (was ja im Prinzip auch ein vserver ist) aber schon. Wahrscheinlich aus den eben von Dir genannten Gründen: Ein neues Produkt mit einem nicht mehr gepflegten BS auszustatten macht ja auch nicht wirklich Sinn.

Da ich von einem vServer Vertrag auf einen Opencloudserver umsteige, bekomme ich dabei automatisch ein 11.x Image.

Danke für die Info.
Last edited by m.m. on 2010-02-11 13:10, edited 1 time in total.
Top

m.m.
Posts: 45
Joined: 2009-09-07 19:32

Re: poplock.db: Bad file descriptor

Post by m.m. »

Hab ich gemacht (gelöscht und mit den gleichen Berechtigungen neu angelegt) aber bekomme nach wie vor:

Code: Select all

Feb 11 13:45:01 xxx poplock DB cleanup[18412]: started
Feb 11 13:45:02 xxx poplock DB cleanup[18412]: fatal error: postmap: fatal: open database /var/spool/postfix/plesk/poplock.db: Bad file descriptor


Hmm...ich würde ja fast /etc/postfix sichern und erst postfix über den autoinstaller deinstallieren und qmail installieren - dann wieder umgekehrt zurück.

Aber das ist irgendie Windows-alike....naja, Plesk halt :-#

Vielleicht boote ich den Server mal und schaue was dabei passiert....
Top

m.m.
Posts: 45
Joined: 2009-09-07 19:32

Re: poplock.db: Bad file descriptor

Post by m.m. »

Jo...hab ich auch festgestellt (nach dem Reboot).

Ich überlege noch ob ich wie hier http://kb.parallels.com/en/5801 beschrieben den MTA mit dem Plesk autoinstaller auf qmail ändere und danach wieder auf postfix zurück gehe oder ob ich wirklich schon jetzt den Cloud bestelle....wenn, dann kann auch gleich den konfigurieren.

Am Ende vielleicht besser als jetzt mit dem autoinstaller eine ansonsten intakte Installation zu gefährden. Wenn der sich verschluckt, hab ich am Ende mehr Stress und auch nicht weniger Arbeit.

Danke für Deine Zeit. :-D
Top

m.m.
Posts: 45
Joined: 2009-09-07 19:32

Re: poplock.db: Bad file descriptor

Post by m.m. »

Update: Das Problem besteht weiterhin aber:

Nachdem ich Plesk noch eine Chance gegeben habe und der verbleibende Platz nicht ausreicht, die gzip Archive zu erstellen bevor sie auf ein FTP repository ausgelagert werden hat es mir gereicht: Bevor die Platte wieder zuläuft Backup abgebrochen, aufgeräumt und abgehakt (ganz davon abgesehen, daß Plesk nichts von gpg weiß...).

Kurzum: Meine Backpups erledigt nun Duply (Anm.: Der Hinweis hier im Forum auf http://www.heise.de/security/artikel/Hi ... 70834.html war schon nicht schlecht aber das Script ist noch auf duplicity 0.4.11 ausgelegt, aktuell ist aber 0.6.06 => also Duply installiert, gpg key erstellt und cronjob eingerichtet.

Wenn das erste Full-Backup auf meinem externen FTP Space durch ist, gehe ich (vielleicht) an eine Neu-Konfiguration von Postfix via Plesk. Oder ich drehe den cronjob auf

Code: Select all

/usr/lib64/plesk-9.0/postfix-poplockdb-clean 

einfach ab. :lol:
Top

m.m.
Posts: 45
Joined: 2009-09-07 19:32

Re: poplock.db: Bad file descriptor

Post by m.m. »

Da ich es hasse wenn ich auf der Suche nach einer Problemlösung:
1. passende Einträge in einem Forum finde die aber
2. ohne eine Problemlösung oder noch besser mit einem 'Danke, ich hab das Problem gelöst'

aufhören, möchte ich euch meine Lösug nicht vorenthalten:

Ich habe zuerst mein /etc/postfix Verzeichnis gesichert und dann wie in http://kb.parallels.com/en/5801 beschrieben den MTA erst auf qmail geändert und sofort wieder auf postfix zurückgeändert.

Dabei wurde die poplock.db neu erstellt.

@matzewe01
Ich werde meinen Server trotzdem upgraden ;)
Last edited by m.m. on 2010-02-14 17:12, edited 1 time in total.
Top