12 Replies Latest reply on Feb 12, 2019 10:46 AM by SitzRieSe

    OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist

    System32 Apprentice

      Hallo

       

      Jemand von euch mal auf eure DSM geschaut seit einem 2018.1.2 Update? Unter 2017.1 hatten wir das noch nicht aber seit dem Update müllen unsere DSM Server ihre C:\ Platte zu 100% zu mit lauter *.zip Dateien im Ordner:

       

      C:\Program Files (x86)\Common Files\enteo\NiLogs\Distribution\%Servername.OSD% [Depot,66404]\zip

       

      Un das sieht dann so aus und geht immer weiter bis die HDD voll ist:

       

      In den *.zip selber sind immer Dateien mit dem Namen z.B.:

       

           JobQueue_Packages_66404_SYSTEM_AGG.log

       

      Drinnen steht dann lustiges Zeug was ich aus Datenschutz Gründen hier nicht posten kann aber eine "failure" Meldung wiederholt sich darin regelmäßig:

       

      13:15.20.798  0          FPS.dll  Current activity for this file transfer is 'Normal activity'. 100% of available bandwidth is used.
      13:15.20.819  2          FPS.dll  CRC mismatch between source file and the CRC in the FPI (4009740916 != 4169645790)
      13:15.20.819  2          FPS.dll  CRC mismatch between source file and the CRC in the FPI. File in the destination is deleted.
      13:15.20.821  E Warning (Module:mgmtagnt.exe, Severity:0x03):          FPS.dll  Failed to copy file 'Extern$\sources\background_cli.bmp'.

      A CRC error occured in a source file. (0xe009000d)

      13:15.20.822  E Warning (Module:mgmtagnt.exe, Severity:0x03):          FPS.dll  Severe failure while trying to get up to date (step 0):

      A CRC error occured in a source file. (0xe009000d)

       

      oder..

       

      13:15.28.638  0          FPS.dll  'extern$\Fonts\_NI5.zip' does not exist in the source
      13:15.28.639  E Warning (Module:mgmtagnt.exe, Severity:0x03):          FPS.dll  Severe failure while trying to get up to date (step 0):

      The system cannot find the file specified. (0x00000002)

       

       

      Und die betrifft immer verschiedene Project ID von verschiedenen Paketen am Master Depot.

        • 1. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
          FrankScholer Master

          Hi,

           

          wie ich hier (Server läuft voll mit distibution logfiles) schon geschrieben hab, passiert das unter DSM 2018.1 immer dann, wenn es eine Inkonsistenz zwischen DB und Dateisystem gibt bzw. wenn das Dateisystem "korrupt" ist. Wie du ja in den JobQueue_Packages-Logs bereits gefunden hast, stimmt wohl die Checksumme nicht mehr mit der im File Package Index (FPI)-File überein. Warum auch immer! Ich fürchte, du musst für die ganzen betroffenen Pakete nochmal die Distribution vorbereiten, damit die Checksumme neu berechnet und das FPI-File neu geschrieben wird...

           

          Ich würde aber auch hinterfragen, wie die Checksumme korrupt werden kann / woran es liegen kann, dass die nicht mehr passen? Virenscanner der die Files ggf. "touched"? Teilweises aber nicht vollständiges Restore eines älteren Backups? Was auch immer? Weil das Problem soll ja nicht in kürze womöglich wieder auftreten.

           

          HTH, Grüße Frank

          • 2. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
            System32 Apprentice

            Guten Morgen Frank! Vielen Dank, das könnte die richtige Spur sein, wie bekomme ich heraus welche der 17.000 Pakete betroffen ist Schreit nach einer SQL Suchaktion mit anschließenden Push über ein Script ?

             

            Restore von einem Backup kann ich ausschließen, Virenscanner ist eine gute Frage, ich versuche mal mehr heraus zu bekommen.

             

            LG

            • 3. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
              MPockr1 Rookie

              Wir haben leider auch auf 2018.1.2 aktualisiert, wenn ich könnte würde ich wieder downgraden da 2018.1.3 auch nur teilweise hilft.

              Leider sind die Bugs so versteckt das diese erst nach dem Rollout auf 700+ Managementpoints aufgefallen sind da unsere DEV und QAS zu klein sind ..

               

              Case 01502351

              A) (Defekte Revisionen) Bislang wurden zur "Lösung" von defekten Paketen eine neue Revision angelegt und die Warnung 1x alle Stunde ignoriert, nach dem Update laufen die Server quasi in einer Endlosschleife.

               

              Workaround: defekten Pakete löschen und neu replizieren

               

              B) Paket-Installationen scheitern da die Paket-Checksummen nicht rechtzeitig in der Datenbank aktualisiert werden, da das Backend mit Distribution-Messages überflutet wird. (Konsole und package.fpi.checksum weichen von einander ab)

               

              Workaround: keine Pakete kopieren und beim import auf korrekte Checksumme achten.

               

              C) Managementpoints ignorieren definierten Pollingintervalle ihrer Site

               

              D) Der Core-Service der Managementpoints (mgmtagnt.exe) gibt keinen Arbeitsspeicher frei. Bei knapp 4 GB melden diese dann im Distribution\Site\Packages_* kontinuierlich folgende Meldung bis der Core-Service neu gestartet wird.

              Warning (Module:mgmtagnt.exe, Severity:0x03): eRepLib.dll No more threads can be created in the system. (0x000000a4): Distribution definition cannot be retrieved.

               

               

              B und D scheinen mit 2018.1.3 behoben zu sein - sind aber auch erst in der DEV am testen, .. dies mal genauer ..

              • 4. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                Vito Apprentice

                Hi,

                 

                wir haben ähnliche Umstände in unserer Umgebung, seit wir auf DSM 2018.1 sind (A, B, C ). D noch nicht beobachtet.

                Hat jemand bereits Erfahrungen mit dem neusten DSM Build (https://community.ivanti.com/docs/DOC-72274) ?

                Wir überlegen uns das Update durchzuführen, da es ja ein paar Fehler beheben soll

                 

                Aktuell habe ich das Problem, dass wieder mega viele Logs im BLS geschrieben werden, weil längst gelöschte Packete wieder oder noch als "ToDelete" anstehen.

                Kennt das jemand?

                 

                eRepLib.dll    Moving directory '205743' to 'todelete.140841-16012019.205743' to mark it for deletion.

                E Warning (Module:mgmtagnt.exe, Severity:0x03): FPS.dll    Failed to move '\\?\UNC\virt-heatbls\enteo$\Install\Master\Projects\205743' to '\\?\UNC\virt-heatbls\enteo$\Install\Master\Projects\todelete.140841-16012019.205743'.

                The system cannot find the file specified. (0x00000002)

                E Warning (Module:mgmtagnt.exe, Severity:0x03): eRepLib.dll    The system cannot find the file specified. (0x00000002): Failed to mark package for deletion.

                 

                Wenn ich einen Ordner (\?\UNC\virt-heatbls\enteo$\Install\Master\Projects\205743) anlege, dauert es keine 10 Sekunden und dann habe ich den "todelete.140841-16012019.205743".

                Leider scheint es gerade gefühlt tausende solcher Fehler im Sekunden Takt zu schreiben zu unterschiedlichen Packeten.

                 

                Muss ich nun für jeden Fehler im Log einen Ordner anlagen, damit dann der toDelete Ordner angelegt wird?

                 

                System32

                Das mit den vielen *.zip-Dateien in JobQueue_Packages_66404_SYSTEM_AGG.log habe ich auch seit dem Update.

                Das ist dann irgendein Packet das an dem entsprechenden Depot nicht distrbuiert werden kann.

                2019-01-16_15h59_14.png Als ich diese Fehler gelöst hatte haben auch die JobQueue Logs ein Ende gehabt

                 

                 

                Gruß

                Vito

                • 5. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                  KaiNitzsche Apprentice

                  Hallo zusammen,

                   

                  wir haben dummerweise vor ein paar Wochen auch auf die 2018.1.2 aktualisiert und seitdem große Performance-Probleme auf dem BLS. Die CPU- und RAM-Auslastung ist dauerhaft ziemlich hoch, der Paket-Download von Clients läuft sehr langsam und auch das zuweisen oder entfernen von Policies auf eine größere Anzahl Clients dauert gefühlt ewig, die Distribution natürlich auch. Der Reboot des BLS hilft mal für einen Tag, aber nicht auf Dauer.

                  Kennt jemand das Problem und hat eine Lösung? Update auf die 2018.1.3?

                   

                  BLS.png

                   

                  Danke Euch Kai!

                  • 6. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                    MPockr1 Rookie

                    FYI, wir wurden heute von Ivanti telefonisch kontaktiert ..

                     

                    Problem A) Distribution-Service spammt Festplatte bei defekten Paketen voll:

                    Case 01539358

                    es gibt einen inoffiziellen hotfix (neue eRepLib.dll) mit Benutzung auf eigene Gefahr.

                     

                     

                    Problem C) Managementpoints ignorieren definierten Pollingintervalle ihrer Site

                    Case 01539366

                    Dieses Verhalten ist "as design".

                     

                    Sobald der Wert auf 0 gestellt wird, ist die Distribution deaktiviert.

                    Jeder Wert ungleich 0 wuerde bedeuten das die Distribution aktiviert wurde und das Polling von einer Minute greift.

                    • 7. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                      Nico Schmidtbauer Specialist

                      Da ich heute beim Update der letzten und ältesten DSM Umgebung (gibt es seit enteo v6 RTM) genau auf das Problem gestoßen bin... nochmal meine 5 cent dazu. Franks Ansatz ist korrekt.

                      C:\Program Files (x86)\Common Files\enteo\NiLogs\Distribution\---DEPOT---\JobQueue_Packages_xxxxx_AGG.log ist da entsprechende Logfile dazu. Suche nach "failed"

                      Ich hatte sowohl auf dem Master BLS, als auch auf 4 von 12 Site Servern das Problem mit der CPU Auslastung.

                       

                      War eine fleißaufgabe, aber ich hab das Log durchgearbeitet. Dabei sind mir unterschiedliche Pakete / Problme aufgefallen:

                      - 4 SYSTEM Pakete bzw. Templates (Linux Boot Env, Dos Boot Env., ein Partiton Paket und nochmal eines) machten Probleme dort ist irgend eine Zwischenrevision in der Vergangenheit mal vermutlich madig repliziert worden. Lösung => Aus den Work Ordnern der BLS löschen...

                      - Ein paar Pakete hab ich selbst gelöscht (weil nicht mehr benötigt)

                      - Ein Paket war recht interessant. Das war wohl mal per RunEScript eingebunden und lies sich nicht löschen... da hat dann irgendjemand mal einfach die Massendaten rausgelöscht und auf Prepare Package gedrückt. Das hat ebenfalls ein Problem verursacht.

                       

                      Manche Pakete (z.B. die Systempakete) sind in den Logs jetzt nicht unbedingt sprechend im Log aufgetaucht. Die habe ich mir dann per ProcMon auf dem DSM Server / Depot rausgesucht... dort nach dem mgmtagnt.exe Filtern und schauen in welchen Paketverzeichnissen er alle 0,5 Sekunden rumsucht.

                       

                      Ich mach an der Stelle dann doch lieber Vergangenheitsbewältigung und schmeiß defekte Pakete raus / korrigier sie, als nen "use on own risk" Hotfix zu benutzen

                      • 8. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                        MPockr1 Rookie

                        Ja korrigieren ist richtig, aber die Chance das auf einen von über 700 Managementpoints irgendwo irgend eine Datei von den knapp 1 TB an Paketen vom Virenscanner gefressen (oder sonstiges) wird und die OS Platte vollmüllt ist mir zu hoch.

                        (Merkt man ja wenn das Paket nicht installiert ..)

                         

                        Der "use on own risk" Hotfix läuft übrigstes sehr gut.

                        • 9. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                          Andreas.Jahnke SupportEmployee

                          Hallo Zusammen,

                           

                          der "use on own risk" fix sollte, wie von Herrn Pockrandt geschrieben, dieses Verhalten korrigieren.

                          Als Anmerkung:

                          Der Fix wurde selbstverstaendlich von unserer Entwicklung getestet.

                          Da allerdings bei einem Fix (einzelne dll Datei) der QA Prozess umgangen wird, muss ich hier aus legalen Gruenden darauf hinweisen.

                          Dieser fix wird auch offiziell in die DSM 2019.1 implementiert werden.

                          Da es sich bei dem Fix nur um den Austausch einer dll handelt, kann in einem Fehlerfall auch auf die Original-dll wieder zurueck gegriffen werden.

                          Vielen Dank.

                           

                          Viele Gruesse,

                          Andreas Jahnke

                          • 10. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                            SitzRieSe Expert

                            Hallo Herr Jahnke,

                             

                            gibt es ein ungefähres Releasedatum von 2019.1 welches Sie kommunizieren können? Mein letzter Stand war 1. Quartal.

                             

                            Gruß

                            • 11. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                              Andreas.Jahnke SupportEmployee

                              Hallo Herr Pelz,

                               

                              wir versuchen DSM 2019.1 bis mitte Maerz zur Verfuegung zu stellen.

                              Ich hoffe das hilft Ihnen weiter.

                               

                              Viele Gruesse,

                              Andreas Jahnke

                              • 12. Re: OSD Server werden seit Update 2018.1.2 mit Logs zugemüllt bis C:\ Platte voll ist
                                SitzRieSe Expert

                                Kann bei der Identifikation von defekten Paketen nicht das DSM Web helfen? Habt ihr da mal geschaut?

                                 

                                 

                                Gruß

                                 

                                Alex