Sieht danach wirklich so aus, als gäbe es hier ein IPC (interprocess communication) Problem
Danke jorgk3 - das tut meiner Informatiker-Seele gut! Ich hatte schon befürchtet, ihr wärt komplett "beratungsresistent" 
Nun können wir das OT Thema hier ruhen lassen.
Ich mach mal mit meinen Tests weiter, die Gene vorgeschlagen hatte...
Ich bin auch Informatiker (obwohl mit Abschluss als Diplom-Mathematiker), dazu der Maintainer von Betterbird (Du findest eine Menge zu mir im Netz). Aber zum (Off-)Thema: Die Prozesse kommunizieren natürlich untereinander, und es sieht ganz so aus, als würden dabei alle Mozilla-Prozesse in einen Topf geschmissen. Komisch. Wie ist es denn, wenn Du zwei FF-Instanzen startest, also `firefox -p` auf zwei verschiedenen Profilen. Machen die dann auch "Übersprechen"? Man könnte eine FF-spezifische env var setzen, um zu sehen, ob dann auch die andere Prozess-Familie mit dem Logging anfängt.
Wenn ich die Thematik hier richtig einordne, tritt das "Problem" und die somit aufgeworfene Sicherheitsfrage nur beim aktivierten Logging auf. Sehe ich dies richtig? Somit wären "normale" Anwender sowieso nicht betroffen?
tritt das "Problem" und die somit aufgeworfene Sicherheitsfrage nur beim aktivierten Logging auf
Würde ich jetzt so nicht unterschreiben.
Fakt ist, dass zwischen FF und TB kommuniziert wird.
Ich würde mal davon ausgehen, dass das nicht nur beim Logging der Fall ist. Es wird halt dort ersichtlich, weil Files kreiert werden.
Wie ist es denn, wenn Du zwei FF-Instanzen startest, also `firefox -p` auf zwei verschiedenen Profilen. Machen die dann auch "Übersprechen"? Man könnte eine FF-spezifische env var setzen, um zu sehen, ob dann auch die andere Prozess-Familie mit dem Logging anfängt.
das halte ich mir warm! Konzentriere mich aber vorab mal auf Gene's test cases zur send mail Problematik und bleibe daher noch etwas bei Pale Moon...
Aber das könntest du ja auch selbst testen, falls du Lust hast (und nen WindowsPC)
Ich würde mal davon ausgehen, dass das nicht nur beim Logging der Fall ist.
Ich würde dies schon vermuten, da für das Logging ja womöglich ein Prozess aktiviert wird, der aus dem gemeinsamen Mozilla-Code hervor geht.
da für das Logging ja womöglich ein Prozess aktiviert wird, der aus dem gemeinsamen Mozilla-Code hervor geht.
Gut möglich. Dagegen spricht allerdings, dass TB für logging keinen neuen Prozess startet. Es sind immer die gleichen 4 - mit oder ohne Logging:
stimmt ja gar nicht, was ich da erzähle: mit logging sinds 4 Prozesse, ohne aber 5!
Das soll mal einer verstehen...
Der Pale Moon kann wohl seine Herkunft nicht verleugnen - da habe ich nun schon gestaunt!
Nur 1 leeres File, ohne child und file extension, sonst aber ganz gem. MOZ_LOG_FILE!
Das zeigt, dass das Problem schon eine ganze Weile im FF/Mozilla Code sein muss.
Weiss jemand, wann Pale Moon den FF Code "geklaut" hat?
Aber das könntest du ja auch selbst testen, falls du Lust hast (und nen WindowsPC)
OK, FF Daily runtergeladen. In einem Fenster:
set MOZ_LOG=timestamp,rotate:200,nsHttp:5,cache2:5,nsSocketTransport:5,nsHostResolver:5,cookie:5
set MOZ_LOG_FILE=log.txt
firefox.exe -p
C:\temp\ff-daily\firefox>dir log.txt.*
Volume in drive C is OS
Volume Serial Number is E426-3423
Directory of C:\temp\ff-daily\firefox
17 Dec 2021 13:28 0 log.txt.child-1.moz_log.0
17 Dec 2021 13:28 4,131 log.txt.child-2.moz_log.0
17 Dec 2021 13:28 512,143 log.txt.child-3.moz_log.0
17 Dec 2021 13:28 8,256 log.txt.child-4.moz_log.0
17 Dec 2021 13:28 4,131 log.txt.child-5.moz_log.0
17 Dec 2021 13:28 4,131 log.txt.child-6.moz_log.0
17 Dec 2021 13:28 4,131 log.txt.child-7.moz_log.0
17 Dec 2021 13:31 12,958,155 log.txt.moz_log.0Dann denselben Daily in einem anderen Fenster noch einmal gestartet. Es kamen keine log file mehr dazu.
Interessant auch, im (Sysinternals) Process Explorer habe ich 8 Prozesse mit command line:
"C:\temp\ff-daily\firefox\firefox.exe" -contentproc --channel="2268.2.1558478544\265933177" -childID 1 -isForBrowser -prefsHandle 2964 -prefMapHandle 2960 -prefsLen 216 -prefMapSize 255430 -jsInitHandle 1360 -jsInitLen 280572 -parentBuildID 20211217035153 -appDir "C:\temp\ff-daily\firefox\browser" - 2268 "\\.\pipe\gecko-crash-server-pipe.2268" 2944 1dec3e68148 tab
Die gehören zur ersten Instanz. Die zweite Instanz hat statt 2268 eine 4456, und er noch dazu gestartete FF 91 ESR, den ich standardmäßig benutze, fährt mit 8425. Trotzdem produziert die erste Instanz aber nicht mehr log files.
Weiss jemand, wann Pale Moon den FF Code "geklaut" hat?
Geforkt. Unbekannt. Wenn sie das richtig machen, rüsten sie Sicherupdates nach. Und multi process ist schon "uralt", vor FF 57, also die dem multi process entgegenstehenden XUL-Add-ons abgeschaltet wurden.
Trotzdem produziert die erste Instanz aber nicht mehr log files.
scheint also im FF besser "isoliert" zu sein. Wie ist es denn, wenn du parallel einen TB mit logging startest?
Und multi process ist schon "uralt", vor FF 57
dann muss das vorher gewesen sein. Pale Moon fährt nur 1 Prozess (darum auch nur 1 logfile)
Installiert Dir mal: https://docs.microsoft.com/en-us/sysinter…rocess-explorer
Ich probiere das heute Abend mit TB/BB und FF, versprochen. Jetzt ab in die Sonne.
Danke, die SysinternalsSuite habe und schätze ich schon lange. Russinovich ist genial!
Aber klar, man sollte den natürlich auch benutzen! Dort sieht man ja, wer welches File alloziert
Viel Spass in der Sonne! Bei uns leider Nebel bei 3°
Benutzt Mozilla noch die NSPR für das Logging? Das wäre eine gemeinsame Komponente, die dann von beiden genutzt würde bzw. beide ansprechen kann.
MailNews:Logging - MozillaWiki
Und um es klarzustellen: Ich will hier nichts einfach so abtun. Ich halte es aber für sehr verfrüht, hier von einem dicken Sicherheitsproblem zu reden.
Also, 5crambler, schreib doch bitte mal auf, wie das Problem zu reproduzieren ist. Was mache ich falsch, oder richtig, dass ich das Problem nicht sehe. Das hier ist aus einem cmd window:
C:\temp\logging>set MOZ_LOG=IMAP:5,timestamp
C:\temp\logging>set MOZ_LOG_FILE=imap.log
C:\temp\logging>"C:\Program Files\Mozilla Thunderbird 91\thunderbird.exe" -p -no-remote
C:\temp\logging>dir imap.log*
Volume in drive C is OS
Volume Serial Number is E426-3423
Directory of C:\temp\logging
17 Dec 2021 17:49 0 imap.log.child-1.moz_log
17 Dec 2021 17:49 0 imap.log.child-2.moz_log
17 Dec 2021 17:49 0 imap.log.child-3.moz_log
17 Dec 2021 17:49 0 imap.log.child-4.moz_log
17 Dec 2021 17:49 0 imap.log.child-5.moz_log
17 Dec 2021 17:49 2,151,105 imap.log.moz_log
6 File(s) 2,151,105 bytes
0 Dir(s) 6,024,454,144 bytes free
C:\temp\logging>"C:\Program Files\Mozilla Firefox\firefox.exe" -p
C:\temp\logging>dir imap.log*
Volume in drive C is OS
Volume Serial Number is E426-3423
Directory of C:\temp\logging
17 Dec 2021 17:53 0 imap.log.child-1.moz_log
17 Dec 2021 17:53 0 imap.log.child-2.moz_log
17 Dec 2021 17:53 0 imap.log.child-3.moz_log
17 Dec 2021 17:53 0 imap.log.child-4.moz_log
17 Dec 2021 17:49 0 imap.log.child-5.moz_log
17 Dec 2021 17:53 0 imap.log.moz_log
6 File(s) 0 bytes
0 Dir(s) 6,008,221,696 bytes freeBevor ich FF im selben environment gestartet habe, hatte ich ihn noch von einem desktop shortcut gestartet. Beides hat keine zusätzlichen log files erzeugt.
Müsste eigentlich so klappen, wie du das gemacht hast, ausser dass ich FF und TB nicht im gleichen Environment starte, so dass die Variablen MOZ_LOG und MOZ_LOG_FILE eben für den FF nicht gesetzt sind.
Darum mein Script mit SetLocal, Variable setzen, Start TB, EndLocal.
In meinem Fall ist FF bereits up and running, wenn ich das TB-Script starte.
Die zusätzlichen Child-Files kommen aber nicht sofort, sondern erst nach und nach. Lass das mal ein paar Stunden so laufen und verwende dabei den FF und auch den TB. Schau dir die Timestamps meiner Files an, einige kamen erst nach 6 Stunden.
habt ihr diesen Thread aufgegeben?
"too hard" basket 
Da müsste man mal einen Bug anlegen ... der dann auch 20 Jahre liegen bleibt.
Das Logging ist sowieso Mozilla-Plattform-Zeug. Gibt es denn da auch "Übersprechen" zwischen (z.B.) zwei FF-Instanzen? Da gibt es auch einiges logging, das man einschalten kann.