From: nospam.Chris.Hizny@f420.n105.z1.fidonet.org

This was a problem for me on A46. I had hoped an upgrade to A47 would make a difference and it doesn't appear to.

2021.28.09 16:00:10 MUTIL 000 Runtime error 216

What is this?

The effect is the same when I stop and restart mis and the poll jobs (about every 5 minutes, one for each network) runs. The first poll will work okay, but then subsequently every poll fails:

+ 2021.09.28 16:00:07 1-Connecting to net1.fsxnet.nz on port 24556
+ 2021.09.28 16:00:07 1-Using address 219.89.83.33
+ 2021.09.28 16:00:08 1-Connected by IPV4 to 219.89.83.33
+ 2021.09.28 16:00:08 1-System Agency + Risa HUB
+ 2021.09.28 16:00:08 1-SysOp Paul Hayton
+ 2021.09.28 16:00:08 1-Location Dunedin, New Zealand
+ 2021.09.28 16:00:08 1-Mailer binkd/1.1a-112/Linux binkp/1.1
+ 2021.09.28 16:00:08 1-Receiving: 53397b12.we0 (849 bytes)
+ 2021.09.28 16:00:09 1-Session ended (0 sent, 1 rcvd, 0 skip)
+ 2021.09.28 16:00:10 Polled 1 systems

--------------------- POLL v1.12 A47 2021/09/24 Tue, Sep 28 2021 (loglevel 1) + 2021.09.28 16:05:07 Poll BINKP node via address lookup: 21:1/10
+ 2021.09.28 16:05:09 Polled 0 systems

(all subsequent polls will show "Polled 0 systems"). It doesn't appear to be one network. Depending on what part of the hour it is, it will always poll whatever network is scheduled correctly once, and then fail for all subsequent ones.

I do not know if this is normal or not, but the other thing that happens is .bsy files appear in a whole bunch of my echomail/out folders:

mystic@shibboleths:/mystic$ find . -name *.bsy ./echomail/out/fidonet.001/00da02bc.bsy ./echomail/out/agoranet.02e/0001009c.bsy
./echomail/out/tqwnet.539/00030064.bsy
./echomail/out/micronet.26a/012c0001.bsy ./echomail/out/spooknet.2bc/00640000.bsy
./echomail/out/primary/00010064.bsy
./echomail/out/primary/0001000a.bsy
./echomail/out/metronet.019/00190000.bsy ./echomail/out/weednet.1a4/00020001.bsy
./semaphore/mutil.bsy
./semaphore/mis.bsy

Note also that mutil.bsy stays there even though mis is not running between polls; I assume this runtime error causes it to die before it can remove that file.

The mutil.log file shows this:

+ Sep 28 16:10:25 Waiting for BUSY nodes
+ Sep 28 16:11:25 Results: Cannot import. Some nodes are BUSY in 60.06s
! Sep 28 16:11:25 Status: FATAL
+ Sep 28 16:11:25 Process: Importing EchoMail
+ Sep 28 16:11:25 Waiting for BUSY nodes
+ Sep 28 16:12:25 Results: Cannot import. Some nodes are BUSY in 60.06s
! Sep 28 16:12:25 Status: FATAL
+ Sep 28 16:12:25 Process: Merging Nodelists
+ Sep 28 16:12:25 Results: Merged 0 of 0 nodelist(s) in 0.00s
+ Sep 28 16:12:25 Shutdown Normal (0)


Currently dead in the water and unsure how to proceed.

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: nospam.Paul.Hayton@f100.n770.z3.fidonet.org

On 28 Sep 2021 at 09:11a, Chris Hizny pondered and said...

I do not know if this is normal or not, but the other thing that happens is .bsy files appear in a whole bunch of my echomail/out folders:

If you run 'mis poll killbusy' but close MIS down first before you do

Then restart and see how you go.

Best, Paul

... A black cat crossing your path signifies that the animal is going somewhere

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: nospam.g00r00@f215.n129.z1.fidonet.org

Thanks! It turned out the central issue was my system rebooted in the middle of a poll, leaving corrupt stuff in my echomail folders
(determined this by trying to unzip everything and a bunch of things
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.

I will remember the killbusy method in the future; I was using a for
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!

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: nospam.Chris.Hizny@f860.n218.z1.fidonet.org

If you run 'mis poll killbusy' but close MIS down first before you do
Then restart and see how you go.

Thanks! It turned out the central issue was my system rebooted in the middle of a poll, leaving corrupt stuff in my echomail folders (determined this by trying to unzip everything and a bunch of things would not unzip) which was causing Mystic to soil the proverbial bed. As it crashed, it was leaving those .bsy files behind. I cleaned out my echomail folders and now it seems to be humming along. I am describing this here just in case someone else searches on the problem in the future.

I will remember the killbusy method in the future; I was using a for loop to find the files and rm them previously.

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)

From: nospam.Chris.Hizny@f860.n218.z1.fidonet.org

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

I had hoped one of my automated backups had copies when I went to sleep in the middle of the crisis, but apparently they don't. Next time I will save them.
I didn't think much of the situation when it occurred since it was my fault.

In any case, things are working fine now.

Thanks for your response, and all of your work on Mystic all these years. I appreciate it.

--- SoupGate-Win32 v1.05
* Origin: www.darkrealms.ca (1:229/2)