Сообщение all threads completed succeed 0 failed 0 в логе программы, работающей с данными OpenStreetMap (загрузчики тайлов, конвертеры карт, утилиты обработки дампов), означает, что все рабочие потоки завершились, но при этом не было успешно обработано ни одной задачи — и не было ни одной ошибки. Нули в обоих счётчиках — ключевой симптом: программа не упала и не сломалась, она просто не получила ни одного задания в очередь. Файлы на выходе при этом обычно отсутствуют или имеют нулевой размер.
Такая ситуация типична для многопоточных утилит, обрабатывающих списки тайлов, регионов или пакетов данных: загрузчик стартует, создаёт пул потоков, потоки опрашивают очередь задач, находят её пустой и корректно завершаются. Итоговая строка в логе выглядит обманчиво «успешно», потому что слово completed воспринимается как признак выполненной работы. На деле это отчёт о холостом проходе.
Что на самом деле означает строка в логе
Разберём сообщение по частям. All threads completed — все потоки пула дошли до конца своего цикла. Succeed 0 — счётчик успешно обработанных элементов равен нулю. Failed 0 — счётчик ошибок тоже нулевой. Комбинация «0 и 0» исключает сетевые сбои, битые файлы и проблемы с правами записи: если бы задачи запускались и падали, счётчик failed был бы больше нуля.
Логика многопоточных обработчиков устроена так: основной модуль формирует очередь заданий, потоки забирают их по одному. Если очередь пуста с самого начала, потоки завершаются мгновенно, а итоговый отчёт показывает именно те нули, которые вы видите. Следовательно, искать причину нужно не в потоках и не в сети, а на этапе формирования списка задач — до запуска обработки.
Основные причины пустой очереди задач
Практика работы с OSM-утилитами показывает несколько типовых сценариев, при которых список заданий оказывается пустым. Проверять их стоит именно в этом порядке — от самых частых к более редким.
- 🗂️ Неверный путь к входным данным — файл списка тайлов, дамп .osm / .pbf или каталог с исходниками не найден по указанному пути, и программа молча работает с пустым набором.
- 🔍 Слишком строгие фильтры — заданные границы региона (bbox), диапазон масштабов (zoom) или условия отбора не пересекаются с реальными данными, и после фильтрации не остаётся ни одного элемента.
- 📄 Пустой или битый файл списка — входной список задач существует, но содержит ноль строк, лишние служебные символы или данные в неожиданном формате, которые парсер тихо пропускает.
- ⏭️ Режим пропуска существующих — если включена опция «не скачивать уже имеющиеся файлы», а все целевые файлы уже есть на диске, очередь законно окажется пустой.
- ⚙️ Ошибка в конфигурации — параметр с опечаткой проигнорирован, и программа запустилась с настройками, при которых задач нет.
Обратите внимание: большинство таких утилит не считают пустую очередь ошибкой и не завершаются с ненулевым кодом возврата. Поэтому автоматические скрипты, проверяющие только код завершения, могут «не заметить» проблему.
Пошаговая диагностика
Начните с самого простого — проверки входных данных. Откройте файл или каталог, который вы передали программе, и убедитесь, что он существует, не пуст и читается. Если путь задан относительно, проверьте рабочую директорию, из которой запускается утилита: относительные пути — частый источник «невидимых» файлов.
Далее проверьте параметры запуска. Временно уберите или расширьте фильтры: увеличьте охват региона, снимите ограничения по масштабу, отключите режим пропуска существующих файлов. Если после этого счётчик succeed стал ненулевым — причина найдена, оставалось слишком жёсткое условие отбора.
☑️ Диагностика нулевых счётчиков
Повысьте детализацию журнала, если утилита это поддерживает (обычно это флаг вида -v или --verbose, но точное имя смотрите в справке вашей программы через --help). Подробный лог часто показывает этап, на котором задачи отбрасываются: «0 items matched filter», «input file empty» и подобные строки.
your-osm-tool --input tiles.txt --verbose
⚠️ Внимание: не запускайте повторную полную загрузку большого региона «наугад», пока не нашли причину. Массовое скачивание тайлов с публичных серверов OpenStreetMap регулируется правилами использования, и агрессивные повторные запросы могут привести к временной блокировке вашего IP.
Типовые сценарии и их решения
Сведём частые ситуации в таблицу — так проще сопоставить симптом с действием.
| Симптом | Вероятная причина | Что сделать |
|---|---|---|
| succeed 0 failed 0, лог пустой | Не найден входной файл | Проверить путь и рабочую директорию |
| succeed 0 failed 0, в логе «0 items matched» | Фильтры отсекли все задачи | Ослабить bbox/zoom/условия отбора |
| succeed 0 failed 0, файлы уже на диске | Режим пропуска существующих | Удалить старые файлы или отключить skip |
| succeed N failed 0 | Штатная работа | Ничего, всё в порядке |
| succeed 0 failed N | Задачи есть, но падают | Смотреть ошибки конкретных потоков в логе |
Последние две строки таблицы важны для понимания: ненулевой failed — совсем другая история, связанная с сетью, правами доступа или повреждёнными источниками. А вот нулевой failed при нулевом succeed практически всегда указывает на пустой вход.
Если сообщение появляется в собственном скрипте
Когда строку выводит ваш собственный код на Python, Bash или другом языке, диагностика упрощается: добавьте вывод размера очереди задач перед запуском потоков. Одна строка логирования вида print(len(tasks)) сразу покажет, формируется ли список вообще.
Также проверьте типовые ошибки в коде: чтение файла с неверной кодировкой, регулярное выражение, не совпадающее ни с одной строкой, условие if, которое всегда ложно. В многопоточном коде встречается и гонка: потоки стартуют раньше, чем очередь успевает заполниться. В таком случае помогает заполнение очереди до создания пула потоков.
Почему программа не считает пустую очередь ошибкой
С точки зрения разработчика утилиты пустая очередь — штатная ситуация: например, при инкрементальном обновлении карт отсутствие новых тайлов означает, что всё уже актуально. Поэтому потоки завершаются корректно, код возврата нулевой, а интерпретация результата остаётся на пользователе.
Как не допустить повторения проблемы
Чтобы нулевой результат не проскакивал незамеченным, встройте в рабочий процесс простые проверки. Они занимают минуты, но экономят часы холостых прогонов.
- ✅ Проверяйте итоговые файлы — после завершения смотрите, появились ли ожидаемые данные и имеют ли они разумный размер.
- 📊 Контролируйте счётчик succeed — если скрипт автоматический, добавьте проверку: succeed равен нулю → завершение с ошибкой и уведомление.
- 🧪 Тестируйте конфигурацию на малом объёме — прежде чем обрабатывать целый регион, прогоните один тайл или один небольшой участок.
- 📝 Сохраняйте полные логи — по ним всегда можно восстановить, на каком этапе задачи отфильтровались.
⚠️ Внимание: если вы используете стороннюю утилиту и не можете найти нужный параметр, ориентируйтесь на её официальную документацию и вывод команды помощи. Названия флагов и поведение опций различаются между программами и версиями, поэтому не копируйте параметры из чужих примеров без проверки.
Часто задаваемые вопросы
Значит ли succeed 0 failed 0, что загрузка прошла успешно?
Нет. Нулевой failed говорит лишь об отсутствии ошибок, но нулевой succeed означает, что ни одна задача не была выполнена. Фактически программа ничего не сделала — проверяйте, появились ли ожидаемые файлы на диске.
Почему нет сообщения об ошибке, если ничего не загрузилось?
Большинство многопоточных утилит считают пустую очередь допустимой ситуацией, а не сбоем. Потоки корректно завершаются, программа возвращает нулевой код выхода, и единственный признак проблемы — нули в итоговой статистике.
Может ли причина быть в блокировке со стороны сервера OSM?
При блокировке или сетевых проблемах задачи обычно запускаются и завершаются с ошибкой — счётчик failed растёт. Комбинация «0 и 0» указывает именно на отсутствие задач, то есть на локальную причину: пути, фильтры или пустой входной файл.
Что делать, если входной файл на месте, а очередь всё равно пустая?
Проверьте содержимое файла: он может быть пустым, в неверной кодировке или с форматом строк, который парсер не распознаёт. Откройте файл в текстовом редакторе и сравните структуру с примерами из документации вашей утилиты. Запуск с флагом подробного логирования также помогает увидеть, сколько элементов было прочитано.
Как автоматически отловить такую ситуацию в скрипте?
Разбирайте итоговую строку лога или итоговые переменные программы: если значение succeed равно нулю при ожидаемой ненулевой работе, завершайте скрипт с ненулевым кодом и пометкой о пустой очереди. Это надёжнее, чем проверка только кода возврата самой утилиты.