If anyone is having any issues with the latest prealpha let me know.

I am gearing up to release A37 for New Years.

--- Mystic BBS v1.12 A37 2017/12/30 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Haven't seen any on my end.

On 13:47 30/12 , g00r00 wrote:

If anyone is having any issues with the latest prealpha let me know.

I am gearing up to release A37 for New Years.

--- Mystic BBS v1.12 A37 2017/12/30 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader

--- Mystic BBS/NNTP v1.12 A37 2017/12/30 (Linux/64)
* Origin: -=The ByteXchange BBS : bbs.thebytexchange.com=- (21:1/107)

On 12/30/17, g00r00 pondered and said...

If anyone is having any issues with the latest prealpha let me know.

I am gearing up to release A37 for New Years.

Yes, it seems a BSY issue tonight, have sent you logs to look at

--- Mystic BBS v1.12 A37 2017/12/30 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

I am gearing up to release A37 for New Years.

Yes, it seems a BSY issue tonight, have sent you logs to look at

This is a false alarm similar to the last report, as far as I can tell.

There is no error in the logs, no error in BUSY file alignment, and while MUTIL is refusing to run... It is properly doing so because you had active BINKP server connections:

21:14:55 MUTIL refuses to run because of BUSY files.

FIDOPOLL? Last exec was 21:05:58, not running
MIS? 3 connections of BINKP, #1 starts at 21:13:02, ends at 21:43:53
Conclusion: Proper MUTIL refusal because MIS had active transfers.

21:41:25 MUTIL refuses to run because of BUSY files.

Conclusion: Proper MUTIL refusal because MIS still had active transfers
(same session as above)

21:43:29 MUTIL refuses to run

Conclusion: Proper MUTIL refusal because MIS still had active transfers
(same session as last two)

MUTIL is going to run each time a session ends, but it will refuse to do anything until there are no active sessions. In this case, you had one
person downloading for 30 minutes which spanned all 3 times MUTIL refused to run.

--- Mystic BBS v1.12 A37 2017/12/30 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 12/31/17, g00r00 pondered and said...

Conclusion: Proper MUTIL refusal because MIS still had active transfers (same session as last two)

MUTIL is going to run each time a session ends, but it will refuse to do anything until there are no active sessions. In this case, you had one person downloading for 30 minutes which spanned all 3 times MUTIL
refused to run.

OK thanks that's helpful. And in this case it was me hatching a 59 Megabyte
art pack and that ties up BinkP connections for ages.. so as echomail comes
in from another node and other nodes are still pulling the file down on BinkP server MUTIL fires on an echomail.in and waits for 60 secs then abandons.

Something I'll need to be aware of when hatching large files and it will slow the process of tossing echomail from other nodes...

--- Mystic BBS v1.12 A37 2017/12/30 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 01/01/18, Avon pondered and said...

anything until there are no active sessions. In this case, you had o person downloading for 30 minutes which spanned all 3 times MUTIL refused to run.

OK thanks that's helpful. And in this case it was me hatching a 59 Megabyte art pack and that ties up BinkP connections for ages.. so as

I know how seeing this sort of stuff makes you smile so for your New Years
Eve viewing pleasure.

SERVER USER STATUS ORIGIN
ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
BINKP 21:1/114@fsxNet Throwback BBS 24.250.17.45
BINKP 21:1/128@fsxnet The Ouijaboard II 65.103.12.162
BINKP 21:1/126@fsxnet Twinkle BBS 2601:08C0:4280:1C81:020C:29F
BINKP 21:1/138@fsxnet Electronic Warfare BB 104.236.216.137
BINKP 21:1/199@fsxNet Clutch BBS 108.170.187.75
BINKP 21:1/143@fsxnet The Bridge 2001:44B8:4176:F100::0007
BINKP 21:1/162@fsxnet Razor's Domain 3.1415 104.191.182.7
BINKP 21:1/105@fsxnet flupH 75.109.135.35
BINKP 21:1/189@fsxnet Kernel Error Networks 2604:A880:0400:00D0::4BC4:10
BINKP 21:1/122@fsxnet Necronomicon BBS 76.118.118.197
BINKP 21:1/159@fsxnet The GateHouse BBS 45.72.176.222
BINKP 21:1/174@fsxnet The Zone BBS 71.72.9.255
BINKP 21:1/163@fsxnet dreamland bbs 162.205.72.214
BINKP 21:1/186@fsxNET Castle Rock BBS 67.61.21.181
BINKP 21:1/154@fsxnet Raiders Inc BBS 68.103.73.149
BINKP 21:2/100@fsxnet fsxHUB Tholian [NET2] 108.204.225.235

I had wound up the BinkP server to 25 ports and hatched out x 2 larger ANSI packs a day or so ago (the subject of my false alarm logs:)) This time I got
to 16 incoming connects simultaneously. If I time my hatching when a lot of nodes poll the HUB I have a feeling next time it will be more :) I really wanted to get to 20 but as some nodes finished pull the files down others arrived so the greatest maximum hit 16 this time.

I did find myself having to scroll up/down the connections window trying to keep count, not that easy to do, hence a past cosmetic request to put some dynamic info (total active connections) up on the MIS screen :) It's no biggy though just a nice to have.

Anywhoo... well done with all the changes to Mystic in 2017 it's been a big year for the development of the software and I appreciated your
responsiveness to feedback and suggestions along with the countless hours you have put in to your 20 year love affair with something a good section of the BBS community enjoys using / tinkering with.

Best, Paul

--- Mystic BBS v1.12 A37 2017/12/30 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

OK thanks that's helpful. And in this case it was me hatching a 59 Megabyte art pack and that ties up BinkP connections for ages.. so as echomail comes in from another node and other nodes are still pulling
the file down on BinkP server MUTIL fires on an echomail.in and waits
for 60 secs then abandons.

Something I'll need to be aware of when hatching large files and it will slow the process of tossing echomail from other nodes...

Yeah its a tough situation. When you have 3 sessions going, its going to trigger when each of them finish but it will only actually do something when the last session finishes.

The first thing it does when MUTIL runs is locks all of the nodes that do not currently have a session so that they cannot connect and attempt to transfer mail. Then it waits up to 60 seconds for the sessions that are open to end. If they end within 60 seconds, it processes mail. If they do not, it releases all of the locks and just says "I give up, boss!". The latter is what you saw 3 times because that one session took 30+ minutes while other sessions started and completed, each one triggering mail processing.

Maybe I can come up with some possible way to improve on how this works, but its a touchy situation with a system as busy as yours! We have to be careful we're not trying to toss messages into packets as they are being downloaded.

Happy new year :)

--- Mystic BBS v1.12 A37 2017/12/31 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

g00r00 wrote to Avon <=-

MUTIL is going to run each time a session ends, but it will refuse to
do anything until there are no active sessions. In this case, you had
one person downloading for 30 minutes which spanned all 3 times MUTIL refused to run.

Might have been me, there were two _huge_ files yesterday in my mail feed. :)


... A kid with a hammer will find that everything he sees needs pounding.
___ MultiMail/Win32 v0.49

--- Mystic BBS/QWK v1.12 A36 2017/12/04 (Raspberry Pi/32)
* Origin: The Bridge - bridge.vkradio.com (21:1/143)