TYPO3 Core

Hi Henri,

• Operating System & version
• PHP version
• Webserver Type & Version
• Database Type & Version
• Database Connection Disposal (either 127.0.0.1, localhost, socket-based or remote database)

Thanks in advance for your feedback!

I was working on in standard Linux VM on my Windows Host. Local database and webserver. Settings special were

I did not build any symlinks - because of the evil host system -, but put the /typo3 and /vendor folders right there in the webroot.

It won't help much to tell you these specifics. I will try to reproduce the behaviour, debug it and give some more info then.

As I checked again, the hanging in step 4 (databaseData) is not specific to 7.6.1

I tried to debug this. As it hangs in step 4 databaseData it can be reproduced easily by dropping and rebuilding the database. In the StepController it runs outputSpecificStep() and checks for $needsExecution. That value is returned as true. But the tables are all in the database. Only the isInitialDatabaseImportDone configuration value read from the LocalConfiguration is still false.

The situation was reproducable and good for debugging. Then I added a sleep(5) in StepController->execute() in order to see the changing of the isInitialDatabaseImportDone value in LocalConfiguration through the several 303s. With that sleep-change the looping in step 4 suddenly broke. And I could not rebuild it again with 7.6.0/7.6.1. So that is why I stop here.

My best guess would be the two writes on LocalConfiguration at the end of DatabaseStep->execute() get somehow messed up. Sounds strange. But well, everything worked besides the write into the Localconfiguration. Probably one shouldn't just read/write every value by it's own.

Is TYPO3 installed in a synchronized file system directory? (Synchronized between VM and host)

Yes. See above.

Excuse I forgot to add me as watcher.

So, at first, does this issue still exist?

• I do not work in that environment any more and I have no time to reproduce it.
• It is questionable, if I could actually reproduce it.
• The situation it happened in probably is far off the generally applied deployment path / working environment.

So, please close.