mayton2019

Пропадание - это не инженерный термин. Как выглядит пропадание с точки зрения gubuster?
Connection timed out? Connection refused? Попингуй. Потрассируй роуты. Если ты занят такой непростой задачей как pen-test то надо быть специалистом в сетях. Иначе твоё заключение о пентестинге будет слабо обоснованным.

С точки зрения Linux-shell, любой процесс после завершения фиксирует код ошибки и его можно посмотреть через

echo $?

и принять решение что делать дальше. Значения кодов ошибок - специфичны для каждого приложения. Считается хорошим тоном чтобы програмист процесса сохранял туда осмысленные значения перед выходом. В С++ то это что возвращается из main - функции.

Я не специалист в mysql. Но в других DBMS достаточно CTAS/alter table rename для любых смен типов и геометрии хранения.

Sed - это вообще плохая утилита для ETL. Не используйте ее.

Алгоритмически - это буфер типа FIFO. С одной стороны заходят IP пакеты. С другой стороны они выходят с задержкой так чтобы средний объем трафика за единицу времени не превышал лимит.

Это была теория. Практически шейперы кодят на С или С++.

Сомнительно чтобы эффективный шейпер можно было сделать на Питоне.

Таже фигня. Ubuntu 18.x.LTS, HP 250. Wifi-router D-Link.
Никак не пролечил. Поменял роутер на двухдиапазонный Netis.
Стало чуть лучше. Но все равно связь регулярно рвется. И очень долго реконнектится.

Грешу просто на плохие драва в Ubuntu из за которых устанавливается слабая чуствительность.

Сейчас подключаю кабелем если надо что-то скачать.

На этом-же железе раньше стояла Windows-10 и все работало чики-пики.

ntfs - не родная система для этого дела. Если вы так по чесному хотите смигрировать на Ubuntu - то уходите совсем. Если хотите держать две ОС - то может лучше загружайтесь с флешки. Если вам ценна та инфа которая осталась на ntfs разделах.

Непонятно что такое "хост" и как с него можно что-то собирать. Хост - это технический термин. Не бизнесовый и наверное в топике имелось в виду другое. Может на этих хостах - ftp/cifs файловые хранилища?

Правильно выше пишут. Технически tar+cron решает эту задачу. И обычно самое простое решение - самое надежное. Если "хочется отслеживать" - то это уже другая задача. И она не имеет прямого отношения к бэкапу. Тоесть вопрос состоит из двух независимых частей. Собственно бэкап. И какой-то мониторинг который должен ... что то мониторить.

В задании есть какое-то противоречие. Внутри одной папки могут лежать файлы по разным месяцам. Что делать в таком случае - непонятно. Вобщем автору надо детализировать задание чтоб отвечающие могли понять что на самом деле надо. Что должно быть на выходе.

До того как автор начнет что-то повышать. Пускай послушает мою мысль. Между 3.33 и 3.6 разница порядка 8%
Общий индекс производительности системы зависит не только от процессора но вообще от совокупной работы всех частей (реакция памяти и скорость кешей L1/L2/L3). Если просто повышать частоту CPU но при этом не менять ничего остального то эффект - нивелируется. Ожидаемого прироста 8% не будет. Будет меньше.

Даже если гипотетически предположить что автор поднял частоту до 5Ghz то и в этом случае удвоения перформанса не будет.

Вобщем послушайте старого программиста на C++ и прочих ассемблерах. Не тратье своё время на фигню. Ваша игра или рендеринг 3Д графики особой разницы не почувствуют. Взамен вы получите потенциальные проблемы. Ведь производитель не собирался делать нестандартный режим номинальным. В этом был свой смысл.

Скорее всего убунта была не выключена а запаркована в хибернейт. В этом случае большинство устройств тоже паркуются.

Проверь настройки кнопки power.

Дело в том что bash сам по себе не является языком программирования. Он - просто связующий клей который вызывает внешние утилиты. Поэтому если у вас задача серъезная - то берите Perl/Python. Там есть сильные средства для процессинга текста и отчотов.

Bash подойдет только до первого out of memory как только у вас зайдет файл превышающий оперативку. Или просто зайдет "технически"-нетекстовый файл где строки будут сверх-длинные или просто вызывающие побочные эффекты. Обработать такую ситуацию в ЯП - нормально а в баше - сложно.

Если часто удаляется папка с over миллиардом файлов то можно пересмотреть эту задачу архитектурно. Например смонтировать эту папку как volume и форматировать ее. Это быстрее. В противоположность, файловые удаления по 1 штуке требуют фиксации транзакции для каждого файла. А это избыточные действия которые как раз и создают поток IOPs над структурами данных ext4. По аналогии с БД. То что делает автор это удаление каждой строчки из таблицы с коммитом. А то что я предлагаю - это по смыслу truncate table.

Почти таже самая проблема на стареньком HP Core i3. Пока стояла десятка все норм. Как только поставил Ubuntu 18 LTS - пошли регулярные дисконнекты. Субъективно вижу что очень низкая чувствительность антены приёмника в ноуте. Грешу на хреновые дрова. Так и не пролечил.

Workaround: Когда включаю смартфон в режиме wifi-точки и ложу его рядом прямо с корпусом ноута - связь появляется.

Автор пытается делать стеганографию. Тоесть в картинке скрывать информацию. Здесь выбор PNG полезен тем что инфа лежит плотно и в случае "гладкого" характера информации сжимается. Наподобие архиватора.

SVG - не подходит т.к. векторный и расточительный.
JPG - тоже не подходит т.к. повреждает информацию. Ее потом нельзя будет извлечь из файла без потерь.

По поводу дополнения файла до размера кратного длине строки (padding). Там не 00 не FF не подходит. Так как в оригинальном файле тоже могут быть эти константы и алгоритм даст сбой. Надо почитать как делается в криптографии. Там есть специальный workaround. Если его не реализовать правильно то при обратном декодировани картинки в файл мы можем получить ложное удлиннение файла на размер хвостика последней строки пикселов. Насколько это большой дэмедж для исходного файла - ХЗ. Но лучше конечно его не нелать чтоб обратное декодирование было надёжным с точки зрения длины файла.

Полностью согласен с ораторами насчет виртуализации.

По поводу ситуации что уже случилась. Скорее всего заход в баш вам ничего не даст. Т.к. любые команды что вы будете выполнять будут запускать процессы и вы будете снова и снова получать ту-же ситуацию что и с башом. Тоесть каким-то чудом зашли но ничего сделать толком нельзя.

Нужно 100% собрать логи и посмертные снимки памяти приложений. Или приложения. Скорее всего оно одно. И оно-же является источником проблемы. Это приложение надо перенести в докер к лимитами по памяти и там запускать.

Дампы памяти надо проанализировать и понять что флудит. С точки зрения приложения должны быть какие-то гарантии или требования по штатному режиму работы. Тоесть если ему надо 8Г то дайте ему ровно 8 и не больше.

На базе стандартного файлового API скорее всего невозможно. Объясню почему. Linux оперирует файловым API на уровне команд open/close/seek/read/write. Это основа которая работает для всех файловых систем. Если опуститься на уровень какой-то специфичной файловой системы (например vfat) то можно наверное порезать файл на кусочки кратные размеру блока файловой системы без пере-аллокаций. Но это - грязный хак который будет работать только под root и только для specific файловой системы. И только для особых условий (граница блока). Вобщем технически это сделать можно но использование этой утилиты будет носить "разрушительный" характер наподобие утилит parted, fdisk, mkfs.* и прочих. Сильно сомневаюсь что такая утилита будет полезна и востребована. Лучше пользоваться нормальным API.

grep -v оставляет весь текст кроме указанного шаблона.