Hi Jack,
On 06/ 7/10 09:21 PM, Jack Schwartz wrote:
[...]
15454 pkg install failure in im_pop did not abort DC and AI
in which case AI does not abort if there is a failure during
transfer mode.
Is this what might cause the failure you encountered ?
Yes, well sort of... I caused a failure on purpose by removing
babel-install and SUNWcsd from the manifest. I saw lots of pkg errors
as I expected, but then the ICTs ran to copy the log files afterward.
I suspect that the directory the logfiles are copied to were part of
the packages or incorporations I didn't install.
I agree. Since you saw 'pkg install' failures, I assume fix for 15454
will address this.
But to answer your question, a failed pkg install attempt should have
halted the process before the ICTs tried to copy the logfiles. The
right things should happen here when 15454 is fixed.
Seems like the right things will happen even if im_pop succeeds but
some subsequent finalizer script fails. The install should stop
before the ICTs would attempt to copy the logfiles.
So it sounds like what I was planning on doing, checking for existence
of /a before copying /tmp/install_log, is enough. If /a exists,
ls_transfer will create the directories to copy the logfile. If it
doesn't, nothing will happen and no additional errors will be
emitted; in this case AI will have failed, the system will not be
rebooted, and one can inspect the install_log in /tmp.
Do you agree?
Yes. That sounds good.
Seems like the ICT should also not try to copy its logfiles if their
target directory doesn't exist.
To be honest, I was assuming that we can't end up there modulo the
bug above -
this is the reason why I am trying understand what lead to that failure.
The copy attempts introduce the kind of error message noise that
we were trying to avoid.
One possibility I could think about how we might end up with noise
messages
emitted by ict_transfer_logs() is bug
11500 "auto-install used with non-default -p (manifest) option causes
ict_transfer_logs errors.
But this is slightly different problem - since some of source files
might not
exist, ict_transfer_logs() should be more tolerant and check for
existence
of log files before it tries to copy them.
However, I am not sure if that bug might be triggered by some
of DDU scenarios.
This shouldn't be triggered by DDU scenarios, but I introduced a
deliberate failure which played into the 11500 scenario.
ok. Thank you for clarifying this.
Jan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
