CH> Thanks! It turned out the central issue was my system rebooted in the
CH> middle of a poll, leaving corrupt stuff in my echomail folders
CH> (determined this by trying to unzip everything and a bunch of things
CH> would not unzip) which was causing Mystic to soil the proverbial bed.
It sounds like you may have had some sort of corrupted packet of some type that
Mystic couldn't gracefully "fail" with. Do you still have the file MUTIL was
crashing on by chance or any of the files that were clogged up in your folder?
I would like to see if I could use it to reproduce the crash and handle it more
gracefully but I probably wouldn't have anything to go on without the actual
file that was causing MUTIL to crash.
CH> I will remember the killbusy method in the future; I was using a for
CH> loop to find the files and rm them previously.
Yeah this function exists for exactly this purpose. If Mystic gets shutdown in
the middle of doing stuff, sometimes things can get stuck in a weird state. The
killbusy command will clear all that mess up for you to and try to give you a
clean slate, but it should really only be needed in those circumstances. Mystic
is also supposed to "self-heal" after some period of time, but if a corrupted
packet was causing MUTIL to crash over and over it would never been able to do
that - the self healing of course would require it not shitting on itself
before it can heal lol :)
... No honey, I can't eat with the family. My computer gets lonely!
--- Mystic BBS v1.12 A47 2021/09/23 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)
|
