[RFC][PATCH] Resolve an issue when using pipes to process data

[RFC][PATCH] Resolve an issue when using pipes to process data

[Mark Hatle]

I'm sending this as an RFC.  I know the patch works, but I think it highlights
a potentially larger issue in the system.

If we're processing data using shell pipes, the return code of a failed
process may end up being lost -- avoiding the regular error capture when
bitbake runs a task.

In this particular case, while working to fix a bug in pseudo we made an
error condition fatal (triggered an abort()), but buildhistory kept on
processing ignoring any issues had occurred.

Breaking up the processing into steps, things that 'could fail', and later
processing steps that shouldn't fail will give us more of an opportunity to
identify failures in the future and deal with them in a quicker manner,
then having to investigate log files for messages.

I'm suspecting we should run a janitor exercise against oe-core looking for
similar situations where we might be piping the data and potentially losing
return codes in the process.

Comments?

Mark Hatle (1):
  buildhistory.bbclass: Break up the find to catch failures

 meta/classes/buildhistory.bbclass | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.5.0

Re: [RFC][PATCH] Resolve an issue when using pipes to process data

[Mark Hatle]

(Had someone ask me where the patch is..)

Our wonderful corporate mail server sucks.. so the thread didn't get attached
with the patch.

This is the cover letter, the patch has the subject:
[RFC][PATCH] buildhistory.bbclass: Break up the find to catch failures

--Mark

On 2/9/16 9:41 AM, Mark Hatle wrote:
> I'm sending this as an RFC.  I know the patch works, but I think it highlights
> a potentially larger issue in the system.
> 
> If we're processing data using shell pipes, the return code of a failed
> process may end up being lost -- avoiding the regular error capture when
> bitbake runs a task.
> 
> In this particular case, while working to fix a bug in pseudo we made an
> error condition fatal (triggered an abort()), but buildhistory kept on
> processing ignoring any issues had occurred.
> 
> Breaking up the processing into steps, things that 'could fail', and later
> processing steps that shouldn't fail will give us more of an opportunity to
> identify failures in the future and deal with them in a quicker manner,
> then having to investigate log files for messages.
> 
> I'm suspecting we should run a janitor exercise against oe-core looking for
> similar situations where we might be piping the data and potentially losing
> return codes in the process.
> 
> Comments?
> 
> Mark Hatle (1):
>   buildhistory.bbclass: Break up the find to catch failures
> 
>  meta/classes/buildhistory.bbclass | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 

Re: [RFC][PATCH] Resolve an issue when using pipes to process data

[Christopher Larson]

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

On Tue, Feb 9, 2016 at 8:41 AM Mark Hatle <mark.hatle@windriver.com> wrote:

> I'm sending this as an RFC.  I know the patch works, but I think it
> highlights
> a potentially larger issue in the system.
>
> If we're processing data using shell pipes, the return code of a failed
> process may end up being lost -- avoiding the regular error capture when
> bitbake runs a task.
>
> In this particular case, while working to fix a bug in pseudo we made an
> error condition fatal (triggered an abort()), but buildhistory kept on
> processing ignoring any issues had occurred.
>
> Breaking up the processing into steps, things that 'could fail', and later
> processing steps that shouldn't fail will give us more of an opportunity to
> identify failures in the future and deal with them in a quicker manner,
> then having to investigate log files for messages.
>
> I'm suspecting we should run a janitor exercise against oe-core looking for
> similar situations where we might be piping the data and potentially losing
> return codes in the process.
>
> Comments?
>

Hmm, wonder if it'd be worth adding the ability to inject extra 'set'
options to the start of all emitted shell tasks, and make it obey SHELL, so
you could set SHELL=bash and set -o pipefail.

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

Re: [RFC][PATCH] Resolve an issue when using pipes to process data

[Richard Purdie]

On Tue, 2016-02-09 at 09:41 -0600, Mark Hatle wrote:
> I'm sending this as an RFC.  I know the patch works, but I think it
> highlights
> a potentially larger issue in the system.
> 
> If we're processing data using shell pipes, the return code of a
> failed
> process may end up being lost -- avoiding the regular error capture
> when
> bitbake runs a task.
> 
> In this particular case, while working to fix a bug in pseudo we made
> an
> error condition fatal (triggered an abort()), but buildhistory kept
> on
> processing ignoring any issues had occurred.
> 
> Breaking up the processing into steps, things that 'could fail', and
> later
> processing steps that shouldn't fail will give us more of an
> opportunity to
> identify failures in the future and deal with them in a quicker
> manner,
> then having to investigate log files for messages.
> 
> I'm suspecting we should run a janitor exercise against oe-core
> looking for
> similar situations where we might be piping the data and potentially
> losing
> return codes in the process.

We do also have a problem with this specific patch since it causes
setscene failures for certain "restore from sstate" secnarios where
pseudo-native might not be available yet it could try and execute it.

Currently it silently fails, which is obviously bad, but breaking the
builds completely is worse.

I've not looked into the details yet but I can't take the patch as is.

Cheers,

Richard