I had an issue last week where the script would derail and print to the second log file, but not the first one. That told me several things, the first of which was that the script was not halted, but continued to execute. So I had an issue where something was miscoded enough to the point that it would not write to the log file at all, but not broken to the point that the whole binary was kaput.
It occurs to me that maybe the best way to source the error, especially after the few fixes I have made, is to have the script actually send to console an active report on what it is doing while it is doing it. In that manner, I can see about where the breakage is.
I anticipate that the big thing I face is possible aliasing of the binaries I am using to build the script off of. For example, if the binary /bin/foo is aliased with a switch of /bin/foo -s (for "something") and I am not needing that something to be executed because I want to use -a for another thing, then the resulting command is /bin/foo -as and mucks up everything depending on what is aliased.
This means that I will need to review and set each of these binaries in the script individually or at the least unlink the aliasing while the script is running. I will be able to test this more fully later tonight, but at the moment, this is what I am seeing.
So for the second session, I will need to verify the locations and paths of the binaries being used or I will have to find a way to unset all aliasing.