Hi Xavier,
thanks for your response. I did understand very well not to restart the
whole monster :-).
I did those update/downgrade tests within a university infrastructure,
where there is one php that serves many virtual hosts (it's a
Redheat/CentOS distribution). It is not just that simple to initiate a
php daemon restart, simply because there might quite likely be a course
on Moodle going on, which then would most certainly experience
interruptions (wouldn't be the first time).
And still, when it comes to shared hostings, the solution presented here
needs shell access, which many people just don't have.
So eventually I still wonder, why there where some 30 upgrades and
nothing alike happened (at least I didn't read anything - please correct
me, when I am wrong!), and now those problems arise. As for the
university, the php infrastructure didn't see a change in a php major
version in over 4 years (I probably shouldn't say that, but, well, here
it is...), so I wouldn't blame php...
...just thinking out loud...
Have a nice day!
Robert
Markus did not suggest to restart the *whole server*, but the *PHP
server* (as he explained, to clear the PHP opcode cache). This typically
means:
$ sudo /etc/init.d/php-fpm restart
or
$ apache2ctl graceful
(PHP-fpm or mod-php5)
and of course not a complete reboot of the server itself. Of course,
even that may be problematic for you or for someone using a shared
server. But the whole point is actually to clear the opcode cache, so if
you cannot afford doing that, you have to find out how to clear the
opcode cache differently. You can search on Google or read the TYPO3
code to see how it does when an extension is installed in 6.2.
By using search terms "clear opcode cache" you'll see that for instance
if using APC:
http://stackoverflow.com/questions/911158/how-to-clear-apc-cache-entries
HTH
Xavier
_______________________________________________
TYPO3-english mailing list
TYPO3-english@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
