Komut satırı maksimum uzunluğunu artırmak için çekirdeği derleyin

Bunun ardından, https://stackoverflow.com/questions/14176089/system-command-line-max-length-in-perl adresindeki exec / komut satırı argümanları için maksimum uzunluk kontrol edilir ARG_MAX.

Bu yüzden böyle bir komut satırı maksimum uzunluğunu artırmak istiyorum ve çekirdeği yeniden derlemek tek seçenek gibi görünüyor. İnce. Ancak benim sorum üzerinde ARG_MAXherkes yükseltilmesi gerektiğini biri olduğunu söylüyor, ama ben okuma çünkü http://www.in-ulm.de/~mascheck/various/argmax/#linux olduğunu,

ARG_MAX2.6.23 öncesi çekirdek kodunda kullanılmaz. Linux 2.6.23 sonrası, ARG_MAXartık kodlanmış değildir.

Yani ARG_MAXartık kullanılmıyor mu , kullanılmıyor mu? Daha sonra exec / komut satırı argümanları için maksimum uzunluk nasıl arttırılır? çünkü komut satırı maksimum uzunluğu, tercih ettiğimden daha küçük bir değere sahip.

Teşekkürler

Linux-2.6.23'ün ARG_MAXönceden belirlenmiş bir sabit olması gerekmediğinden, bağımsız değişkenlerin toplam boyutunun yığın boyutunun 1 / 4'üne kadar olmasına izin verilir (bkz ulimit -s. KB'deki yığın boyutu; ancak /proc/1/limitsdaha kesindir). Ancak, ARG_MAXsadece süreç argümanları için değil, dikkate almanız gerekebilecek çevre değişkenlerini de içerir.

POSIX, ne ARG_MAXanlama geldiğini ve kabul edilebilir bir alt sınır ( _POSIX_ARG_MAX4096) tanımlar . Statik değeri, ( #definesistematik olarak) sistem başlıklarında bulunur ve linux çekirdek başlıklarında da belirlenir. Etkili değeri komut satırından sysconf()veya getconf ARG_MAXkomut satırından alınabilir .

Eğer glibc başlıklarını ( sys/param.h) kontrol ederseniz, şunu göreceksiniz:

/* The kernel headers defines ARG_MAX.  The value is wrong, though.  */
#ifdef __undef_ARG_MAX
# undef ARG_MAX
# undef __undef_ARG_MAX
#endif

Bu, glibc-2.17'den, bu 2,11 (2009) civarında ortaya çıktı, bu tarih için ilk destek 2,8 (2008) oldu, ancak 2,14 (2011) öncesinde, yukarıdaki mantıkta beklendiği gibi çalışmasını engelleyen bir hata vardı. Amaç, ARG_MAXsabit olmadığı takdirde tanımsız olduğundan emin olmaktır , bu nedenle programlara güvenmek gerekir sysconf(). (Tanımlanmış olsa bile, yalnızca garantili düşük bir limit olabilir ve programlar sysconf()üst limitleri belirlemek için kullanmalıdır , bkz. sysconf(3))

Eğer C derleyicisi (ile gördüklerini kontrol edebilirsiniz gcc, bash/ zshsözdizimi için):

$ gcc -E -dM -x c <(echo "#include <sys/param.h>") | fgrep ARG
#define ARG_MAX 131072
#define NCARGS ARG_MAX
#define _POSIX_ARG_MAX 4096

Yukarıdaki çıktı, tam çalışma zamanı (glibc desteği) değil, çekirdek desteğine sahip eski bir sistemden (2.6.27) geliyor. Hiçbir ARG_MAXçizgi görmüyorsanız, önceden belirlenmiş bir sınır değildir ve kullanmanız gerekir (sysconf) getconf ARG_MAX:

$ getconf ARG_MAX
2097152

Desteği kontrol etmenin yararlı bir yolu da:

$ xargs --show-limits < /dev/null
Your environment variables take up 2542 bytes
POSIX upper limit on argument length (this system): 2092562
POSIX smallest allowable upper limit on argument length (all systems): 4096
Maximum length of command we could actually use: 2090020
Size of command buffer we are actually using: 131072

Bu daha yüksek limitlere sahip bir linux-2.6.37 / glib-2.13 sisteminden geliyor. Çıktıların son satırına, xargsvarsayılan olarak (oluşturma süresi) "muhtemelen" başlayan bir işlemin çok büyük değerlerle başa çıkamadığı durumlarda "mantıklı" bir limit getirdiğini unutmayın. Bu -sseçenek ile çalışma zamanında bunu değiştirebilirsiniz . Ayrıca, bir etkiniz varsa ulimit -s, bu sayılar daha düşük olabilir. Bu gerektiğini findutils-4.3.9 (2007) beri düzgün çalışması. Ayrıca bakınız: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Argument-list-too-long

Perl'i kontrol etmek için:

% perl -MPOSIX -e 'print ARG_MAX . "\n"';
131072

Yukarıdakiler yine eski bir sistemden geliyor, yeni bir sistem şunu göstermeli:

% perl -MPOSIX -e 'print ARG_MAX . "\n"';
Your vendor has not defined POSIX macro ARG_MAX, used at -e line 1

Özetlemek:

• 2.6.23 sonrası bir çekirdeği çalıştırıyorsanız, çekirdek, bir işlem oluştururken daha büyük boyutların geçirilmesine izin verir. Bu gerekli ancak yeterli olmayan bir durumdur.
• Ana süreç (sert kodlanmış örn herhangi bir yanlış çalışma zamanı sınırı zorlamak olmamalıdır ARG_MAX, bunun için kontrol etmelidir) exec() E2BIGyerine hata kodları ve gerektiği kullanımı sysconf(_SC_ARG_MAX)gerekirse
• Çocuk süreç özellikle yanlış kodlanmış sınırları olmamalıdır çekirdek sağlanan parametreleri işler onun başlatma kodu herhangi bir yanlış çalışma zamanı sınırı zorlamak olmamalıdır (örn kurarken argc, argc, çalışma zamanı kullanımı için çevre bölgesi). Bu genellikle libc (glibc) ile yapılır.
• Ebeveyn ve çocuk için ayrıca libc'den (veya eşdeğeri) konfigürasyon ve zaman desteğine ihtiyacınız olabilir. Glibc için bu en azından glibc-2.8 gerektirir (onunla çalışmak mümkün olsa da, basit veya temiz olmayabilir)

Bir sorun birleşimi güncellenmiş (linux> = 2.6.23) çekirdek, ancak eksik veya şüpheli glibc desteği (glibc <= 2.14)

Daha eski bir çekirdek kullanıyorsanız, öncelikle satıcınızın özelliği geri taşımadığından emin olun. Aksi halde, ilke olarak çekirdek sınırını değiştirebilir ve yeniden derleyebilirsiniz, ancak çalışma desteği için en azından bazı sistem başlıklarını veya kaynak kodunu değiştirmeniz gerekebilir.

Programlar isteğe bağlı değerleri kullanabilmelidir, ancak bu her zaman böyle olmayabilir: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html

Başvurular bir limit için belirli bir değer almamalıdır. [...] Bununla birlikte, listelenen sınırların çoğunun değişmez olduğu ve çalışma zamanında, sınırın değerinin aşağıdaki nedenlerden dolayı bu başlıkta verilenlerden farklı olabileceği belirtilmelidir:

• Sınır yol adına bağlıdır.
• Sınır derleme ve çalışma zamanı makineleri arasında değişir.

Bu nedenlerden dolayı, bir uygulama çalışma zamanında bir limitin gerçek değerini belirlemek için fpathconf (), pathconf () ve sysconf () işlevlerini kullanabilir.