Hi Dirk,
thank you for the workaround.
This is working.
Ok, I'm just publishing three updates for 5209R again:
- base-alpine: Various fixed regarding error-handling.
- base-apache: Fix to make sure the PHP settings no longer get lost.
- base-vsite: Fix in Vsite creation to make it
Hi Dirk,
This happens here in your logfile (I shortened the lines):
SET 315 . Disk quota = 400
SET 315.Disk failed (-2)
SET 315 . FTPNONADMIN enabled = 0
SET 315.FTPNONADMIN failed (-2)
SET 315 . SSL enabled = 0
SET 315.SSL failed (-2)
SET 315 . Shell enabled = 0
SET
Michael,
with the actual updates you crashed php at 5209R again.
I have to walk again over the servers and disable/enable php for the sites
again. Otherwise - only sourcecode instead of the website :(
Best regards,
Dirk
---
Black Point Arts Internet
Michael,
strange.
Not on all 5209R PHP was disabled again. Only on some (~ 40%).
Best regards,
Dirk
---
Black Point Arts Internet Solutions GmbH - Hanauer Landstrasse 423a - 60314
Frankfurt
Geschäftsführer
Tel.: +49.69952181 31
Fax: +49.69952181 41
Michael,
thank you for the workaround.
This is working.
Best regards,
Dirk
---
Black Point Arts Internet Solutions GmbH - Hanauer Landstrasse 423a - 60314
Frankfurt
---
-Ursprüngliche Nachricht-
Just in case I'm the canary in the mine today...
After today's YUM update, which carried some Apache / httpd payloads,
httpd failed to restart gracefully on its own. We saw this first with
a customer server, and then on all of our production hosting systems.
Restoring service is easy enough.
On 28/05/15 12:41, Chris Gebhardt - VIRTBIZ Internet wrote:
After today's YUM update, which carried some Apache / httpd payloads,
httpd failed to restart gracefully on its own. We saw this first with
a customer server, and then on all of our production hosting systems.
Can confirm that we
