Какой памяти не хватает wget?

У тебя наверно какой-то хитрый btrfs вместо файловой системы?

32 бита?

Можешь дать ссылку для проверки?

Оперативной. Вангую дешёвый хостинг с оверселлингом.

Два раздела: своп и ext4 под корень.

Это интрасеть, так что ссылку дать не могу.

Сервер свой: и виртуальный, и физический. И там, и там debian stretch.

Странно тогда. Ну помониторь загрузку памяти в процессе, попробуй strace. Но если интерес не чисто академический, то используй curl вместо wget.

Глюки wget, возможно. Попробуй заюзать curl.

у меня такое было с /tmp в ram

tmp на раздел монтируется.

попробуй wget с --verbose, может расскажет поподробнее

Глянь, нет ли квот или ограничений на /tmp. Не на fat32 качаешь?

Нет ничего. ФС ext4.

В данный момент загрузка файла прошла. Запускал загрузку руками через консоль, т.е. «wget http://...".
Нужно, чтобы работало в скрипте. К сожалению, мне урезают канал в интрасети и загрузка занимает более часа. Попробую запустить загрузку через скрипт.

ВОобще по памяти wget весьма корявый

Может есть ризон задействовать aria2c – он сразу деофлтом память выделяет на диске и туда пихает. Да вообще как-то по адекватнее на больших файлах

Опишу подробнее цепочку запуска.
Я запускаю скрипт с wget через таймер systemd. Когда wget выкачивает 99% большого файла (3.7 Гб), он начинает дико отжирать оперативу (её 2 Гб). Отожрав всё, что есть, падает и орёт «wget: недостаточно памяти».
Причем, если в скрипте указывать именно загрузку этого файла, т.е.:

wget http://../.../file

wget \
	--mirror -R "index.html*" \
	-P /mnt/mirror/ \
	--append-output=$FileLog \
	http://10.3.128.249/

$FileLog куда указывает?

Как победить?

Возможно косяк wget'а какой-то при рекурсивном обходе. httrack поковыряй.

Извиняюсь за ламерский вопрос. Я вообще wget правильно использую? Т.е. изначально нужно сделать зеркало хранилища файлов, доступное только по http. Может быть нужно использовать другие инструменты или как-то по-другому использовать wget?

rsync

rsync даст по http скачать? Думал, он по своему протоколу работает.

Был уверен что даст, но нет. А работает он по ssh, своему протоколу и по файловой системе. Если есть доступ по ssh это лучший вариант, т.к. качает не все а только изменения.

Если сервер отдаёт листинг, то попробуй lftp. У этой проги есть команда mirror с настройками на несколько потоков и синхронизацией.

Есть zsync для http, алгоритм схож с rsync.

/var/log/wget.log
Если Вы на свободное место на разделе намекаете, то его предостаточно и в момент загрузки, и в момент падения.

Для zsync нужно специально готовить хранилище, добавляя метафайлы. Мне же доступно только скачивание по http.

Понятно, спасибо за информацию, zsync особо не юзал. Тогда curl вполне себе замена wget.

Создал с нуля две машины: виртуалку (2 Гб, 2 ядра, 50 Гб под корень) и lxc с теми же параметрами. ВМ - та же ошибка, однако, на lxc загрузка проходит без ошибок.
Почему? Может на пользователя какие ограничения есть?

может своп в вм включить?

Попробую, но на предыдущей ВМ он был (1 Гб) и в процессе никак не использовался.

Ну или tmpfs где-то всё же используется (системда намекает), или надо валить с wget на curl.

Грепай sysctl на предмет ограничений памяти на процесс.

В файлах /etc/sysctl.d/99-sysctl.conf и /etc/sysctl.conf все строки закомментированы.

Для успешной загрузки больших файлов с помощью wget с параметром "--mirror" требуется swap объемом больше загружаемого файла. Проверено эмпирически.
Было дано:
Гипервизор Proxmox 5.1;
Виртуальная машина (2 Гб RAM, 40 Гб под корень, от 2 до 10 Гб под swap);
Debian Stretch 9.8;
wget 1.18.
Для lxc без swap с теми же параметрами wget загружает файлы без ошибок.

sysctl -a выложи куда-нибудь.

https://dropmefiles.com/K4vyq