The 'charm.log' for a unit logs all hook messages to stderr as 'ERROR', for example:
2012-03-13 13:50:10,845: hook.output@ERROR: Adding group `postfix' (GID 123) ...
2012-03-13 13:50:11,083: hook.output@ERROR: Done.
2012-03-13 13:50:11,227: hook.output@ERROR: Adding system user `postfix' (UID 115) ...
2012-03-13 13:50:11,349: hook.output@ERROR: Not creating home directory `/var/spool/postfix'.
2012-03-13 13:50:11,472: hook.output@ERROR: Creating /etc/postfix/dynamicmaps.cf
2012-03-13 13:50:11,476: hook.output@ERROR: Adding tcp map entry to /etc/postfix/dynamicmaps.cf
2012-03-13 13:50:11,690: hook.output@ERROR: Adding group `postdrop' (GID 124) ...
2012-03-13 13:50:11,733: hook.output@ERROR: Done.
2012-03-13 13:50:11,904: hook.output@ERROR: setting myhostname: xxx.compute-1.internal
2012-03-13 13:50:11,917: hook.output@ERROR: setting alias maps
2012-03-13 13:50:12,129: hook.output@ERROR: setting alias database
'grep ERROR charm.log | wc -l' reveals 72 lines of non-errors.
A lot of programs use stderr to output information that would otherwise disrupt a pipe on stdout, so I don't think it can safely be assumed it really is an error and reporting it as such is initially distracting.
Robert, agreed, I think printing on stderr should probably be logged at the INFO level like stdout. Setting as Low, but leaving as New to allow more time for others to comment.