Hi, Edouard Klein <e...@rdklein.fr> skribis:
> Maxim Cournoyer <maxim.courno...@gmail.com> writes: > >> Hi Ludovic, >> >> Ludovic Courtès <l...@gnu.org> writes: >> >>> Hi Edouard, >>> >>> Edouard Klein <e...@rdklein.fr> skribis: >>> >>>> I'm a huge fan of guix --container, and I created a system to use those >>>> by default for network services. But the VPS these services run on has >>>> only 2GB of RAM, and I just realized that a container, by default, >>>> requires at least 200MB. >>> >>> Ouch, confirmed: >>> >>> $ \time -v guix shell -C coreutils -- uname 2>&1 |grep 'Maximum resident' >>> Maximum resident set size (kbytes): 283048 >>> $ \time -v guix shell coreutils -- uname 2>&1 |grep 'Maximum resident' >>> Maximum resident set size (kbytes): 56588 >>> $ guix describe >>> Generation 297 Mar 24 2024 23:12:25 (current) >>> guix 28bc0e8 >>> repository URL: https://git.savannah.gnu.org/git/guix.git >>> branch: master >>> commit: 28bc0e870b4d48b8e3e773382bb0e999df2e3611 >>> >>> >>> As raingloom and Ricardo wrote, there’s a Guile process that keeps >>> waiting. >> >> Is there a technical reason for this? Couldn't we replace the >> current Guix process with 'exec', as hinted by Edouard? >> > > Raingloom did, I just reported the problem without investigating the > cause. Did what? I don’t think execing is possible in this case, unless we let the user’s process run as PID 1 inside its namespace (which isn’t recommended). See #:child-is-pid1? in ‘call-with-container’. I submitted a patch set to help a bit with that and related issues: https://issues.guix.gnu.org/70132 (I shouldn’t have said in the cover letter that it’s a boring patch series: I got zero comments. :-)) Thanks, Ludo’.
