а кстати. у меня такая же фигня. скрипты не создаются. это после переезда с версии 1.0 на 1.4
Скриптов в /opt/etc/cron.1min кроме ados.sh нет и не появляется.Появляются ли скрипты в /opt/etc/cron.1min?
Содержимое error.log:Что пишется в /opt/var/log/lighttpd/error.log?
Мне очень не нравится строка #4. Или это нормально?Code:2007-08-14 00:54:36: (log.c.75) server started 2007-08-14 02:08:00: (log.c.135) server stopped 2007-08-14 02:09:06: (log.c.75) server started 2007-08-14 02:29:59: (mod_fastcgi.c.2551) FastCGI-stderr: PHP Warning: Division by zero in /opt/share/www/ados/sections/section_download.php on line 687 2007-08-14 16:21:31: (log.c.135) server stopped 2007-08-14 16:21:33: (log.c.75) server started
Нет, а почему запущенных процессов php-fcgi аж 8 штук?Память "жрется" только в момент подключения через web-интерфейс. Если из него выйти, то все будет нормально.
а кстати. у меня такая же фигня. скрипты не создаются. это после переезда с версии 1.0 на 1.4
Это, конечно, не нормально. Но в нормальной ситуации такой строки и не будет.
Деление на ноль происходит из-за нулевого размера файла. То есть, получается, что скачивается файл с нулевым размером.
Тоже хороший вопрос. Попробуй остановить и снова запустить сервер и PHP и посмотри, когда появляются лишние процессы.
Смотри лог ошибок. Все описания ошибок, связанных с закачками, мной уже написаны и заносятся в лог. Поэтому если барахлит скрипт, то будет запись в логе.
И я недеюсь, что ты не забыл заменить файлы модуля для axel'я, о которых я говорил?
Last edited by DINI; 14-08-2007 at 20:20.
Здравствуйте, уважаемый DINI!
Давно искал интерфейс, подобный Вашему ADOSу для установки на сервере под управлением FreeBSD.
Посмотрев системные требования и доустановив необходимое, попробовал его в деле.
Интерфейс, как ни странно, заработал с полпинка :-)
Однако, есть такая проблема.
Закачка создается, cron отрабатывает, логи пишутся, файл сохраняется в во временный каталог _tmp с расширением .ados. Однако, после окончания закачки он не переносится в нужный каталог. В логе закачки в это время все ОК, тоесть закачка 100%.
В интерфейсе при этом статус закачки "Закачивается".
Такое впечатление, что движок не совсем верно отслеживает окончание закачки axelем. Насколько я могу судить, используются номера запущенных процессов axel, и команда ps. А ее вывод может быть разным для разных систем.
Что можно предпринять или где посмотреть в данной ситуации?
Могу предложить скромную помощь в отладке Вашего ПО для FreeBSD, если есть такая необходимость.
Честно говоря, писался скрипт именно под Линукс, однако его достаточно легко можно оптимизировать для работы как под Windows, так и под Unix-подобные системы.
Определение окончания закачки действительно происходит посредством выполнения команды ps и анализа возвращенного результата. Однако идентификаторы закачек используются непосредственно при скачивании файла для обновления информации о его текущем состоянии.
После окончания скачивания процессы, инициализированные axel'ем, завершаются, и именно по отсутствию этих процессов скрипт определяет, что закачка завершена.
В вашем случае я советую посмотреть записи в файлах _log/cron_end_download.log и _log/cron_schedule.log.
Правда это может быть и баг axel'я: если в папке _tmp при 100% загрузке помимо файла с расширением .ados также находится файл с аналогичным именем, но имеющий расширение .ados.st, то это и есть тот самый баг. Почему-то axel не всегда докачивает файл до конца, оставляя недокачанными всего-лишь несколько байт. При этом в логе закачки значится 100%.
Решением здесь является пауза и повторный запуск закачки. А по поводу исправления бага надо обращаться к автору axel'я.
К сожалению, полноценная отладка пока невозможна, т.к. необходимо написать тексты ошибок, которые будут добавляться в лог. На это нужно время, которого у меня, увы, очень мало. Поэтому пока не могу точно сказать, когда будет готова версия для полноценного тестирования и отладки.
Тем не менее, спасибо за ваше предложение!
"Этого быть не может, потому что не может быть."©То есть, получается, что скачивается файл с нулевым размером.
Я качаю файл с сервака локальной сетки провайдера. Просто так axel'ем он качается, размер не нулевой. Я пробовал даже скачать картинку со стартовой страницы Firefox, не скачалось.
Сразу же. Я делаю killall lighttpd и killall php-fcgi, потом запускаю S80lighttpd start, и они появляются сразу же. Быть может, мне стоит удалить все файлы из папки /opt/share/www кроме папки с ados (там ещё есть lighttpd, images, cgi-bin)?Тоже хороший вопрос. Попробуй остановить и снова запустить сервер и PHP и посмотри, когда появляются лишние процессы.
У меня тоже 8 штук php-fcgi....
Полазил в инете и вычитал, что нужно добавить в lighttpd.conf в секцию fastcgi.server такие строки:
теперь ps показывает 2 процесса php-fcgi (почему два, тоже неясно, но не восемь же! )Code:"min-procs" => 1, "max-procs" => 1, "max-load-per-proc" => 4,
Однако, мою проблему это не решает, по прежнему в логе пишет
системный лог ни о каких проблеммах не сообщает. Мне так и не удалось скачать с помощью этого чудо скрипта ни одного файла...Code:(mod_fastcgi.c.2551) FastCGI-stderr: PHP Fatal error: Maximum execution time of 90 secon ds exceeded in /opt/share/www/ados/classes/class_engine.php on line 1710
Всем, у кого возникли проблемы, я еще раз сообщаю: я не могу подъехать к вам, чтобы лично проследить, откуда возникают ошибки. Поэтому вам придется дожаться того момента, когда я добавлю тексты ошибок для записи в лог. Только после этого с помощью лога скрипта можно будет узнать причины ошибок. Пока же я могу лишь тыкать пальцем в небо.Я пробовал даже скачать картинку со стартовой страницы Firefox, не скачалось.
Тем не менее, при правильной установке скрипт полностью работоспособен, т.к. он прекрасно работает у меня и у моих знакомых, которые также установили себе мой скрипт, следуя инструкциям.
В файле _log/cron_schedule.log следующего вида записи:В вашем случае я советую посмотреть записи в файлах _log/cron_end_download.log и _log/cron_schedule.log.
Файл _log/cron_end_download.log не появился. А вот логи закачки от самого axelя имеются с ссответствующими именами типаCode:... /usr/local/www/data/html/classes/class_cron.php /usr/local/www/data/html/classes/class_cron.php /usr/local/www/data/html/classes/class_cron.php ...
3c60c2a1b2b88d831d04e5e8dcc72fd0.log
Все файлы, что качались, закачались полностью до последнего байта, файлов .ados.st после окончания не наблюдал.Правда это может быть и баг axel'я: если в папке _tmp при 100% загрузке помимо файла с расширением .ados также находится файл с аналогичным именем, но имеющий расширение .ados.st, то это и есть тот самый баг. Почему-то axel не всегда докачивает файл до конца, оставляя недокачанными всего-лишь несколько байт. При этом в логе закачки значится 100%.
Пожалуйста! :-)Тем не менее, спасибо за ваше предложение!
И спасибо за Вашу работу!
спасибо, будем ждать!
Внимание: вышел пятый билд беты скрипта.
См. обновленные ссылки в первом посте темы.
Для обновления необходимо заменить файлы на сервере файлами из архива. Файлы lang/ru/module_axel.lng и modules/module_axel.php необходимо заменить соответствующими файлами из архива install/ados_module_axel_1.0.0.tar.gz
Добавлено:
- Коды и описания ошибок для классов управления закачками и модуля axel.
Обновлено:
- В окне описания события журнала помимо прочего теперь также выводится код события.
Исправлено:
- Вывод советов по устранению ошибок в окне описания событий в журнале (ранее вместо советов выводилась лишь пара ничего не значащих символов).
- Waitbar (небольшой gif'чик с анимацией, появляющийся во время ожидания ответа от сервера) располагается строго по центру окна независимо от положения страницы в окне (ранее waitbar появлялся по центру окна только в том случае, если просматривался самый верх страницы). После обновления файлов на сервере нажмите Ctrl+R в браузере, чтобы обновить кэш со скриптами и увидеть изменения.
Добрый день !
Хочу выразить свою благодарность Уважаемому DINI ! Ваш труд заслуживает похвалы Вы молодец !
По делу. Установка ados у меня заняла около 2-х часов - причина невнимательное чтение инструкция и непонятки с php-fgci (нехватало 2х пакетов не указанных в инструкции), но это ерунда. Волнует такой момент в списке процессов висит 8 процессов /opt/bin/php-fcgi, один из которых занимает 14 мегабайт (остальные <1 мб). Как Вы упоминали ранее кол-во процессов должно б уменьшится при закрытии Веб интерфейса... но этого не происходит. Разъясните пожалуйста, это нормальная ситуация ?
Asus WL500GP + Zyxel 660RT + 500 GB HD501LJ in VPA-35018 case
Спасибо!
Вы опять невнимательны: я нигде не говорил о том, что после закрытия скрипта должно уменьшиться количество процессов php-fcgi. Однако dimaka написал, как можно изначально уменьшить количество этих процессов.Как Вы упоминали ранее кол-во процессов должно б уменьшится при закрытии Веб интерфейса... но этого не происходит. Разъясните пожалуйста, это нормальная ситуация ?