I think it would be very helpful if Mystic could log automated acts that it takes when functions such as this one do something.

While I appreciate it may be recorded in the MUTIL logs I'm thinking a lot of stuff gets logged there (I tend to run things at Level 3 also to help debig stuff) and it can be quite a task to go through those logs to find out if something happened as a result of (let's say) running this function once a
day as part of a maint.ini process.

I was wondering if one logging text file could be created that summarized any key changes Mystic took as a result of an automated function being TRUE in
this function (or any other future functions)?

The file could log date/time/actions taken and could just be a copy of or
part of something already being written to the MUTIL log, if that made it easier.

Here's an imaginary log file I made up as I have not yet tested this new function.

+ 2020.03.02 00:07:44 Node 88 Session (HOLD) Errors (542) Days (7)
+ 2020.03.02 08:15:22 Node 17 set Inactive. Days (31)
+ 2020.03.02 08:15:23 Node 17 packets purged. Days (31)
+ 2020.03.02 08:15:27 Node 17 filebox (fsxnet_z21n1n117) purged. Days (31)

Thanks for considering.

--- Mystic BBS v1.12 A46 2020/02/29 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

+ 2020.03.02 00:07:44 Node 88 Session (HOLD) Errors (542) Days (7)
+ 2020.03.02 08:15:22 Node 17 set Inactive. Days (31)
+ 2020.03.02 08:15:23 Node 17 packets purged. Days (31)
+ 2020.03.02 08:15:27 Node 17 filebox (fsxnet_z21n1n117) purged. Days (31)

This is what the MUTIL log basically looks like now (it actually gives more detail than this I think). If you want to make that a separate log you can do so with MUTIL by simply changing the log filename. IE:

Create a tracker.ini and inside it just have the EchoNodeTracker with a loglevel of 3 pushing to tracker.log. Now you include "mutil tracker" in a weekly maint or something and it will keep a log of everything it does in tracker.log.

Then you can post that log weekly into your email or something and delete it, if you wish to have a notification of all the events that took place.

Would this cover what you're looking for? You can do this sort of thing with any MUTIL function really.

--- Mystic BBS v1.12 A46 2020/03/01 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 02 Mar 2020 at 03:08p, g00r00 pondered and said...

Would this cover what you're looking for? You can do this sort of thing with any MUTIL function really.

It would thanks, so yep ignore that request from me :)

--- Mystic BBS v1.12 A46 2020/02/29 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I have a node that shows as follows

91 Yes Jordan McGilvray / Coloss Jordan McGilvray 21:1/182 ───────────────────────────────────────────────────────────────────────────
Inactive: 2,895 days Last In: Never
Files Sent: 0 (0KB) Last Out: 01 Apr 2012 18:09
Received: 0 (0KB) Reset: Never
Crash Errors: 1,059

and the ini for the EchoNodeTracker is set with


reset_stats = 0

inactivity = 0

clear_outbound = false

crash_errors = 15
crash_days = 3

This does not set the node (which is set to CRASH) to HOLD

- Mar 05 22:01:51 EXEC EchoNodeTracker
+ Mar 05 22:01:51 Process: Echo Node Tracker
+ Mar 05 22:01:52 Results: 0 Reset, 0 Disabled, 0 Hold in 0.84s
+ Mar 05 22:01:52 Shutdown Normal (0)

I'm wondering why that may be? Could the clue be in the dated Last Out record?

--- Mystic BBS v1.12 A46 2020/02/29 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

This does not set the node (which is set to CRASH) to HOLD

- Mar 05 22:01:51 EXEC EchoNodeTracker
+ Mar 05 22:01:51 Process: Echo Node Tracker
+ Mar 05 22:01:52 Results: 0 Reset, 0 Disabled, 0 Hold in 0.84s
+ Mar 05 22:01:52 Shutdown Normal (0)

I'm wondering why that may be? Could the clue be in the dated Last Out record?

The only thing I can think of is that its not set to crash (which you said it was) or its broken. Maybe there is some sort of artifact from one of the
older prealphas before I changed the date format.

Would you be willing to send me your echonode.dat and I can try it? No
worries if not I will just try to duplicate the record myself so you don't
have to send it.

--- Mystic BBS v1.12 A46 2020/03/04 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 05 Mar 2020 at 04:59p, g00r00 pondered and said...

The only thing I can think of is that its not set to crash (which you
said it was) or its broken. Maybe there is some sort of artifact from
one of the older prealphas before I changed the date format.

Yep it's set to CRASH... I'll be in touch, thanks :)

--- Mystic BBS v1.12 A46 2020/03/04 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I have a node that shows as follows

This does not set the node (which is set to CRASH) to HOLD

I have reviewed everything and fixed an issue. Surprisingly nothing was wrong with the logic, it was just set up in a way that it only processed the HOLD logic if they were also expiring for days of inactivity. Fixed!

Here is the log after the fix when ran on the data you sent me:

+ Mar 06 20:39:27 Process: Echo Node Tracker
+ Mar 06 20:39:27 Setting mail to Hold for ID 36 (21:1/129)
+ Mar 06 20:39:27 Setting filebox to Hold for ID 36 (21:1/129)
+ Mar 06 20:39:27 Setting mail to Hold for ID 91 (21:1/182)
+ Mar 06 20:39:27 Setting filebox to Hold for ID 91 (21:1/182)
+ Mar 06 20:39:27 Setting mail to Hold for ID 123 (21:1/205)
+ Mar 06 20:39:27 Setting filebox to Hold for ID 123 (21:1/205)
+ Mar 06 20:39:27 Results: 0 Reset, 0 Disabled, 3 Hold in 0.05s

--- Mystic BBS v1.12 A46 2020/03/05 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 06 Mar 2020 at 08:41p, g00r00 pondered and said...

I have reviewed everything and fixed an issue. Surprisingly nothing was wrong with the logic, it was just set up in a way that it only processed the HOLD logic if they were also expiring for days of inactivity. Fixed!

I have just run this and concur, seeing the same results you did

+ Mar 06 20:39:27 Process: Echo Node Tracker
+ Mar 06 20:39:27 Setting mail to Hold for ID 36 (21:1/129)
+ Mar 06 20:39:27 Setting filebox to Hold for ID 36 (21:1/129)
+ Mar 06 20:39:27 Setting mail to Hold for ID 91 (21:1/182)
+ Mar 06 20:39:27 Setting filebox to Hold for ID 91 (21:1/182)
+ Mar 06 20:39:27 Setting mail to Hold for ID 123 (21:1/205)
+ Mar 06 20:39:27 Setting filebox to Hold for ID 123 (21:1/205)
+ Mar 06 20:39:27 Results: 0 Reset, 0 Disabled, 3 Hold in 0.05s

and mine

- Mar 10 21:39:01 EXEC EchoNodeTracker
+ Mar 10 21:39:01 Process: Echo Node Tracker
+ Mar 10 21:39:02 Setting mail to Hold for ID 36 (21:1/129)
+ Mar 10 21:39:02 Setting filebox to Hold for ID 36 (21:1/129)
+ Mar 10 21:39:02 Setting mail to Hold for ID 91 (21:1/182)
+ Mar 10 21:39:02 Setting filebox to Hold for ID 91 (21:1/182)
+ Mar 10 21:39:02 Setting mail to Hold for ID 123 (21:1/205)
+ Mar 10 21:39:02 Setting filebox to Hold for ID 123 (21:1/205)
+ Mar 10 21:39:02 Results: 0 Reset, 0 Disabled, 3 Hold in 1.12s

In this case I used

crash_errors = 15
crash_days = 3

Do you think when a rule is met a line in the log could state what was TRUE to cause the changed setting to be applied?

e.g. Crash Fail Days (7 > 3) | Connection Errors (45 > 15)

If I were to start posting this to BOT it would be more informational than
just saying that the change had happened, as it would explain why it happened as well.

--- Mystic BBS v1.12 A46 2020/03/09 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 06 Mar 2020 at 08:41p, g00r00 pondered and said...

I have reviewed everything and fixed an issue. Surprisingly nothing was wrong with the logic, it was just set up in a way that it only processed the HOLD logic if they were also expiring for days of inactivity. Fixed!

I also tested the following

inactivity = 45
clear_outbound = true

+ Mar 10 21:48:23 Results: 0 Reset, 9 Disabled, 0 Hold in 1.00s

A suggestion would be to delink the echomail areas and file bases from the nodes being made inactive as part of this process.

The tool is very good - thank you :)

--- Mystic BBS v1.12 A46 2020/03/09 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Do you think when a rule is met a line in the log could state what was TRUE to cause the changed setting to be applied?

I have added a print out that shows the number of attempts made and the
number of days they were unreachable. The other operations do give more
detail for some reason I didn't for the hold stuff.

I also removed the ID 1234 stuff because I didn't think it was that relevant and it made the lines too long. It should look something like:

Setting mail to Hold for 21:1/1 (21 crash errors, 7 days unreachable)

--- Mystic BBS v1.12 A46 2020/03/10 (Windows/64)
* Origin: Sector 7 (21:1/108)

A suggestion would be to delink the echomail areas and file bases from
the nodes being made inactive as part of this process.

I think if I do that I think I'd like to make it optional. I like the idea of being able to reactivate someone and they can pick up right where they left off without having to sort out what they were subscribed to.

Deleting them from the system does delink them (or should). I don't have access to my TODO list to add this right now but it should be added.
Hopefully I won't forget (I am on the move at the moment)

--- Mystic BBS v1.12 A46 2020/03/10 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 10 Mar 2020 at 04:57p, g00r00 pondered and said...

I have added a print out that shows the number of attempts made and the number of days they were unreachable. The other operations do give more

Setting mail to Hold for 21:1/1 (21 crash errors, 7 days unreachable)

Thanks! Yes I think this hits the mark and will help understanding as to why.

--- Mystic BBS v1.12 A46 2020/03/09 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

A suggestion would be to delink the echomail areas and file bases fro the nodes being made inactive as part of this process.

I think if I do that I think I'd like to make it optional. I like the idea of being able to reactivate someone and they can pick up right
where they left off without having to sort out what they were subscribed to.

Deleting them from the system does delink them (or should). I don't have access to my TODO list to add this right now but it should be added. Hopefully I won't forget (I am on the move at the moment)

OK thanks, yep agreed with 'optional' switch.

--- Mystic BBS v1.12 A46 2020/03/09 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 10 Mar 2020, g00r00 said the following...

Deleting them from the system does delink them (or should). I don't have access to my TODO list to add this right now but it should be added. Hopefully I won't forget (I am on the move at the moment)

Actually, I don't think it does. I was just looking at Hub 4 (Win 32) system, and when I look at the echomail exports from the message base, I'm seeing:
XXX UNKNOWN ID 42

Stay safe in your travels.


---

Black Panther(RCS)
Castle Rock BBS

--- Mystic BBS v1.12 A45 2020/02/18 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)

Actually, I don't think it does. I was just looking at Hub 4 (Win 32) system, and when I look at the echomail exports from the message base,

Its in the code to do it, so the intention is there. I just set up a temp echonode and linked it to a bunch of bases, then deleted the node in the node editor. I have confirmed they are removed from the bases they were tagged in.

I can see maybe something like what you're showing happening if a situation occurs where echomail is exporting at the same time you are trying to make adjustments to echomail nodes though.

--- Mystic BBS v1.12 A46 2020/03/10 (Windows/64)
* Origin: Sector 7 (21:1/108)

I have added a print out that shows the number of attempts made and t number of days they were unreachable. The other operations do give m

Setting mail to Hold for 21:1/1 (21 crash errors, 7 days unreachabl

Thanks! Yes I think this hits the mark and will help understanding as to why.

I have also added an "unlink" option in the next build too for the node deactivation. When set to true it will remove their file and message base subscriptions.

I'll try to get that uploaded in the next 30 minutes or so.

--- Mystic BBS v1.12 A46 2020/03/10 (Windows/64)
* Origin: Sector 7 (21:1/108)

On 12 Mar 2020, g00r00 said the following...

I can see maybe something like what you're showing happening if a situation occurs where echomail is exporting at the same time you are trying to make adjustments to echomail nodes though.

That is a good possibility. With the traffic flowing through that system, I could see where that could happen.


---

Black Panther(RCS)
Castle Rock BBS

--- Mystic BBS v1.12 A45 2020/02/18 (Linux/64)
* Origin: Castle Rock BBS - bbs.castlerockbbs.com (21:1/186)