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)