Re: I've got a pkg 2.3.1 "pkg-static autoremove" that has grown to have over 1 GiByte of RAM resident after more than 77 minutes of cpu time

Unfortunately, I have to confirm your observation, but on 14.3-RELEASE-p2
on amd64.

As pkg's curl fetcher seems buggy beyond repair, the only way to finish the
installation of a planned FreeBSD small  server farm seems to use pkg's
stdio/file methods.
To save the project and avoid migration to Linux only because of this
long-standing pkg bug  "pkg: An error occurred while fetching package: No
error", which tends to appear unpredictably and is a real FreeBSD
showstopper because when it appears first, from then on it appears always,
I just set up a poudriere server with 20 cores at 3GHz and 256GB RAM. to
make the repos available via NFS.

Poudriere ran fine for a few minutes until it stopped for a loooong time.
Maybe 20 minutes the machine's drives were quiet. No SSH output.
Then I looked at the console, and top showed 5 or 6 pkg-static processes,
each with between 99.97 and 100.x CPU load.
Unfortunately, suddenly the machine awakened again from this pkg-static
freeze, so I could not get a full ps listing with more information, or even
a truss output.


On Sun, Sep 14, 2025 at 6:39 PM Mark Millard <marklmi@yahoo.com> wrote:

> [Some prior testing was also seeing such for pkg, not just pkg-static .]
>
> The context here is a armv7 chroot on an aarch64 system,
> in case that turns out to matter.
>
> # pkg-static -v
> 2.3.1
>
>
> For reference:
>
> load: 1.44  cmd: pkg-static 57217 [running] 4856.83r 4619.81u 2.24s 99%
> 1056180k
>
> ..PID   JID USERNAME    PRI NICE     SIZE       RES STATE    C   TIME
>  CPU COMMAND
> 57217     0 root        141    0   1096Mi    1038Mi CPU3     3  78:07
> 100.00% pkg-static autoremove
>
> The boot system:
>
> # uname -apKU
> FreeBSD aarch64-main-pbase 16.0-CURRENT FreeBSD 16.0-CURRENT
> main-n280292-3c60ea77649d GENERIC-NODEBUG arm64 aarch64 1600000 1600000
>
> Inside the chroot:
>
> # uname -apKU
> FreeBSD aarch64-main-pbase 16.0-CURRENT FreeBSD 16.0-CURRENT
> main-n280292-3c60ea77649d GENERIC-NODEBUG arm armv7 1600000 1600000
>
> # truss -p 57217
> freebsd32_mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926179328 (0x37346000)
> freebsd32_mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926199808 (0x3734b000)
> freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926220288 (0x37350000)
> freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926224384 (0x37351000)
> freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926236672 (0x37354000)
> freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926240768 (0x37355000)
> freebsd32_mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926244864 (0x37356000)
> freebsd32_mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926265344 (0x3735b000)
> freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926285824 (0x37360000)
> freebsd32_mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926298112 (0x37363000)
> freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926318592 (0x37368000)
> freebsd32_mmap(0x0,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926330880 (0x3736b000)
> freebsd32_mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926359552 (0x37372000)
> freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 926380032 (0x37377000)
> . . .
>
> No other activity reported by truss, other than freebsd32_mmap use,
> at least for what i looked at.
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>