Специально для таких случаев я разобрал ТОП3 проблем наших клиентов
https://wiki.ihor.ru/ispmanager:проблемы_с_активацией_лицензии
Ситуация крайне странная, по крайней мере потому, что Вы говорите о нескольких своих серверах. Я нашёл только один Ваш аккаунт в биллинге с одним сервером.
Но для бОльшего охвата хотелось бы узнать и о других проблеммных серверах.
Вы не могли бы в личку или в тикет сделать выборку времени ответа разных сайтов с разных серверов, чтобы можно было судить о проблеме и, возможно, обозначить фронт работ/проверки сотрудникам?
А вот теперь - нельзя. Обновление прошло успешно, но в 10:30 резко перестал быть доступен. Системные администраторы в курсе проблемы и приступили к устранению проблемы.
=
проблема устранена
Увы - да. Уже подключили специалистов ИСПсистем для выявления и исправления проблемы. Так как по факту всё должно работать как часы, но возникли магические проблемы.
Всё сделаем в лучшем виде. ;)
Спам откуда-то с вашего сервера
Помогу решить Вашу проблему обязательно. Почему Вы сутки не реагировали на этот запрос?
<..skip..>
Во вторник 27 декабря 2016 года в 22:00 запланировано обновление панели управления услугами BILLmanager. Работы продлятся около получаса. Всё это время https://billing.ihor.ru будет недоступен.
На работоспособность услуг не скажется.
Приносим извинения за возможные неудобства.
---------- Добавлено 24.12.2016 в 17:53 ----------
Рассказываю всю ситуацию.
В моей сборке образа CentOS-7-x86_64-ispmgr5 директория /tmp подключёна как tmpfs
Размер ему задаёт сама система на основании доступной ОЗУ.
на SSD Ferrum, который использовался у hostmasterx этот раздел равен 497 мегабайтам, у SSD Cuprum - 1001 мегабайтам.
При загрузке через файловый менеджер во временной директории /tmp создаётся временный файл
вида isptemp.<набор из7 случайных символов>, куда помещается загружаемый файл.
fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8b94bad000write(1, "Set-Cookie: ispmgrlang5=orion:ru"..., 4096) = 4096lstat("/tmp/isptemp.y2Ypt4", 0x7ffcb6b4e150) = -1 ENOENT (No such file or directory)write(1, "alue\" : \"\",\"fullwidth\" : true,\"h"..., 1360) = 1360close(3)
Поэтому на моём сервере в /tmp помещался файл в 600 мегабайт, а на сервере с меньшим разделом - нет.
Самое интересное или странное что при резервном копировании используется tmp-директория в /usr/local/mgr5/tmp и в любой другой работе панели - тоже.
Мой выбор /tmp как tmpfs трактовался и трактуется как снижение нагрузки на диск => увеличение скорости работы сервисов/сервера. К примеру тот же MySQL временные файлы скидывает в /tmp.
Извините, но Вы тоже не мгновенно отвечаете. Поэтому и получаются такие задержки в решении проблемы.
Если бы Вы ответили сразу, то блокировки бы не последовало. Тикет Ваш вижу и отвечу в течение пары минут.---------- Добавлено 24.12.2016 в 17:53 ----------
Вам будет действительно интересно узнать почему у Вас не получалось загрузить? Вариант решения проблемы от технической поддержки правильный, если Вы расчитываете на результат, а не на академические споры и изыскания корня проблемы.
Я обязательно перечитаю весь запрос и постараюсь создать стенд идентичный Вашему окружению для всесторонней проверки.
Не совсем понятно, почему Вы завели речь про техподдержку.
Образ CentOS-7-x86_64-ispmgr5 собирался мной из CentOS-7-x86_64-minimal + установка ISPmanager5 stable + изменения в конфигурационных файлах ПО, которые, как мне показалось, не соответствовали оптимальным.
Если у Вас есть конкретные вопросы или предложения по этому шаблону, то я готов выслушать, протестировать и внести корректировки.---------- Добавлено 24.12.2016 в 00:05 ----------
Сообщили об этом в отдел продаж.
PS: SSD Cuprum, шаблон CentOS-7-x86_64-ispmgr5. C помощью файлового менеджера загрузил в корень сайта файл чуть более 300 мегабайт, никаких проблем не возникло
