Неопознанный кактус

Live stream finished (1 hour)

Live stream started

Сегодня хочу опробовать новый формат, запущу немного позже стрим: побегаем в Pragmata под Arch Linux и может быть в Resident Evil 9: Requiem. Рекламы казино и ставок не ожидается, подумалось просто, что если всё равно планирую часик поиграть, то почему бы не включить OBS. И ещё мне как гику интересен видеозахват с других платформ, как подъедет железка, постримим с PS5 Pro, Xbox Series X и со SteamDeck. Разминка на ПК

/usr

Актуальная картина в современных дистрибутивах - всё линкуется на /usr:

.
├── bin -> usr/bin
├── lib -> usr/lib
├── lib64 -> usr/lib64
├── sbin -> usr/sbin

А здесь ещё интереснее 🙂

/usr - это не /user, как можно предположить из названия.

Хотя изначально это был User - да, homedir пользователя. Но теперь нет, теперь это: "UNIX System Resources".

Что здесь произошло? Произошла классика.

У создателей UNIX закончилось место на корневом диске.
Они посмотрели на файловую структуру.. и решили перекинуть то что не вмещалось в домашнюю директорию пользователя, которая смонтирована отдельно.

Ну а что, там же есть место ¯\_(ツ)_/¯

И назвалась получившаяся конструкция не как-нибудь, а "Вторичной иерархией".
Не баг, а фича.

Там должны лежать не критичные для загрузки системы программы, общие ресурсы, библиотеки, документация, переводы, исходные коды и тд

Не критичность для системы - ключевой критерий нахождения в /usr, но как мы видим теперь туда переносят и критичное.

Дело тут вот в чём: программы перестали быть простыми, зависимости есть почти у всего, статичного больше почти ничего нет, соответственно что ни возьми - всё лезет в /usr/lib за shared libraries:


ldd /bin/mount
linux-vdso.so.1 (0x00007fbaf2845000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007fbaf27ae000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fbaf277a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbaf2584000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fbaf2524000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbaf2847000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fbaf2475000)


Ну а раз всё динамическое, то всё к зависимостям и переехало.
Архитектурно - некорретно, краеугольные принципы нарушены, но по факту получается обосновано.

Изменились механизмы загрузки системы, инициализации и восстановления, много всего изменилось и можно понять почему от канона отходят, но как по мне - лучше ломать совместимость, чем годами хлам держать.

Filesystem Hierarchy Standard

/bin
/sbin
/usr/bin
/usr/sbin

оО

Зачем столько похожих разделов? И там и там программы, права одинаковые..
Файловая иерархия в Linux полна вопросов, если выражаться мягко.

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

Изначально дерево разделов было скопировано из UNIX, просто и без затей.
Там, как я уже рассказывал, большое влияние на архитектуру оказали технические средства и ограничения начала 70х.

Памяти было мало, система не всегда могла уместиться целиком на один накопитель, поэтому разделы могли монтироваться физически отдельно друг от друга и загружаться не одновременно. В некотором роде смотреть на них можно как на диски C:/, D:/, E:/ в Windows.

Соответственно у нас по дизайну фрагментация и одни фрагменты функционально важнее других.

Чем отличаются /bin и /sbin?

Ну, bin - понятно, binary, sbin - superuser binary. И всё это именно про базовые системные программы - их разделяют на общие и привилегированные. /bin есть у обычных пользователей в PATH, /sbin - нет, он в PATH у root. В /bin лежат такие программы как ls, cat, echo и тд, в /sbin: fdisk, useradd, mkfs и прочие.

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

И есть еще один важный момент - большая часть программ собраны динамически, то есть линкуют ресурсы при запуске, но в случае с разными точками монтирования доступность не гарантирована и для администратора часть программ компилировали статично, со включением всех компонентов. То есть если система у вас рассыпалась - админ должен cуметь с помощью программ из /sbin её продиагностировать и восстановить. Так оно задумывалось, но сейчас всё меньше кто-то заморачивается и такой продуманности почти не встретить, по сути осталась лишь условность.

А почему она осталась?

Потому что Linux - это ядро, а операционная система - это GNU/Linux. Дистрибутивов GNU/Linux наплодилось великое множество, так как лицензия GPL поощряет форки (с возвратом).

И буквально сразу проявилась проблема, что вроде бы мы все Linux, но единства нет - каждый строит как ему вздумается и невозможно это всё учесть и подстроиться в плане поддержки и распространения софта. То есть сама суть и идея проекта Linux с её GPL без стандартизации файловой иерархии в общем-то перспектив не имела, на тот момент по крайней мере.

И тогда было принято закрепить канон: https://specifications.freedesktop.org/fhs/latest/
На его основе работают в том числе инструменты сборки autotools и cmake - в мире Linux программы собираются из исходников, в этих инструментах жестко прописаны пути из этого стандарта, если им не следовать - работа с вашим дистрибутивом потребует знатного пердолинга, никому это не надо. Поэтому добровольно-принудительно канону начали следовать.

Но Linux уже не стартап, экспансия свершилась, сформировались киты и успех проекта больше не зависит от всеобщей колаборации, тренд скорее обратный. В последние годы всё больше происходит уход от канона: где-то разделы объединяют, где-то заменяют симлинками, а кто-то вообще делает полностью по своему (см. NixOS).

strace

Программа не может сама взять ресурсы системы (прочитать файл, выделить память, открыть сокет, отправить пакет и тд), необходим системный вызов (system call).

Категории системных вызовов:
1. Работа с файловой системой (openat, read, write, close, ...)
2. Работа с памятью (mmap, munmap, mremap, ...)
3. Управление процессами (fork, clone, kill, execve, ...)
4. Сеть (bind, connect, listen, accept, ...)
5. Многопоточность (futex, pause, nanosleep, ...)
6. IPC (pipe, shmget, msgsnd, msgrcv, ...)
7. Пользователи и права (getuid, getgid, setuid, ...)
и так далее: сигналы, пространства имён, event loop, ...

Выполнение даже простой программы - набор таких вызовов. Увидеть их можно с помощью strace - мощного диагностического инструмента. Добавляем перед началом команды strace и получаем все подробности. Каждый запрос к системе перехватывается, анализируется и фиксируется всё: сам вызов, аргументы и возвращаемые значения. Важно! Скорость выполнения программы в этом режиме проседает на порядки - в продакшене использовать с осторожностью. Тем не менее, иногда только через трассировку можно понять почему, например, процесс завис:

strace -p 37958 покажет чего именно ждёт указанный PID.

Попробуйте добавить strace перед самыми разными командами: ls, cat, date, who, ...
Очень интрересные вещи можно увидеть.

Прочитаем вывод strace:

strace cat /proc/cpuinfo
execve("/usr/bin/cat", ["cat", "/proc/cpuinfo"], 0x7ffd55c9d688 /* 21 vars */) = 0
brk(NULL) = 0x5564493fb000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd834c61000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9931, ...}) = 0
mmap(NULL, 9931, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fd834c5e000
...


execve - запустилась программа cat (и передала 21 переменную окружения), 0 - успех
brk(NULL) - вопрос про указатель на куче, 0x5564493fb000 - адрес конца кучи
mmap - выделение 8кб памяти (8192 байта), MAP_PRIVATE - приватная не разделяемая память, 0x7fd834c61000 - адрес выделенного блока
ld.so - динамический загрузчик, работа происходит через него
ld.so.cache - бинарный кэш, в котором записано где на диске лежат системные библиотеки
openat - cat попросил ядро открыть файл, ядро вернуло дескриптор 3

(0, 1, 2 — это stdin, stdout, stderr, поэтому следующий свободный — 3) и т.д.

Действий много, лог забит, поэтому важно уметь фильтровать действия по категориям: ключ -e

strace -e openat ping -c1 ya.ru
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libunistring.so.5", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY|O_CLOEXEC) = 5
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 5
openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 5
openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 5
openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 5
openat(AT_FDCWD, "/etc/gai.conf", O_RDONLY|O_CLOEXEC) = 5


или несколько: strace -e openat,connect ping -c1 ya.ru

Sticky Bit

Специальный флаг для директорий, не позволяющий удалять чужие файлы.

костыль к стандартной системе . Для общих разделов, как, например, /tmp или /dev/shm нужно разрешить запись всем, но при этом чтобы совсем уж не было беспредела. Предлагается аналогия с общей кухней в общежитии - пользоваться кухней могут все, но чужое выбрасывать нельзя. Забавно при этом, что можно полностью изменить чужое содержимое, но именно удалить - нельзя (переименовать тоже нельзя, потому что это суть есть удаление с пересозданием).

"Липкий бит" отображается как t в конце блока прав у директорий, для файлов это не работает.


$ ls -ld /tmp
drwxrwxrwt 88 root root 171606016 Jul 13 11:35 /tmp

Устанавливается флаг через chmod:
$ chmod +t ~/shared/folder

или единицей перед основным значением в числоворм режиме:
$ chmod 1777 ~/shared/folder

Снять ограничение:

$ chmod -t ~/shared/folder

/dev/shm

Устройство доступа к разделяемой памяти (shm - SHared Memory), технически - виртуальный диск, работающий в оперативной памяти, смонтированный на файл устройства. В более старых системах назывался /dev/tmpfs

Собственно тип его файловой системы так и называется, проверим размер диска:
$ df -h /dev/shm
Filesystem Size Used Avail Use% Mounted on
tmpfs 442M 0 442M 0% /dev/shm
Размер по-умолчанию равен половине доступной оперативной памяти. Все файлы, которые вы туда положите физически будут находиться в RAM, а скорость чтения/записи равна скорости оперативной памяти. При перезагрузке соответственно данные теряются.

Размер можно изменить, потребуется перемонтировать устройство
$ mount -o remount,size=1G /dev/shm
Чтобы зафиксировать эту настройку, нужно уже прописать в /etc/fstab:
tmpfs /dev/shm tmpfs defaults,size=1G 0 0

Важно! Это не ring-buffer, не FIFO, если место кончится - то кончится. Если процесс завершится, не удалив свои данные отсюда, они там останутся висеть до перезагрузки. Например, если придет OOM Killer и прихлопнет разъевшуюся программу, данные здесь останутся висеть, в этом основное отличие просто от частной выделенной процессу оперативной памяти - оно как бы диск, просто в памяти. Задача - быстрое межпроцессное взаимодействие данными в понятном интерфейсе, требует менеджмента.

Fork bomb

В классическом понимании это программа, которая бесконечно порождает свои копии через системный вызов fork, простейший пример: while true; do fork & done

Что произойдёт? Кол-во процессов начнет расти по экспоненте и довольно скоро исчерпает весь пул PID, невозможно будет запустить новые процессы, в том числе kill и OOM Killer тоже не придёт.

Когда такое может произойти?

1. При направленной атаке, когда подобный скрипт запускается пользователем
2. При ошибке в коде программы. Если программе нужно порождать субпроцессы и допускается рекурсия
3. При работе планировщика

На последнем пункте остановимся отдельно как на наиболее распространенном.
В сущности это не совсем Fork bomb, но результат для системы тот же.
Вы добавляете какое-то задание в crontab, например:
* ~/script.sh

Каждую минуту стартует новый экземпляр программы, независимо от того завершился ли предыдущий запуск.
Если в логике скрипта допущено ожидание или бесконечный цикл и нет никакого контроля (чаще всего) - процессы начинают копиться, утилизируя CPU и выбирая дескрипторы, технически это "Process Leak", но итог тот же, что и у Fork bomb.

Эффект усиливает работа с какой-нибудь базой данных или интерпретаторами, у которых свои собственные пулы и лимиты и проблемы начинаются каскадно cо стремительной деградацией. Сталкивался с этим сильно чаще, чем хотелось бы. Например, сетевой вызов на недоступный домен без таймаута или ожидание какого-то условия, которое не наступает.

Что можно (и следует) сделать? Используйте flock (file lock):
* /usr/bin/flock -n /tmp/script.lock ~/script.sh

Когда процесс запускается, создается файловый дескриптор, по завершении - удаляется, всё просто. Соответственно пока дескриптор живёт на диске, последующие запуски не приводят к спаму процессов. Важно обратить внимание на ключ -n: без него мы по-умолчанию в "блокирующем" режиме - flock запустился, но ждёт, процессы самого flock копятся, хоть и не происходит вызова "таргета". n - это "nonblocking", в этом случае запуск будет завершаться ошибкой - процессы не копятся.

Если источник проблемы в cron и вы не успеваете ничего с этим сделать (всё умирает слишком быстро), вас спасёт single mode - при загрузке системы в однопользовательском режиме cron не стартует, заходите в систему и редактируете /etc/crontab вручную.

Если система кое-как, но живёт:
systemctl stop cron и идём разбираться

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

Tape Archiver (TAR)

Один из старейших инструментов, созданный еще в 1979 году, по факту стандарт архивации в современных UNIX-системах. Не сразу может быть очевидным, что архивация и компрессия - это разные задачи и что архив != сжатие. Задача архива - объединить файлы в один общий файл-контейнер с целью удобного хранения, резервного копирования или переноса. На заре эпохи для хранения использовались ленточные накопители, откуда инструмент и получил своё название.

Если не указать в качестве аргумента имя файла, tar по-умолчанию отправится писать данные на магнитную ленту: /dev/rmt0 (Raw Magnetic Tape). Если таковой в системе нет, то вывод будет направлен в STDOUT, но терминал такую попытку отклонит, поэтому вернется ошибка: tar: Refusing to write archive contents to terminal (missing -f option?)

То есть минимально актуальный вызов выглядит так:
tar cf access.tar access.log

Специально написал аргументы без дефиса - tar настолько древний, что в те времена современный синтаксис еще не был до конца сформирован и такой формат записи является каноном, но вы пишите нормально, с дефисами, всё адаптировано.

Интересно, что до сих пор сохранилась опция --tape-length, хоть уж 45 лет прошло, выполняет роль сплита:

tar -cMvf logs.tar --tape-length=1024 /var/log

Кстати tar коварен - если перепутать местами аргументы (я это делал) и имя архива указать в конце (что кажется логичным - типа "target"), то ваши данные могут быть стёрты. В зависимости от сборки может сработать предохранитель, но у меня в BSD на заре карьеры не срабатывал, да он и не должен. Считается, что ты понимаешь что делаешь и несешь за это ответственность, десять раз переспрашивать и оберегать - не в философии UNIX. Поэтому если ты выполнил tar cf access.log access.tar, то это буквально эквивалент tar --create --file=archive.log access.tar, archive.log будет перезаписан, а так как access.tar не существует, то мы получим пустой файл без данных размером 0. Пару раз было очень больно, но быстро учишься 🙂 Вообще вот эта беспощадность и равнодушность системы в противовес гиперопеке я считаю крайне полезной и дисциплинирующей, не должно быть полагания ни на кого кроме себя самого и если ты ошибся, то ты ошибся, это правильно.

Один из ключевых принципов UNIX - делать что-то одно и делать это хорошо, для комплексных сценариев применять комбинаторику. tar именно архивирует - объединяет данные и фиксирует их мету (права, владение, атрибуты, временные метки). Если нужно сжатие, то подключается компрессия, в современных версиях всё упрощено до опций самого tar, но технически отрабатывает несколько инструментов. Например, классический gzip при опции -z:

tar -czf access.tar.gz access.log

Еще раз обозначу важный момент - имя архива должно идти после ключа -f, поэтому он должен быть последним в наборе, tar -cfz - некорректно.

Несколько актуальных вариантов по компресии:
gzip: -z (.tar.gz, .tgz) - стандарт, средняя скорость, среднее сжатие
bzip2: -j (.tar.bz2) - выше сжатие, скорость ниже
xz: -J (.tar.xz) - максимальное сжатие, но долго и дорого (кушает память)

Так как по сути мы объединяем опциями разные инструменты, получить тот же результат можно через перенаправление:

tar c access.log | gzip > access.tar.gz

Ещё интересней распаковка с декомпрессией:

cat access.tar.gz | gunzip | tar x

работают три программы:

cat читает файл архива
gunzip выполняет декомпрессию
tar x распаковывает файлы из архива

Чтобы не строить каждый раз очевидную цепочку чтения и декомпрессии, появился инструмент zcat:

zcat access.tar.gz | tar x

то же самое

Замерить время выполнения команды

Достаточно просто: перед командой нужно ввести time

time grep -r "Loader" libc
Binary file libc/target/debug/deps/libgarando_syntax-a4083b3fe293f373.rmeta matches
Binary file libc/target/debug/deps/libgarando_syntax-d2dc6464b24019fe.rmeta matches
Binary file libc/target/debug/deps/libgarando_syntax-d2dc6464b24019fe.rlib matches
Binary file libc/target/debug/build/ctest-test-73059acd9fed048c/build-script-build matches
Binary file libc/target/debug/build/ctest-test-73059acd9fed048c/build_script_build-73059acd9fed048c matches

grep -r "Loader" libc 2,61s user 0,16s system 89% cpu 3,098 total


2,61s user - потратил процессор на выполнение пользовательского кода
0,16s system - на системные вызовы (чтение/запись файлов, работа с диском)
89% cpu - использовано 89% одного ядра процессора во время выполнения
3,098 total - реальное время (wall-clock time) от запуска до завершения команды

История конечно же о том как я всех спас :)

Запросил прямой доступ к системе (все оказались вдруг готовыми нарушить регламенты) и начал препарировать дамп. Я знал на какой строчке процесс прервался, а значит нужно было подняться по дампу чуть выше и выбрать "скальпелем" нужные инструкции, обойти проблемный участок - взять только структуры без данных, сдвинув инкременты вправо, чтобы позже вернуть записи без коллизий - и оставшийся хвост дампа запустить снова в работу. Вооружился grep, sed, awk, split и прочим я довольно быстро сформировал подлеченный хвост дампа, который админы запустили и он успешно продолжился с точки останова. Ни в каком редакторе это было невозможно сделать, только так. Этим же вечером чуть позже система успешно запустилась, поврежденные данные мы позже уже в спокойном режиме дозалили (жаль не поврежденные нервные клетки).

Эта история не только о том какой я молодец, но и как важно понимать системы, с которыми работаешь и уметь работать с данными. Ни в одном регламенте не было таких инструкций, их и далее не внесли, это невозможно. Нельзя вписать пункт "пусть кто-то толковый разберется", поэтому после инцидента провели мног особраний и аудитов, но в итоге всё еще больше усложнили и удорожили. Ключевое же - это навыки, понимание и умение в низкоуровневый инструментарий.

Невыдуманная история к предыдущему посту

Работал я как-то с крупным ретейловым холдингом, размер базы данных CRM которой стремился к терабайту. Снятие такого дампа занимало больше пяти часов и выполнялось на readonly реплике, потому что требовало блокировки для гарантии целостности данных (потом еще реплика пару часов догоняла прод по бинлогам прежде чем перейти в рабочее состояние). Развертывание такого дампа занимало почти сутки! Потому что race condition и запись должна быть строго последовательной, иначе собьются автоинкременты и связи и прочие нюансы БД. И у такой БД естественно должен был быть горячий дублёр, холдинг не мог себе позволить не иметь резервной копии (справедливо). Было установлено требование - время переключения на резерв не должно превышать 10 мин (бизнес теряет деньги!), а затем, внимание, после восстановительных работ на проде трафик нужно возвращать на прод, а резерв снова делать резервом (лучше железо только на проде, на резерве бизнес теряет деньги). Админы почесали голову и сделали репликацию master-master, то есть запись возможна с обеих сторон (иначе задачу действительно было не решить), но нужны грамотные действия, чтобы запись никогда не шла одновременно, иначе коллизия и смерть, цена ошибки фатальна.

И вот в какой-то день ружье выстрелило. Дежурный инженер решил накатить обновление безопасности на БД резерва (благое намерение) и по имеющемуся регламенту он не должен был его согласовывать (минорное же!). В три часа ночи (единственное допустимое по регламенту время) когда на связи не было вообще никого, он начал технические работы. Что-то пошло не так и минорное обновление сломало БД. Последовала попытка откатить обновление, но теперь повредились данные.. Ночь, резерв накрылся, дежурный инженер решает запустить процедуру восстановления из дампа и так как данные повреждены, отправляет команду DROP DATABASE... и она уходит и на резерв и на прод... потому что master-master и он не принял нужных действий и рядом никого не было. Эта ситуция не должна была произойти, но она произошла.

Утром у меня разрывался телефон от звонков и сообщений, в которых стоял мат, крики и слёзы в перемешку с угрозами, потери бизнеса каждую минуты были чудовищными. Когда стало понятно что именно произошло, у нас осталась только одна опция - разворачиваться из дампа с нуля и ждать. Админы уже запустили этот процесс и сообщили, что ориентировочно к полудню мы запустимся. Бизнес предупредил, что нас всех ждут многомилионные штрафы и все начали ждать. В 12 ничего не произошло, в 15 тоже и в 18 когда уже надо было собираться домой, дамп всё еще накатывался. Естественно никакого "домой" не получилось и под общий вой и проклятья мы все ждали когда же дамп завершится. В 20 часов приходит сообщение от админов: "ошибка, дамп не развернулся"...

Сказать, что наступил шок, отчаяние и паника это особо ничего не сказать. У большинства участников начался буквально паралич воли. Админы с белыми лицами молчали (они сделали всё по инструкции, а оно не сработало), все понимают, что новые попытки - это еще почти сутки и никто не понимает что должно помочь. Отладка на таких объемах практически невозможна. Менеджеры подрядчика кажется смирились, что это их конец, а владельцы, что их ждет либо бетон, либо банкротство. В общем наступил всеобщий мрачняк. Ошибку то БД показала, но повторные попытки это каждый раз сутки, ну то есть всё.

Работа с большими текстовыми файлами

Обычно это логи или дампы, надо что-то найти, но в редакторе (каком-нибудь `nano`) файл не открыть, даже если хватит памяти, то с такой соростью, что работать будет практически невозможно. Но там перемещение, поиск, фильтры, как быть?

Проблема серьезней, чем может показаться. Кто обслуживал большие системы, наверняка знает как часто такая ситуация возникает и как счет идёт на секунды, а ты сделать ничего не можешь. Первое, что обычно придумывают - скачать файл себе и открыть у себя "на нормальном-то компе". Но обычно проблема никуда не уходит, вы только теряете время на перекачке данных, ваш редактор зачастую тоже начинает умирать (потому что всё пытается проанализировать и вообще заточен под другой сценарий), сервера умеют накапливать огромные массивы данных.

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

Самое простое: less и more (особенно `less`)
Такой просмотрщик позволяет плавно ехать по содержимому с помощью стрелок или PgUp/PgDn, искать текст ("/", запрос, enter). Ключ -N покажет номера строк

less -N huge_file.log


Если нужно увидеть "шапку" или "подвал", например последние N записей в логах, еще удобней использовать head и tail.
head -n 20 huge_file.log - покажет первые 20 строк
tail -n 20 huge_file.log - последние 20

А ключ -f позволит в реальном времени видеть обновления файла, не открывая его постоянно заново: tail -f /var/log/syslog

Иногда ситуация сложнее и надо что-то найти непонятно где, оно не в начале, не в конце и глазами это можно искать весь день. Наш лучший друг в этом случае - grep.
grep -i -n "error" huge_file.log, ключ -i игнорирует регистр, ключ -n покажет номера найденных строк.
Важный момент! Поиск идет построчно, эффективно, но построчно от и до. Если достаточно найти первое вхождение или N первых, то ограничиваем кол-во результатов и экономим время: grep -i -n -m 5 "error" huge_file.log

Теперь у нас есть номера нужных строк и мы можем, например, забрать содержимого из огромного файла в какой-то небольшой файл и работать уже с ним в редакторе нормально. Нам нужен sed, заберем строки с 10 000 по 20 000:

sed -n '10000,20000p' huge_file.log > вырезка.log

Можно также скомбинировать для этой задачи head и tail

tail -n +10000 huge_file.log | head -n 10001 > вырезка.log


Файл также можно разбить, нарежем чанки по 10 000 строк

split -l 10000 -d -a 3 huge_file.log part_

-d и -a 3 - устанавливают цифровой суффикс вида part_001

Также можно разбить по размеру:

split -b 100M huge_file.log part_


И еще бывает полезно быстро получить информацию о размере содержимого
wc -l filename - кол-во строк в файле
wc -w filename - кол-во слов
wc -c filename - кол-во байт

Также есть возможность "вертикальной" нарезки. Кто работал с CSV - должен оценить:
cut -d ';' -f 2 filename - извлечь второй столбец при разделителе ";"
cut -c 1-10 filename - извлечь первые 10 символов каждой строки

Феномен GTA

Сложно назвать другую настолько массово любимую и ожидаемую игру, чем GTA. При этом сам я не могу найти у себя никакой воли и интереса в неё играть.

Первое знакомство для меня было еще с третьей частью, я тогда был мелким пацаном без собственного компа или приставки, старший брат включил мне её "побегать". Бегать было действительно прикольно, но.. на этом всё.

Совершенно не могу найти в себе желание в виртуальном городе бегать что-то зачем-то исполнять, как-то себя развлекать. Это я как человек, закрывший все знаки вопроса на Скеллиге вам говорю. Сама идея виртуального города давно для меня инфлирована, должно быть что-то большее. Да, там есть сюжет, но он такой.. не за него по-моему GTA любят. Глядя на GTA RP видно, что люди готовы буквально жить виртуальную жизнь в виртуальном городе, который как их реальный мир, только виртуальный... в 2026 то году.. посмотрел пару стримов и не знаю как это комментировать, мне очень странно.

При этом я игры очень люблю и игры с открытым миром люблю и даже EVE Online люблю (очень), которая космическая песочница без целей и задач, но насколько же она уникальна и самобытна. А вот городская "песочница", такой "Regular City Sandbox" для меня загадка.

Я это пишу не с целью кого-то задеть не дай бог или поспорить, это мысли в слух на волне очередных горящих публикаций о скором релизе и объявленном ценнике и как все издатели переносят релизы и боятся GTA.. Без сомнения великая игровая серия, которую я, увлеченный игрок, никак не могу заставить себя полюбить.