/run/user/<id>/bb

/run/user/<id>/bb

[Slater, Joseph]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

TMPDIR is useful, but named sockets need a "short" pathname, so it it might be nice to have a RUNDIR, or something similar, under /run/user/<id>/bb.  Could this be added?  I would do it if the concept is accepted.

Joe


[-- Attachment #2: Type: text/html, Size: 592 bytes --]

Re: /run/user/<id>/bb

[Richard Purdie]

On Thu, 2019-01-03 at 23:57 +0000, Slater, Joseph wrote:
> TMPDIR is useful, but named sockets need a "short" pathname, so it it
> might be nice to have a RUNDIR, or something similar, under
> /run/user/<id>/bb.  Could this be added?  I would do it if the
> concept is accepted.

What problem are we solving with this?

I'm guessing problems with memory resident bitbake in envvars but I am
having to guess! :)

Cheers,

Richard

Re: /run/user/<id>/bb

[Mark Hatle]

On 1/7/19 8:56 AM, Richard Purdie wrote:
> On Thu, 2019-01-03 at 23:57 +0000, Slater, Joseph wrote:
>> TMPDIR is useful, but named sockets need a "short" pathname, so it it
>> might be nice to have a RUNDIR, or something similar, under
>> /run/user/<id>/bb.  Could this be added?  I would do it if the
>> concept is accepted.
> 
> What problem are we solving with this?
> 
> I'm guessing problems with memory resident bitbake in envvars but I am
> having to guess! :)

I'm assuming it's a combination of memory resident bitbake, and overall path
length in TMPDIR to the sockets.  Sockets have a maximum filesystem path length
(107 characters in Linux) that is much shorted then other components in the
system (4k or less).

The typical way people work around this is whenever you use a socket you cd to
the path of the socket and then open it relative to the current location.

in either the TMPDIR or RUNDIR type configuration, that 'cd ; open' type
behavior will still likely be needed.  So I'm not sure if RUNDIR actually fixes
anything when it comes to path length issues.  It just moves the socket to a
known location, from 'current' path.

...but with that said, there is some precedence in other tools for defining
RUNDIR based on an existing path (such as TMPDIR), but allowing it to be
overridden easily.  (Assuming there is a specific use that having a known RUNDIR
makes sense for.)

--Mark

> Cheers,
> 
> Richard
> 

Re: /run/user/<id>/bb

[richard.purdie]

On Mon, 2019-01-07 at 10:07 -0600, Mark Hatle wrote:
> On 1/7/19 8:56 AM, Richard Purdie wrote:
> > On Thu, 2019-01-03 at 23:57 +0000, Slater, Joseph wrote:
> > > TMPDIR is useful, but named sockets need a "short" pathname, so
> > > it it
> > > might be nice to have a RUNDIR, or something similar, under
> > > /run/user/<id>/bb.  Could this be added?  I would do it if the
> > > concept is accepted.
> > 
> > What problem are we solving with this?
> > 
> > I'm guessing problems with memory resident bitbake in envvars but I
> > am
> > having to guess! :)
> 
> I'm assuming it's a combination of memory resident bitbake, and overall path
> length in TMPDIR to the sockets.  Sockets have a maximum filesystem path length
> (107 characters in Linux) that is much shorted then other components in the
> system (4k or less).
> 
> The typical way people work around this is whenever you use a socket
> you cd to the path of the socket and then open it relative to the
> current location.

The code in bitbake already does that as it happens...

> in either the TMPDIR or RUNDIR type configuration, that 'cd ; open'
> type behavior will still likely be needed.  So I'm not sure if RUNDIR
> actually fixes anything when it comes to path length issues.  It just
> moves the socket to a known location, from 'current' path.

I'm hoping Joe can explain the problem rather than us guessing,
particularly as the code for where I thought the problem may be already
does a chdir().

Cheers,

Richard

Re: /run/user/<id>/bb

[Slater, Joseph]

Specifically, libassuan, which is used by gpg, puts named sockets under GPG_PATH and that is set by sign_rpm_ext.bbclass to be under TMPDIR, although we could override that.  I think that libassuan computes the absolute pathname to create the socket.  I admit that I did not look very hard at libassuan, but a fix did not seem immediately obvious.

Having a RUNDIR might not be a good idea, though, because it opens the issue of how it gets cleaned up if the user never logs out.

Joe


-----Original Message-----
From: richard.purdie@linuxfoundation.org [mailto:richard.purdie@linuxfoundation.org] 
Sent: Monday, January 07, 2019 9:31 AM
To: Hatle, Mark; Slater, Joseph; bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel] /run/user/<id>/bb

On Mon, 2019-01-07 at 10:07 -0600, Mark Hatle wrote:
> On 1/7/19 8:56 AM, Richard Purdie wrote:
> > On Thu, 2019-01-03 at 23:57 +0000, Slater, Joseph wrote:
> > > TMPDIR is useful, but named sockets need a "short" pathname, so
> > > it it
> > > might be nice to have a RUNDIR, or something similar, under
> > > /run/user/<id>/bb.  Could this be added?  I would do it if the
> > > concept is accepted.
> > 
> > What problem are we solving with this?
> > 
> > I'm guessing problems with memory resident bitbake in envvars but I
> > am
> > having to guess! :)
> 
> I'm assuming it's a combination of memory resident bitbake, and overall path
> length in TMPDIR to the sockets.  Sockets have a maximum filesystem path length
> (107 characters in Linux) that is much shorted then other components in the
> system (4k or less).
> 
> The typical way people work around this is whenever you use a socket
> you cd to the path of the socket and then open it relative to the
> current location.

The code in bitbake already does that as it happens...

> in either the TMPDIR or RUNDIR type configuration, that 'cd ; open'
> type behavior will still likely be needed.  So I'm not sure if RUNDIR
> actually fixes anything when it comes to path length issues.  It just
> moves the socket to a known location, from 'current' path.

I'm hoping Joe can explain the problem rather than us guessing,
particularly as the code for where I thought the problem may be already
does a chdir().

Cheers,

Richard

Re: /run/user/<id>/bb

[richard.purdie]

On Mon, 2019-01-07 at 20:48 +0000, Slater, Joseph wrote:
> Specifically, libassuan, which is used by gpg, puts named sockets
> under GPG_PATH and that is set by sign_rpm_ext.bbclass to be under
> TMPDIR, although we could override that.  I think that libassuan
> computes the absolute pathname to create the socket.  I admit that I
> did not look very hard at libassuan, but a fix did not seem
> immediately obvious.
> 
> Having a RUNDIR might not be a good idea, though, because it opens
> the issue of how it gets cleaned up if the user never logs out.

That as well as how we differentiate between multiple builds from the
same user or even different multiconfigs within the same build.

I suspect there are safer ways to handle this within TMPDIR even if we
have to patch things...

Cheers,

Richard