Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes
Yes that's serious because some commands are bigger than 3.5mb, is your machine embedded perhaps? Or have you definitely given the virtual machine enough space and ram to work with? Thanks Zeb On Tue, 21 Nov 2023, 18:30 Bruno Haible, wrote: > Package: general > Severity: important > X-Debbugs-Cc: br...@clisp.org > > I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU > 8.0.2. > $ uname -srm > Linux 6.3.0-2-parisc parisc > > In this machine, for the invocation of any program, the length of the > command > line (= all arguments together) is limited to less than 3544 bytes. > > How to reproduce: > > In bash: > $ /bin/echo `seq 913` > -bash: /bin/echo: Argument list too long > > In dash: > $ /bin/echo `seq 913` > dash: 1: /bin/echo: Argument list too long > > I also see this while doing "make check" of packages that have more than > 1000 > tests. So, it appears to be a general problem. > > The values returned by getconf don't match the reality: > $ getconf ARG_MAX > 2097152 > $ getconf _POSIX_ARG_MAX > 2097152 > > I have looked at the values of several files in /sys/kernel and > /proc/sys/kernel, without finding the cause. > > For comparison, in a different VM, running "Linux 6.3.7-t2 parisc" (from > the > T2-SDE distribution), I don't observe this bug. Both machines have the same > amount of "physical" RAM: 256 MiB. > > The ulimit values don't appear to be the cause, because they are similar in > the two machines: > In the Debian VM (with the bug): > $ ulimit -a > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 849 > max locked memory (kbytes, -l) 65536 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size(512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 849 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > In the T2-SDE machine, with no bug: > $ ulimit -a > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) 1048575 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 909 > max locked memory (kbytes, -l) 8192 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size(512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 909 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > >
Bug#1056357: general: on hppa, command line of any program invocation is limited to less than 3544 bytes
Excellent, please explain the bug in question in further detail as this is interesting Thanks Zebb On Tue, 21 Nov 2023, 21:36 Helge Deller, wrote: > > I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by > QEMU 8.0.2. > > Kernel: Linux 6.3.0-2-parisc parisc > > PA-RISC Linux kernels starting from 6.2 up until 6.7-rc1 have been lightly > tested > because I was mostly busy with enabling 64-bit hppa CPU support in qemu. > On Debian we currently use kernel 6.1-stable series which works fine with > your > testcase: "/bin/echo `seq 913`". > Starting with Linux kernel 6.7-rc2 the test works OK too, and there is a > whole > bunch of kernel patches (in 6.7-rc2) currently scheduled to be backported. > > I suggest you test again in 1-2 weeks (when the patches have been > incorporated > in the stable series kernels), or try a 6.1-stable or 6.7-rc2 kernel for > now. > > Helge > >
Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes
Yes, I did see it. But I couldn't reproduce it at the moment as I don't have access to my Linux tools On Wed, 22 Nov 2023, 01:39 Bruno Haible, wrote: > Zebediah Beck, > > You haven't read my bug report. > > Bruno > > > >
[no subject]
Good day sir/madam I'm a long time debian user but would like that contribute technical documentation to the community in thanks for your tireless work on this magnificent ecosystem. Thanks Zebb
Re: Request for instructions how to contribute with technical documentation
Thanks for the feedback! Please explain how to do diff? Thanks Zebb On Mon, 27 Nov 2023, 12:06 Steffen Möller, wrote: > Dear Zebb, > > Thank you for your kind offer to help. Debian technical documentation > somewhere may already have an answer to your question. I admit not to have > checked. But if you would please check that and find that info missing, > then please then send a diff to the authors of that document or a pull > request of where the document resides. > > You likely know that the documentation of Debian includes the > documentation provided by the developers of the software that Debian builds > and redistributes. So, if you are proficient with some software of Debian, > maybe you truly want to contribute to the documentation of that software > project, not of the documentation of Debian itself. With the typical > software documentation it may be fair to say that the graphical support is > lacking. So, if you know how to draw or how to make icons then you can be > of immediate strong help for many projects, not only for the Debian > infrastructure. > > Debian and larger software projects, like KDE or Blender, have regular > user meetings. Once you have started contributing, it seems fair to expect > that you are invited to personal meetings, which should then help to find > the right match of your personal skills with whatever bit is about to be > developed (and not yet documented). > > Best, > Steffen > > *Gesendet:* Donnerstag, 23. November 2023 um 21:59 Uhr > *Von:* "Zebediah Beck" > *An:* debian-devel@lists.debian.org > *Betreff:* Kein Betreff > Good day sir/madam > > I'm a long time debian user but would like that contribute technical > documentation to the community in thanks for your tireless work on this > magnificent ecosystem. > > Thanks > Zebb >
