Метод № 4 предусматривает ручное увеличение количества страниц, выделяемых в ядре для аргументов командной строки. Если вы посмотрите на файл include / linux / binfmts.h, вы найдете следующее в верхней части:
/*
* MAX_ARG_PAGES defines the number of pages allocated for arguments
* and envelope for the new program. 32 should suffice, this gives
* a maximum env+arg of 128kB w/4KB pages!
*/
#define MAX_ARG_PAGES 32
Чтобы увеличить объем памяти, выделенный для аргументов командной строки, вам просто нужно предоставить значению MAX_ARG_PAGES большее число. Как только это изменение сохранено, просто перекомпилируйте, установите и перезагрузите новое ядро, как обычно.
На моей собственной тестовой системе мне удалось решить все мои проблемы, подняв это значение до 64. После обширного тестирования у меня не возникло ни одной проблемы с момента переключения. Это вполне ожидаемо, поскольку даже при MAX_ARG_PAGES
значении 64 максимально длинная командная строка, которую я мог бы создать, занимала бы только 256 КБ системной памяти - не очень по современным стандартам системного оборудования.
Преимущества метода № 4 очевидны. Теперь вы можете просто запустить команду, как обычно, и она успешно завершается. Недостатки одинаково очевидны. Если вы увеличите объем памяти, доступный для командной строки, за пределы объема доступной системной памяти, вы можете создать DOS-атаку на вашу собственную систему и вызвать ее сбой. В частности, в многопользовательских системах даже небольшое увеличение может оказать существенное влияние, поскольку каждому пользователю затем выделяется дополнительная память. Поэтому всегда проводите тщательное тестирование в своей среде, так как это самый безопасный способ определить, является ли метод №4 приемлемым для вас.
Я согласен, что ограничение серьезно раздражает.