DSM 3.1 nach Update - 100% CPU & /tmp wird vollgeschrieben

Status
Für weitere Antworten geschlossen.

ralf9000

Benutzer
Mitglied seit
27. Jul 2009
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Liebes Forum,

nach dem Upgrade auf 3.1 läuft meine DS209+II mt 100% CPU und schreibt das /tmp mit Datein zu
-rw------- 1 postfix postfix 8192 Mar 4 18:20 .db.user.tmp.6574.appprivilege.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:20 .db.user.tmp.6574.misc.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:20 .db.user.tmp.6574.name.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:20 .db.user.tmp.6574.shadow.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:20 .db.user.tmp.6574.smb.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:20 .db.user.tmp.6574.uid.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:22 .db.user.tmp.7704.appprivilege.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:22 .db.user.tmp.7704.misc.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:22 .db.user.tmp.7704.name.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:22 .db.user.tmp.7704.shadow.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:22 .db.user.tmp.7704.smb.1594
-rw------- 1 postfix postfix 8192 Mar 4 18:22 .db.user.tmp.7704.uid.1594


In/var/log/messages wird parallel dazu
Mar 4 20:14:33 postfix/smtpd[30363]: user_db_check_and_rebuild.c:130 SYNOUserDBRebuild failed, synoerr=0x2800
Mar 4 20:14:39 postfix/local[30589]: user_db_rebuild.c:56 rename(/tmp/.db.user.tmp.30589.name.1594, /tmp/.db.user.name.1594) = (1)/Operation not permitted
Mar 4 20:14:39 postfix/local[30589]: user_db_check_and_rebuild.c:130 SYNOUserDBRebuild failed, synoerr=0x2800
Mar 4 20:14:39 postfix/local[30589]: user_db_rebuild.c:56 rename(/tmp/.db.user.tmp.30589.name.1594, /tmp/.db.user.name.1594) = (1)/Operation not
geschrieben. Meine Mail-Konfiguration ist rein Standard, nichts am GUI vorbei konfiguriert.

Was ist zu machen? Liegt es irgendwo an Zugangsrechten?

Für jede Hilfe vielen Dank im voraus!

Grüße,

Ralf
 

Herbert_Testmann

Benutzer
Mitglied seit
27. Jul 2009
Beiträge
1.114
Punkte für Reaktionen
1
Punkte
64
Das eine hat evtl. mit dem anderen nichts zu tun.
Hast Du mal geschaut, welcher Prozess die 100% verursacht?
Nach dem Update auf 3.1 werden in der Photostation neue Vorschaubilder in iPad Größe angelegt. Der "convert" Prozess hält die DS (je nach Menge der Photos) bis zu 1 Woche bei 100%.
 

ralf9000

Benutzer
Mitglied seit
27. Jul 2009
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Ich setze keine Photostation ein und habe auf dieser DS auch keine Photos, d.h generell keine Multimedia-Dateien. Diese DS, weil sie nur die "Basisfunktionen" Mail plus Windows-Filespace für Dokumente beinhaltet, date ich diese immer zuerst up, um bei der komplexeren DS schon Sicherheit bzw. Erfahrung zu haben.

Es sind übrigens Email-Prozesse, die die 100% verursachen, allerdings kein einzelne PID, sondern immer Neue, anscheinend werden irgendwie immer neue Prozesse gestartet.
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.008
Punkte für Reaktionen
2.701
Punkte
423
Hallo Ralf,

die db.user.tmp-Dateien in /tmp gibt es bei mir auch und die "leben" auch. Allerdings erzeugt der Vorgang keine Last und es sind ja auch nur ein paar Bytes.
Bei mir gehören die Dateien aber "root" und nicht "postfix". Aus den Ausgaben in messages bei dir schliesse ich, dass da irgendeinem Prozess (saslauthd ?) irgenwelche Rechte fehlen.
Was sagt den die Prozessliste (ps)? Wem gehören die Prozesse bei dir?

Hier ein Ausschnitt von mir:
Code:
 7303 root      2300 S    /usr/syno/mailstation/sbin/saslauthd -a shadow
 7305 root      2300 S    /usr/syno/mailstation/sbin/saslauthd -a shadow
 7306 root      2300 S    /usr/syno/mailstation/sbin/saslauthd -a shadow
 7307 root      2300 S    /usr/syno/mailstation/sbin/saslauthd -a shadow
 7308 root      2300 S    /usr/syno/mailstation/sbin/saslauthd -a shadow
 7340 root     11640 S    /usr/syno/mailstation/libexec/master
 7343 root      9896 S    /usr/syno/mailstation/sbin/dovecot
 7344 root     10136 S    dovecot-auth
 7345 root     10136 S    dovecot-auth -w
 7358 postfix  11676 S    pickup -l -t fifo -u
 7359 postfix  11740 S    qmgr -l -t fifo -u
 7360 dovecot   9744 S    pop3-login
 7361 dovecot   9744 S    pop3-login
 7362 dovecot   9744 S    pop3-login
 7363 dovecot   9756 S    imap-login
 7364 dovecot   9756 S    imap-login
 7365 dovecot   9756 S    imap-login

Edit:
Noch was. Die Mailstation ist ja m.W. jetzt eingebaut. Hast du evtl. noch eine alte Mailstation als Zusatz-Package installiert? Wenn ja, aktualisier das Package auf die aktuelle Mailstation 2 für die 3.1.
 
Zuletzt bearbeitet:

ralf9000

Benutzer
Mitglied seit
27. Jul 2009
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Danke erstmals für die Hilfe, miene Prozesse sehen so aus:
PID USER VSZ STAT COMMAND
2043 root 10136 S dovecot-auth -w
2645 dovecot 9756 S imap-login
3353 admin 34140 S /usr/syno/pgsql/bin/postgres -D /var/services/pgsql
3355 admin 34268 S postgres: writer process
3356 admin 34140 S postgres: wal writer process
5742 root 2300 S /usr/syno/mailstation/sbin/saslauthd -a shadow
5758 root 2300 S /usr/syno/mailstation/sbin/saslauthd -a shadow
5759 root 2300 S /usr/syno/mailstation/sbin/saslauthd -a shadow
5761 root 2300 S /usr/syno/mailstation/sbin/saslauthd -a shadow
5762 root 2300 S /usr/syno/mailstation/sbin/saslauthd -a shadow
6005 root 11640 S /usr/syno/mailstation/libexec/master
6010 root 9896 S /usr/syno/mailstation/sbin/dovecot
15734 postfix 11676 S pickup -l -t fifo -u
23615 dovecot 9756 S imap-login
Auf die Mailstation 2 hatte ich auch mit upgedated. Die Prozesse mit 5-stelliger PID sind diejenigen die die 100% CPU verbraten und alle paar Sekunden sich neu starten und eine neue PID bekommen.
 

Benares

Benutzer
Sehr erfahren
Mitglied seit
27. Sep 2008
Beiträge
12.008
Punkte für Reaktionen
2.701
Punkte
423
Sorry, da bin jetzt auch überfragt. Offensichtlich klappt ja das Umbenennen nicht.
Bei mir läuft die Mailstation nicht dauerhaft. Nach dem Booten gibt es unter /tmp einige Dateien von der Art mit aktuellem Zeitstempel. Wenn ich dann die Mailstation starte, beginnen einige davon "zu leben". Die Datei gehören aber root und sind auch nicht schreibgeschützt. Dateien mit .tmp. im Namen seh ich nie.
Code:
drwxrwxrwt    7 root     root           920 Mar  5 16:12 .
drwxr-xr-x   23 root     root          4096 Mar  5 16:05 ..
-rw-rw-rw-    1 root     root          8192 Mar  5 16:06 .db.group.desc.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:06 .db.group.id.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:06 .db.group.name.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:06 .db.synoshare.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:10 .db.user.appprivilege.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:10 .db.user.misc.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:10 .db.user.name.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:10 .db.user.shadow.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:10 .db.user.smb.1594
-rw-rw-rw-    1 root     root          8192 Mar  5 16:10 .db.user.uid.1594
Darf User postfix so eine Datei überhaupt umbenennen? (z.B. "su postfix -s /bin/sh -c mv /tmp/.db.user.tmp.30589.name.1594 /tmp/.db.user.name.1594")
Ich würde mal alles, was zu Mail gehört ausschalten, die Dateien löschen, neu booten, und dann schrittweise wieder einschalten und sehen was passiert.
Auf /tmp ist noch Platz (df) und die Rechte auf 777?

PS: Nimm Code-Tags anstatt Quote-Tags für solche Zitate. Ist besser lesbar.

Edit:
Ich bin mir übrigens garnicht sicher, dass die Dateien wirklich primär von Postfix stammen. Ich habe momentan alles was zu Mail gehört aus, seh auch keine verdächtigen Prozesse, trotzdem "leben" die Dateien weiter. Sie entstehen beim Booten auch, wenn garnichts vom Mailpaket gestartet wird. Es könnte auch sonstwas mit Benutzerauthenitifizierung in der neuen FW zu tun haben.

Gruß
Benares
 
Zuletzt bearbeitet:

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
die db-Dateie, die dem Benutzer 'root' gehören, sind die SMB-Datenbanken (Samba)

Itari
 

ralf9000

Benutzer
Mitglied seit
27. Jul 2009
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Ich habe jetzt aufgrund dessen, dass alle 2 Tage das /tmp-Verzeichnis mit diesen Dateien voll war und das die DS permanent unter Volldampf lief, wieder 3.0 (hab zum Glück von der Festplatte eine 1:1 Kopie gemacht) zurückgespielt. Hier funktioniert alles erstmal wieder Bestens. Ich warte jetzt auf eine offizielle Korrekturversion oder das sich Synology bei mir aufgrund meiner Meldung reagiert.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat