handling script/init errors

handling script/init errors

[Marc Reilly]

Hi,

Rarely, one of the commands (related to hardware access) in our startup 
scripts fails, and the unit startup ends up bailing to a console prompt. 
(Which is only on debug port, so no appropriate user feedback) 
This would end up appearing to the user that nothing has happened, and will 
either run until batteries are drained (or removed) or a special reset 
sequence is done.

Is there a way to set up an error handler in the scripts? Ideally, a command 
or script that could be called if /bin/sh encounters an error. 

I started looking through hush.c but soon thought it better to consult with 
anyone who actually might know ... :)

It's not an urgent problem, as all the troublesome units so far present 
themselves before they're shipped out, but now a more urgent (thankfully 
simple) problem has emerged, so now is a good time to try fix it.

Note: we're using a version based of 2012.07

Cheers,
Marc

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: handling script/init errors

[Sascha Hauer]

Hi Marc,

On Tue, Nov 12, 2013 at 05:07:35PM +1100, Marc Reilly wrote:
> Hi,
> 
> Rarely, one of the commands (related to hardware access) in our startup 
> scripts fails, and the unit startup ends up bailing to a console prompt. 
> (Which is only on debug port, so no appropriate user feedback) 
> This would end up appearing to the user that nothing has happened, and will 
> either run until batteries are drained (or removed) or a special reset 
> sequence is done.
> 
> Is there a way to set up an error handler in the scripts? Ideally, a command 
> or script that could be called if /bin/sh encounters an error.

What would you consider an error? Is executing the 'false' command an
error?
Commands in scripts must be allowed to fail. You are supposed to catch
this via

if [ $? != 0 ]; then
	echo "something bad happened"
	exit 1
fi

Of course error handling in shell is very cumbersome, even more in a
restricted shell like hush. That's the reason I try to reduce the need
of shell scripts in barebox. Most things that "really need to work" are
better done in C.

Maybe you could implement a 'catch' command. It would execute a command
given as argument to the command. Something like:

CATCH_HANDLER=/env/bin/failure.sh
...
catch <command>

Then whenever <command> fails $CATCH_HANDLER would be executed.

Don't know if that makes sense, just an idea.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: handling script/init errors

[Marc Reilly]

Hi Sasha,

> > 
> > Is there a way to set up an error handler in the scripts? Ideally, a
> > command or script that could be called if /bin/sh encounters an error.
> 
> What would you consider an error? Is executing the 'false' command an
> error?
> Commands in scripts must be allowed to fail. You are supposed to catch
> this via
> 
> if [ $? != 0 ]; then
> 	echo "something bad happened"
> 	exit 1
> fi

"Error" is really a terrible, non-specific word. Sorry. 
And to make it worse I'm not really sure what the error, um, problem, truly 
is...

I scattered a few "false" commands in the init script and it continued onto 
the end, but when i added (on a board where there there is no bus #1):

{{{
# force reset audio dac in case audio playing during soft reset
 i2c_write -b 1 -a 0x47 -r 0x55 0x80
}}}

This causes the init script to just stop and drop to a prompt, assuming 
because bus #1 was not available. I haven't looked into how the errors/ return 
codes are different.

> 
> Of course error handling in shell is very cumbersome, even more in a
> restricted shell like hush. That's the reason I try to reduce the need
> of shell scripts in barebox. Most things that "really need to work" are
> better done in C.

I agree, especially "really need to work", (and that line above should have 
really been in C) ..
Although, one of the things that I've really loved about barebox is that 
ability to experiment and script with the shell, especially for basic testing.


> Maybe you could implement a 'catch' command. It would execute a command
> given as argument to the command. Something like:
> 
> CATCH_HANDLER=/env/bin/failure.sh
> ...
> catch <command>
> 
> Then whenever <command> fails $CATCH_HANDLER would be executed.
> 
> Don't know if that makes sense, just an idea.

I was initially thinking of something like bash's "set +e" or "trap" but I 
have neither good knowledge of how they work, or how they would/could be 
implemented in bareox.
(Just vague, fading memories :) )

Cheers,
Marc



_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: handling script/init errors

[Sascha Hauer]

On Tue, Nov 12, 2013 at 08:05:19PM +1100, Marc Reilly wrote:
> Hi Sasha,
> 
> > > 
> > > Is there a way to set up an error handler in the scripts? Ideally, a
> > > command or script that could be called if /bin/sh encounters an error.
> > 
> > What would you consider an error? Is executing the 'false' command an
> > error?
> > Commands in scripts must be allowed to fail. You are supposed to catch
> > this via
> > 
> > if [ $? != 0 ]; then
> > 	echo "something bad happened"
> > 	exit 1
> > fi
> 
> "Error" is really a terrible, non-specific word. Sorry. 
> And to make it worse I'm not really sure what the error, um, problem, truly 
> is...
> 
> I scattered a few "false" commands in the init script and it continued onto 
> the end, but when i added (on a board where there there is no bus #1):
> 
> {{{
> # force reset audio dac in case audio playing during soft reset
>  i2c_write -b 1 -a 0x47 -r 0x55 0x80
> }}}
> 
> This causes the init script to just stop and drop to a prompt, assuming 
> because bus #1 was not available. I haven't looked into how the errors/ return 
> codes are different.

hush used to interpret return values from commands < 0 as 'exit'. This
changed with this commit:

| commit 16edced39ecf4c316179b72c01af249f85b36218
| Author: Sascha Hauer <s.hauer@pengutronix.de>
| Date:   Fri Aug 10 12:40:01 2012 +0200
| 
|     hush: Make exit a shell builtin
|     
|     'exit' used to do its job by returning value < 0. This is a sign
|     for hush that 'exit' is executed. This has problems:
|     
|     - Often commands accidently return a negative value. This causes
|       the shell to exit.
|     - execute_binfmt returns a negative value when it does not find
|       a binary to execute. This again causes the shell to exit.
|       Returning a negative error value seems to be the right thing
|       to do, but catching this in the shell would mean that the exit
|       command does not work anymore.
|     - if called without arguments exit is supposed to return the code
|       of the last command. As a command exit has no access to this code.
|     
|     This patch changes exit to be a builtin and also fixes the last return
|     code problem. While at it, update the help text.
|     
|     Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Probably the patch above introduced problems of its own fixed in later
commits, so if your device is in production you're better off looking
at i2c_write. I assume it returns a negative error value under some
circumstances. Let it return 1 instead.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: handling script/init errors

[Marc Reilly]

Hi,

 
> hush used to interpret return values from commands < 0 as 'exit'. This
> 
> changed with this commit:
> | commit 16edced39ecf4c316179b72c01af249f85b36218
> | Author: Sascha Hauer <s.hauer@pengutronix.de>
> | Date:   Fri Aug 10 12:40:01 2012 +0200
> | 
> |     hush: Make exit a shell builtin
> |     
> |     'exit' used to do its job by returning value < 0. This is a sign
> |     for hush that 'exit' is executed. This has problems:
> |     
> |     - Often commands accidently return a negative value. This causes
> |     
> |       the shell to exit.
> |     
> |     - execute_binfmt returns a negative value when it does not find
> |     
> |       a binary to execute. This again causes the shell to exit.
> |       Returning a negative error value seems to be the right thing
> |       to do, but catching this in the shell would mean that the exit
> |       command does not work anymore.
> |     
> |     - if called without arguments exit is supposed to return the code
> |     
> |       of the last command. As a command exit has no access to this code.
> |     
> |     This patch changes exit to be a builtin and also fixes the last return
> |     code problem. While at it, update the help text.
> |     
> |     Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> 
> Probably the patch above introduced problems of its own fixed in later
> commits, so if your device is in production you're better off looking
> at i2c_write. I assume it returns a negative error value under some
> circumstances. Let it return 1 instead.

Thanks!

In commands/i2c.c: I changed all "return -ENODEV;" to "return COMMAND_ERROR" 
and the scripts keep executing.

This fixed it for our version, I'll check if its relevant to current version 
and send in a patch soon.

Cheers,
Marc




_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: handling script/init errors

[Sascha Hauer]

On Wed, Nov 13, 2013 at 05:51:28PM +1100, Marc Reilly wrote:
> Hi,
> 
>  
> > hush used to interpret return values from commands < 0 as 'exit'. This
> > 
> > changed with this commit:
> > | commit 16edced39ecf4c316179b72c01af249f85b36218
> > | Author: Sascha Hauer <s.hauer@pengutronix.de>
> > | Date:   Fri Aug 10 12:40:01 2012 +0200
> > | 
> > |     hush: Make exit a shell builtin
> > |     
> > |     'exit' used to do its job by returning value < 0. This is a sign
> > |     for hush that 'exit' is executed. This has problems:
> > |     
> > |     - Often commands accidently return a negative value. This causes
> > |     
> > |       the shell to exit.
> > |     
> > |     - execute_binfmt returns a negative value when it does not find
> > |     
> > |       a binary to execute. This again causes the shell to exit.
> > |       Returning a negative error value seems to be the right thing
> > |       to do, but catching this in the shell would mean that the exit
> > |       command does not work anymore.
> > |     
> > |     - if called without arguments exit is supposed to return the code
> > |     
> > |       of the last command. As a command exit has no access to this code.
> > |     
> > |     This patch changes exit to be a builtin and also fixes the last return
> > |     code problem. While at it, update the help text.
> > |     
> > |     Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > 
> > Probably the patch above introduced problems of its own fixed in later
> > commits, so if your device is in production you're better off looking
> > at i2c_write. I assume it returns a negative error value under some
> > circumstances. Let it return 1 instead.
> 
> Thanks!
> 
> In commands/i2c.c: I changed all "return -ENODEV;" to "return COMMAND_ERROR" 
> and the scripts keep executing.
> 
> This fixed it for our version, I'll check if its relevant to current version 
> and send in a patch soon.

This shouldn't be needed in current barebox. The commands now can return
negative error values without causing the shell to exit.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox