Domino 10.0.1 - "File is in use by another program" nach DAOS resync

[Manfred W.]

Hallo zusammen,

wir sind auf ein merkwürdiges Problem bei Domino 10.0.1 gestoßen.
Nach einem DOAS resync (entweder forced oder nachdem der Katalog tatsächlich nicht mehr synchron war) kann man weder Datenbanken löschen noch einen copy-style compact auf den Datenbanken ausführen. Es erscheint immer die Meldung "File is in use by another program".
Laut Process Explorer greifen nur nserver.exe und ndaosmgr.exe auf die Dateien zu. Kein anderes Programm.
drop xxx.nsf und dbcache flush helfen auch nicht.
Nur ein Neustart des Domino Servers hilft. So lange die ndaosmgr.exe nicht auf die nsf-Dateien zugreift, kann man einen compact -c ausführen und Datenbanken löschen.

Auf Domino 9.0.1 besteht das Problem nicht.

Case bei IBM ist offen (TS002276239).

Hat das sonst noch jemand?

Grüße
Manfred

[eknori]

Interessant. Bleibt der Zustand so, oder wird die Datei nach einer Zeit wieder freigegeben?

[Manfred W.]

Ich werde das nochmal gezielt beobachten. Aber mein Eindruck ist, dass der Zustand auch Tage lang so bleibt, und wirklich erst mit einem Neustart des Domino Servers behoben wird.

[eknori]

Ist das nur eine Datenbank aus der Grundgesamtheit aller DAOS enabled Datenbanken?
Oder ist es gezielt die EINE Datenbank, die den Katalog aus den Tritt gebracht hat?

Was hast du in dein Ticket als steps to reproduce geschrieben?

[eknori]

Habe es auf meinem System nachstellen können. Ich hänge mich mal an deinen TS dran

[eknori]

Hallo Manfred,

ich habe es heute morgen einmal auf meinen Systemen getestet.

Server A is Domino 10.0.1 FP1 / Windows
Server B ist Domino 9.0.1 FP10

beide Server sind DAOS enabled; auf beiden Servern läuft Traveler.

Das von Dir beschriebene Problem scheint nicht nur den DAOSMGR process zu betreffen. Ich kann das auch mit TRAVELER nachstellen.

Ich habe beide Server komplett neu gestartet, um gleiche Startbedingungen zu haben, und gewartet, bis beide Server alle Prozesse sauber geladen haben.

Dann habe ich mir ein mailfile ausgesucht ( Daos enabled, Traveler enabled ) und mit dem Resource Monitor von Windows überwacht ( Associated Handles )

Auf Server A sehe ich nach dem Start des Servers, daß der nserver & ntraveler prozess die Datei im Zugriff hat.
Auf Server B hat nur der nserver die Datei im Zugriff.

Wenn ich jetzt auf Server A ein compact -c ausführe, erhalte ich die bekannte Fehlermeldung.
Auf Server B kann ich den compact -c ohne Fehlermeldung durchführen.

Danach habe ich mit te traveler q den traveler process auf Server A beendet; jetzt kann ich auch hier den compact -c wieder durchführen ohne Fehlermeldung.

Nun zum DAOSMGR.

Auf Server B sehe ich in der Liste der associated handles immer nur den nserver prozess.

Auf Server A sehe ich neben nserver auch ntraveler und ndaosmgr, der die Datei permanent im Zugriff hat. Und da kommt der ncompact dann nicht mehr dran.

Wenn ich auf Server A sowohl den ntraveler als auch den ndaosmgr process beende, dann kann ich wieder ein compact ausführen.

Das gleiche Ergebnis erhalte ich auch mit DBMT; der kommt auch nicht mehr an die Datei ran. DBMT versucht zwar über ein DROP den belegte Handle freizubekommen. Das scheint aber nicht zu funktionieren.

Code

lo dbmt mail/ukrause.nsf

[1F58:0002-0A58] 23.05.2019 07:36:41   DBMT: Database Maintenance started:  mail/ukrause.nsf
[1F58:0002-0A58] 23.05.2019 07:36:41   Entry already in index
[1F58:0006-1A98] 23.05.2019 07:36:43 updating unread table d:\Domino\data\mail\ukrause.nsf for user 'CN=serv01/O=singultus'(1 out of 2)'
[1F58:0006-1A98] 23.05.2019 07:36:43 updating unread table d:\Domino\data\mail\ukrause.nsf for user 'CN=Ulrich Krause/O=singultus'(2 out of 2)'

[132C:0043-08B4] 23.05.2019 07:36:43   38 Transactions/Minute, 5 Notes Users
drop mail/ukrause.nsf

[1F58:0004-1720] 23.05.2019 07:36:49   Compacting mail\ukrause.nsf (Ulrich Krause),  mail/ukrause.nsf
[1F58:0004-1720] 23.05.2019 07:36:49   Compact of mail\ukrause.nsf failed: Database is currently in use by you or another user

[Manfred W.]

Hallo,

danke für's nachstellen.
Der Support hat es zwischenzeitlich auch nachstellen können und gibt es jetzt an die Entwicklung weiter.

Der Zustand ist auch nach über 12 Stunden nach dem DAOS Resync noch der selbe. D.h. die Standard-Timeouts scheinen hier alle nicht zu greifen.

Mir ist noch eingefallen, dass es vielleicht auch an der ODS Version liegen könnte (wir haben schon alle Datenbanken auf ODS53 aktualisiert). Aber das ist nicht der Fall. Bei ODS52 kann ich das selbe Verhalten nachstellen.

Das mit dem Traveler ist doch aber normal. Der hat ja immer die Datenbanken der Traveler User im Zugriff. Daher bekommst Du ja auch die Standard-Meldung "Database is currently in use by you or another user".
Ohne Traveler bekommt man aber nach dem DAOS Resync die Meldung "File is in use by another program".

[eknori]

Danke für die Info. Wenn es schon eskaliert ist, dann kann ich mir den PMR sparen. Hast Du schon eine SPR Nummer?

[Manfred W.]

Nein, hab noch keine SPR Nummer erhalten.

Das mit dem Traveler ist doch aber eigentlich normal, oder? Der hat ja immer die Datenbanken der Traveler User im Zugriff.

[eknori]

Das schon, aber auf dem 9.0.1er Server ist der compact -c möglich, auf dem 10er Server nicht

[Manfred W.]

SPR # GFALBCFAK3

[Manfred W.]

Hallo,

es gibt einen Hotfix für 10.0.1 ohne FP1 und mit FP1.
Werde ich gleich mal testen.

Und nochmal beim Support nachfragen, in welcher zukünftigen Version / welchem zukünftigen FP der Fix enthalten sein wird. Die Info hab ich nämlich noch nicht.

Grüße
Manfred

[eknori]

Das wird dann FP3 sein. Für FP2 ist es schon zu spät, glaube ich ...

[Manfred W.]

Also das Problem mit dem daosmgr ist mit HF29 behoben.
Nach einem resync lässt sich problemlos ein compact -c ausführen.

[eknori]

Allerdings nur das DAOS problem. Traveler hat die Datei nach wie vor im Zugriff ... 

[Manfred W.]

Na prima...

[eknori]

Problem mit Traveler habe ich als follow up zu deiner SPR# eingetütet

Code

Follow up to SPR# GFALBCFAK3<span style="white-space:pre-wrap;">
IBM Support - 27 May 2019, 16:01 PM CEST
Hello Mr. Krause,
 
This case has now reached the Traveler support team and has been assigne dto my colleague,
Declan Byrne which will review it shortly and contact you with his feedback.
 
Many Thanks,

[Manfred W.]

Na dann sollte da auch was vorwärts gehen.

Hier die Antwort vom Support bezüglich der zukünftigen Versionen:

Code

Hello Manfred,

Currently  the fix will be automatically included in Domino 11 based on the information I have from development.

It will not make it into 10.0.1 FP2 based on the information I have to hand at this time and for any potential feature packs for 10.0.1; So at this time you will need to request a new version of the hotfix when you upgrade to 10.0.1 FP2.

I'm writing a technote for the issue,so other customers and engineers have a potential reference point for the issue and will include the SPR identifier within the technote, but due to some internal changes it will be next week before it is published.

[Manfred W.]

Heute ist FP2 erschienen.
D.h. wir brauchen den Hotfix jetzt auch für FP2