I have a Raspberry Pi Zero. It has 512MiB of RAM. Hardly small even by
modern standards. The `cpan` command is basically useless on it.
In more detail: I cannot install anything with the `cpan`. It gets
OOM-killed.
Or, more specifically, if I use
$ cpan Some::Module
or
$ cpan
cpan> install Some::Module
Then it manages to download, unpack, build and test but then gets killed
after the test phase but before the install phase.
...
All tests successful.
Files=1, Tests=32, 0 wallclock secs ( 0.13 usr 0.02 sys + 0.36 cusr
0.08 csys = 0.59 CPU) Result: PASS
Lockfile removed.
Killed
More detail from `dmesg`:
[Mon Nov 13 21:51:44 2023] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=cpan,pid=31971,uid=999
[Mon Nov 13 21:51:44 2023] Out of memory: Killed process 31971 (cpan) total-vm:237996kB, anon-rss:151540kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:244kB oom_score_adj:0
However, I can use the `look` command and manually
$ perl Build.PL
$ perl Build && perl Build test && perl Build install
and that works just fine, no OOM-kill - even from within the `cpan`
shell while CPAN.pm is still running.
First off - I'm not looking to be told how to install stuff. I know how
I can install stuff on my machine - that isn't the point of this email.
See below.
The point of this email is two-fold:
1) We seem to have ended up in a situation where "Perl is unsuable"
on small-memory systems like Raspberry Pis ((Pies?)). I don't have
this problem with Node or Python or... really anything else. Just
Perl. This doesn't paint Perl in a good light on these platforms as
compared to other languages. It's not a good look for us.
2) What on earth is CPAN.pm doing after the test phase but before the
install phase that suddenly needs all this memory, anyway? I could
just write myself a small script to automate around using CPAN.pm
to only grab the tarball, then unpack it and run the build scripts
locally myself. And a bit of extra magic around that would recurse
dependencies and ... wait why on earth would I do that when that
is LITERALLY what CPAN.pm is supposed to be doing?
Perhaps if I hadn't said "don't tell me" above, some folks would
have told me to use cpanm instead? To you folks, I have one
question in reply - Why? More specifically, why is cpan (the
core-shipped and therefore always available, officially-blessed
tool) unable to do this task, but cpanm (a third-party needs extra
steps to install it itself presuming that an end-user even knows
it exists) seems to be the "better" version?
Can we fix this please?
Either find out and fix why CPAN.pm eats all that memory, or write and
supply *IN CORE* a better, more minimised tool, that works better in
this situation.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
modern standards. The `cpan` command is basically useless on it.
In more detail: I cannot install anything with the `cpan`. It gets
OOM-killed.
Or, more specifically, if I use
$ cpan Some::Module
or
$ cpan
cpan> install Some::Module
Then it manages to download, unpack, build and test but then gets killed
after the test phase but before the install phase.
...
All tests successful.
Files=1, Tests=32, 0 wallclock secs ( 0.13 usr 0.02 sys + 0.36 cusr
0.08 csys = 0.59 CPU) Result: PASS
Lockfile removed.
Killed
More detail from `dmesg`:
[Mon Nov 13 21:51:44 2023] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=cpan,pid=31971,uid=999
[Mon Nov 13 21:51:44 2023] Out of memory: Killed process 31971 (cpan) total-vm:237996kB, anon-rss:151540kB, file-rss:0kB, shmem-rss:0kB, UID:999 pgtables:244kB oom_score_adj:0
However, I can use the `look` command and manually
$ perl Build.PL
$ perl Build && perl Build test && perl Build install
and that works just fine, no OOM-kill - even from within the `cpan`
shell while CPAN.pm is still running.
First off - I'm not looking to be told how to install stuff. I know how
I can install stuff on my machine - that isn't the point of this email.
See below.
The point of this email is two-fold:
1) We seem to have ended up in a situation where "Perl is unsuable"
on small-memory systems like Raspberry Pis ((Pies?)). I don't have
this problem with Node or Python or... really anything else. Just
Perl. This doesn't paint Perl in a good light on these platforms as
compared to other languages. It's not a good look for us.
2) What on earth is CPAN.pm doing after the test phase but before the
install phase that suddenly needs all this memory, anyway? I could
just write myself a small script to automate around using CPAN.pm
to only grab the tarball, then unpack it and run the build scripts
locally myself. And a bit of extra magic around that would recurse
dependencies and ... wait why on earth would I do that when that
is LITERALLY what CPAN.pm is supposed to be doing?
Perhaps if I hadn't said "don't tell me" above, some folks would
have told me to use cpanm instead? To you folks, I have one
question in reply - Why? More specifically, why is cpan (the
core-shipped and therefore always available, officially-blessed
tool) unable to do this task, but cpanm (a third-party needs extra
steps to install it itself presuming that an end-user even knows
it exists) seems to be the "better" version?
Can we fix this please?
Either find out and fix why CPAN.pm eats all that memory, or write and
supply *IN CORE* a better, more minimised tool, that works better in
this situation.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/