Re: stray files in go build / bob sandbox not empty

[Jonathan Perkin <jperkin%pkgsrc.org@localhost>]

* On 2026-07-10 at 11:30 BST, Greg Troxel wrote:

> Jonathan Perkin <jperkin%pkgsrc.org@localhost> writes:
>
> > * On 2026-07-09 at 23:21 BST, Greg Troxel wrote:
> >
> > >  go is escaping FAKE_HOME set up by pkgsrc
> >
> > Myself and wiz noticed something similar with I think cargo, and while
> > I didn't fully debug it I think it's caused by tools going directly to
> > getpwnam / pw_dir, so I'm not sure we can avoid it.
>
> I guess $someone can fix go; telemetry is a serious bug anyway.

Yeh, we should definitely be fixing these, just pointing out why 
FAKE_HOME may not always work.

> > >  some combination of leftover files in home and bob objecting to
> > >  polluted sandoxes
> >
> > The way to clean this up in bob is to add a hook so that it's removed
> > after every build, e.g.:
> >
> >   sandboxes = {
> >     hooks = {
> >       { action = "cmd",
> >         destroy = "rm -rf ${bob_sandbox_path}/home/gdt/.config/go" },
> >     }
> >   }
> >
> > or similar.
>
> Why doesn't sandbox deconfig work with the leftover crud that buggy
> packages leave?    Perhaps some kind of lost+found to be nuked later, as
> I would expect you don't want to rm.  I'm thinking of putting all that in
>
>  now = time()
>  ${bob_sandbox_path}/leftover/$now/
>
> which still leaves them.

My philosophy around sandbox management is to be as plain, simple, 
robust, and reliable as possible.  Unmounting file systems, killing 
processes, and running 'rm -rf' as root is not the place I want any kind 
of magic to be happening.

If anything is out of the ordinary, bob warns and leaves the user to 
clean up, and if there are legitimate leftovers that users will 
encounter due to their configuration then the action hooks are provided 
to ensure they can be handled automatically next time.

FWIW on both my macOS and SmartOS daily builds I only currently need one 
cleanup hook which is the qmail /var/qmail issue.  I think there are two 
main factors that cover the majority of this build leftover warts:

 * Enabling the build_user ensures that any leftovers from builds are
   removed by the default action that deletes the build_user home dir.

 * Making /var a tmpfs mount to avoid random leftovers there.

I don't remember the last time I had to manually clean up a failed 
sandbox on those hosts, other than 'bob dev' sessions where I created 
some files outside of those areas (and that's on me).

> Another approach is just to ignroe the message; it seems to not stop
> the new sandbox use.

You can, but the old sandbox will still be left lying around, bob will 
just skip it and use the next available id.

--
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com