Eejz,

I was suffering from an occasional unresponsive Mystic Docker instance. Causes were multiple issues:

- too many connections to port 22/23 due to portscanners
+ causing Mystic to respond only with BUSY
- my scripts failing and causing the node to freeze
- various server issues which caused ssh/telnet to be unresponsive

So, I was breaking my brain how to externally check if connection to the server was possible.

I wrote a script which does the following:
- Retrieves IP from Mystic Docker
- Checks if the server responds with BUSY
- Checks if with a timed delay we can find the ASCII string
+ ASCII is returned when connecting to mystic and not responding to the
detecting terminal command
- When required it sends a restart to the Mystic Docker

If anybody wants to make their Synology Docker more failsafe, or wants to adapt this script to send other commands, feel free.

https://github.com/opicron/mysticbbs/blob/master/src/mystic-test.sh

oP!

... Using PKZIP Version 2.04zzzzzzzzzzz

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

On 06 Feb 2025, opicron said the following...

- When required it sends a restart to the Mystic Docker

nice, now it can reboot in the middle of maintenance, message tossing, etc..

and it'll boot whoever is online if (say) 3 nodes are junked and one is a user

- too many connections to port 22/23 due to portscanners
+ causing Mystic to respond only with BUSY
- my scripts failing and causing the node to freeze
- various server issues which caused ssh/telnet to be unresponsive

why are you having these problems? why not try and solve those instead?

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

- When required it sends a restart to the Mystic Docker

nice, now it can reboot in the middle of maintenance, message tossing, etc and it'll boot whoever is online if (say) 3 nodes are junked and one is a

Yep, all true! And I am fully aware, although the downsides are more severe. Not being able to toss, poll, connect for hours on end or when I finally see an issue. And an disconnect when all nodes are busy, sometimes booting someone, Ill take that inconvenience over the other negative points.

Do note that this occured sometimes in a half hour, sometimes after a few hours.

why are you having these problems? why not try and solve those

instead?

When I was running Mystic a46 there werent any issues. This all
occured when moving to a48/a49. It must be my server configuration together with that version, as nothing else changed.

I need a new docker but I haven't the time to set that up any time soon. If you have a good lead/dockerfile I am all ears.

Thanks for your insight ^^, wouldnt you take this solution seeing the time and benefits?

oP!

... There is one God, but which one is He?

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

On 07 Feb 2025, opicron said the following...

When I was running Mystic a46 there werent any issues. This all
occured when moving to a48/a49. It must be my server configuration together with that version, as nothing else changed.

why not run a46? is there something significant you can't live without?

Thanks for your insight ^^, wouldnt you take this solution seeing the
time and benefits?

no.

http://kirin.dcclost.com/~alex/opicron.c

i tested this a bit but i can't do everything first try ;) maybe a second set of eyes will help. it decouples server connections from mystic node connections.. so even if 1000 people connect at the same time only the one that hits 'ESCAPE' will spawn an actual mystic process/use a node..

change line 138 to the directory mystic is in and build with

gcc opicron.c -o opicron

in MIS you'll have to swap the telnet server to a different port, or disable
it entirely. obv MIS would still run for binkp, events, SSH, etc..

if that works for a while and instead hammering SSH is what causes it, well, maybe libssh can be made to do the same thing this does..

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

why not run a46? is there something significant you can't live without?

Yeah, a lot of added functionality-- widescreen being one which is really nice.

http://kirin.dcclost.com/~alex/opicron.c

I had a look, thank you for the lead! Not sure how I would get this to work. However, you did give me an idea. If I check TERMTYPE in Mystic connect.mps
I can kick the connection if termtype is ASCII. Which is the usual one for
the bots it seems.

Thx for some giving some energy, I changed my reset scripts to send me more detailed information through Slack and I am debugging the issue which occurs.

So far I see that every random period the following command takes 99% CPU for about 30 seconds up to 2:30 mins: "./mystic -T+".

Anybody know what this command does and why its triggering a high CPU load?

oP!

... I used to watch TV, then I bought a modem.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

So far I see that every random period the following command takes 99%
CPU for about 30 seconds up to 2:30 mins: "./mystic -T+".

Anybody know what this command does and why its triggering a high CPU load?

oP!

Looking at the online Mystic Wiki -> Overview -> Mystic Ecosystem ->
MYSTIC -T# This specifies the number of minutes the user will be
permitted to use this session. Ex: -T60 limits the user
to only an hour even if they have many hours of time left

Not a complete answer, but something to get started with.

HTH,

|11ogg
|11SysOp, Altair IV BBS
|11altairiv.ddns.net:2323

--- Mystic BBS v1.12 A49 2024/05/29 (Windows/64)
* Origin: Altair IV BBS (21:2/147)

So far I see that every random period the following command takes 99% CPU for about 30 seconds up to 2:30 mins: "./mystic -T+".
Anybody know what this command does and why its triggering a high CPU load?

Looking at the online Mystic Wiki -> Overview -> Mystic Ecosystem -> MYSTIC -T# This specifies the number of minutes the user will be

Thanks for the directional kick-- let me sleep on it, maybe I get lucky ^^

oP!

... Contains less than 2% U.S. RDA for this echo

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

On 10 Feb 2025, opicron said the following...

I had a look, thank you for the lead! Not sure how I would get this to work. However, you did give me an idea. If I check TERMTYPE in Mystic connect.mps I can kick the connection if termtype is ASCII. Which is the usual one for the bots it seems.

yeah that's what i currently do. just dump a message "this bbs requires an ansi capable terminal," list off a few of them and hangup. on a47 though..

ascii.mps:

Begin
DispFile('answer') // replacing prompt 0 .. duno how your login flow goes
// this either shows a greeting logo or an ascii logo
// answer.ans or answer.asc
If Graphics = 0 then Begin
Write ('|CR USE mTelnet');
Write ('|CR BYE ASCII USER');
HangUp;
Exit;
End;

Write('|PA');

DispFile('preuser'); // ansi with user/pass boxes or whatever
Write('|[X09|[Y14 ..'); // position input, change input colors, etc
End;

compile mpl and replace prompt 0 with !ascii :)

there's probably a lot you could cram in prompt 0

Thx for some giving some energy, I changed my reset scripts to send me more detailed information through Slack and I am debugging the issue which occurs.

right on :) yeah just kinda sucks to see mystic in limbo needing workarounds..

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

On 10 Feb 2025, fusion said the following...

ascii.mps:

meh forgot about connect.mps ;)

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

Hey opicron!

On Mon, Feb 10 2025 19:59:24 -0600, you wrote:

I had a look, thank you for the lead! Not sure how I would get this
to work. However, you did give me an idea. If I check TERMTYPE in
Mystic connect.mps I can kick the connection if termtype is ASCII.
Which is the usual one for the bots it seems.

Another option, in Mystic's configuration, you can set the emulation to ANSI only (instead of "Detect" or whatever the default is), and that should hang up on them if they're using anything but ANSI. It will also display a screen or some text stating that fact.

So far I see that every random period the following command takes 99%
CPU for about 30 seconds up to 2:30 mins: "./mystic -T+".

Anybody know what this command does and why its triggering a high CPU
load?

If you don't know what that command does, why are you running it?

I've never had to use that switch in the 20+ years I've used Mystic. So I can't imagine it's anything useful..?

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

So far I see that every random period the following command takes 99% CPU for about 30 seconds up to 2:30 mins: "./mystic -T+".

Anybody know what this command does and why its triggering a high CPU load?

If you don't know what that command does, why are you running it?

I've never had to use that switch in the 20+ years I've used Mystic. So I imagine it's anything useful..?

Thats the thing, I am not running it :). It like Mystic runs it itself time to time. Not a single bash script or event does anything remotely like that command.

oP!

... Both of his feet are firmly planted in the air.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

Hey fusion!

On Mon, Feb 10 2025 22:54:46 -0600, you wrote:

right on :) yeah just kinda sucks to see mystic in limbo needing workarounds..

Pretty sure if you force ANSI instead of using detection, it does basically the same thing as your MPL script does without any "workarounds."

However, most people probably stuff a "hit escape twice" mod in there too, so maybe something is blocking Mystic from doing what it's supposed to do there.

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

Hey opicron!

On Tue, Feb 11 2025 06:59:48 -0600, you wrote:

I've never had to use that switch in the 20+ years I've used Mystic.
So I imagine it's anything useful..?

Thats the thing, I am not running it :). It like Mystic runs it
itself time to time. Not a single bash script or event does anything remotely like that command.

That's definitely wierd, and something I've never heard of happening to anyone or had happen to me.

How are you running Mystic (daemon, server, etc)?

Do you have time limits set?

Do you have it setup to kick users/force offline when an event runs?

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 10 Feb 2025, Accession said the following...

On Mon, Feb 10 2025 22:54:46 -0600, you wrote:

right on :) yeah just kinda sucks to see mystic in limbo needing workarounds..

Pretty sure if you force ANSI instead of using detection, it does basically the same thing as your MPL script does without any "workarounds."

the "workarounds" here were referring to MIS getting into a state it won't accept connections, requiring his script to restart the docker image.

somewhere between the bot being allowed to connect, dumping whatever it does at the mystic login prompt, and then getting booted for incorrect passwords or idle timeout, is causing MIS or mystic to mark the node BUSY permanently, among other issues.

that's the only problem. it doesn't really matter whether or how we boot the user for not having ANSI. what if i want to allow non-ANSI users? sync does.. mystic does too, but the bots are breaking the server.. it's a bug ;)

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

Hey fusion!

On Wed, Feb 12 2025 00:43:42 -0600, you wrote:

Pretty sure if you force ANSI instead of using detection, it does
basically the same thing as your MPL script does without any
"workarounds."

the "workarounds" here were referring to MIS getting into a state it
won't accept connections, requiring his script to restart the docker
image.

I'm fairly certain this is what I replied to:

[ snip ]

I had a look, thank you for the lead! Not sure how I would get this
to work. However, you did give me an idea. If I check TERMTYPE in
Mystic connect.mps I can kick the connection if termtype is ASCII.
Which is the usual one for the bots it seems.

yeah that's what i currently do. just dump a message "this bbs
requires an ansi capable terminal," list off a few of them and
hangup. on a47 though..

<script was posted doing exactly what I wrote Mystic could do without a script> <workarounds were mentioned>

[ snip ]

somewhere between the bot being allowed to connect, dumping whatever
it does at the mystic login prompt, and then getting booted for
incorrect passwords or idle timeout, is causing MIS or mystic to mark
the node BUSY permanently, among other issues.

What I wrote in my reply was a possible configuration option (as in something the BBS offers, rather than using a "workaround"), which doesn't go as far as the login prompt or passwords and idle timeouts. This happens as soon as you connect, the software version and copyright is displayed and then it displays the "Detecting Emulation" prompt (which this prompt can also be changed to do whatever you want it to do).

that's the only problem. it doesn't really matter whether or how we
boot the user for not having ANSI. what if i want to allow non-ANSI
users? sync does.. mystic does too, but the bots are breaking the
server.. it's a bug ;)

If you wanted to allow non-ansi callers, then you wouldn't have wrote that script you pasted, which is what I was replying to, now would you?

So you're basically saying that because Mystic doesn't have pfsense features/functionality built into it, it's buggy? I can't imagine why g00r00 disappears from the scene for years at a crack. lol

I'd imagine that's probably your (or their) solution, though. Use pfsense or something similar to filter telnet (or whatever ports you have open) before Mystic loads to take care of bots that may connect multiple times from the same IP address at the same time that could possibly hang the software.

This is probably what you (or anyone) would do with any other BBS software besides Synchronet, right?

Synchronet may have these features built in, but how many other BBS softwares have that?

That said, you should probably take matters into your own hands, rather than waiting for James to come back (and who knows, it may never happen again). It's not like he's getting any kind of paycheck for Mystic or anything. So there's really no incentive for him to come back besides maybe his own boredom, and the sudden urge to listen to people complain about the software he created. lol

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 11 Feb 2025, Accession said the following...

I'm fairly certain this is what I replied to:

there's a bit of nuance here. reading comprehension.. i can certainly respond to a) his first idea about dumping non ansi users and separately, b) needing workarounds being disappointing re: his script to completely kill/restart mystic to restore it to a state where it will accept connections... two separate trains of thought.

So you're basically saying that because Mystic doesn't have pfsense features/functionality built into it, it's buggy? I can't imagine why g00r00 disappears from the scene for years at a crack. lol

you haven't really grasped what this thread is about. at all. i'm not sure why you think you have to defend g00r00 but it's a pretty simple concept: if i can flood your server with bullshit, and it stops /functioning/ because of that (note there's a difference between *functioning* and *being unusable* .. if the flooding were to stop, mystic SHOULD continue to FUNCTION, which it currently does not.. that's the point of this thread)

That said, you should probably take matters into your own hands, rather than waiting for James to come back (and who knows, it may never happen again). It's not like he's getting any kind of paycheck for Mystic or anything. So there's really no incentive for him to come back besides maybe his own boredom, and the sudden urge to listen to people complain about the software he created. lol

i specifically did, as the C file i posted shows. a linux daemon that spawns the mystic binary when it receives socket connections. and the other post you misunderstood involved determining why MIS was spawning 'mystic' with parameters that didn't really make sense.. we'd like to know WHY MIS/mystic is failing.

If you wanted to allow non-ansi callers, then you wouldn't have wrote
that script you pasted, which is what I was replying to, now would you?

the only reason you'd need a script like that is if MIS becomes unreliable when you don't have it.. again, this is THE POINT

anything. So there's really no incentive for him to come back besides maybe his own boredom, and the sudden urge to listen to people complain about the software he created. lol

who cares.. nobody is going to grovel because a48/a49 has a regression a47 and earlier didn't have. i certainly don't respect someone who can't take it when people report bugs

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

On 10 Feb 2025, Accession said the following...

On Mon, Feb 10 2025 22:54:46 -0600, you wrote:

right on :) yeah just kinda sucks to see mystic in limbo needing workarounds..

Pretty sure if you force ANSI instead of using detection, it does basically the same thing as your MPL script does without any "workarounds."

the "workarounds" here were referring to MIS getting into a state it won't accept connections, requiring his script to restart the docker image.

Yes this is correct.

somewhere between the bot being allowed to connect, dumping whatever it do the mystic login prompt, and then getting booted for incorrect passwords o idle timeout, is causing MIS or mystic to mark the node BUSY permanently, other issues.

Again correct, the constant hammering does 'something' which causesm mystic to be unresponsive. Of course it could be the server too, but I did not change anything except mystic version.

that's the only problem. it doesn't really matter whether or how we boot t user for not having ANSI. what if i want to allow non-ANSI users? sync doe mystic does too, but the bots are breaking the server.. it's a bug ;)

And who needs ascii anyway, all scripts I write are full of nice ansi stuff. So its a win to boot connections when they detect ascii and to do it at
the connect.mps script.

For now, I have been following your advice, and I do not see mystic become unresponsive anymore. Thanks for making me work for it ^^

oP!

... We come in peace. Shoot to kill.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

What I wrote in my reply was a possible configuration option (as in someth the BBS offers, rather than using a "workaround"), which doesn't go as far the login prompt or passwords and idle timeouts. This happens as soon as y connect, the software version and copyright is displayed and then it displ the "Detecting Emulation" prompt (which this prompt can also be changed to whatever you want it to do).

Your solution was not feasable for me. Thanks for trying though. When using
the connect.mps script it actually it not a workaround imho, its launching
as soon as a termtype is detected, on connect.

In fact dropping connections which have ascii connected saves my board becoming unresponsive. Im unsure why you make such an issue out of this, while Fusion is trying to help.

You are the only one over reacting imho. We have already a small scene-- and here you are punishing our discussion about solutions to a PROBLEM we have.

Nobody is complaining about Mystic, why would I invest hours on end writing
my ichat, rjam, vbase, matrixrain login, lastcaller mods if I didnt like the software with a passion.

Just wow.

oP!

... I'd love to help you out. Which way did you come in?

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

I've never had to use that switch in the 20+ years I've used Mystic.
So I imagine it's anything useful..?

Thats the thing, I am not running it :). It like Mystic runs it
itself time to time. Not a single bash script or event does anything remotely like that command.

That's definitely wierd, and something I've never heard of happening to an or had happen to me.

Happy to hear ^^

How are you running Mystic (daemon, server, etc)?

Mystic is running as a daemon

Do you have time limits set?

Yes, time limits are set for regular users

Do you have it setup to kick users/force offline when an event runs?

No, no event kicks users or forces users to log.

oP!

... Next time you wave at me, use more than one finger!

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

Hey fusion!

On Wed, Feb 12 2025 03:49:10 -0600, you wrote:

there's a bit of nuance here. reading comprehension.. i can certainly respond to a) his first idea about dumping non ansi users and
separately, b) needing workarounds being disappointing re: his script
to completely kill/restart mystic to restore it to a state where it
will accept connections... two separate trains of thought.

Seems the reading comprehension was on your end, chief. I was _specifically_ replying to you talking about not allowing non-ansi users (even quoted it a second time for you, so you would understand -- guess it didn't work), and supplied another option to do so that Mystic itself provides besides your script/workaround. I wasn't replying to his message or his problem, or the fact that you wrote that script because of said problem.

It was simply stating that Mystic already had an option to not allow ascii callers.

you haven't really grasped what this thread is about. at all. i'm not
sure why you think you have to defend g00r00 but it's a pretty simple concept: if i can flood your server with bullshit, and it stops /functioning/ because of that (note there's a difference between *functioning* and *being unusable* .. if the flooding were to stop,
mystic SHOULD continue to FUNCTION, which it currently does not..
that's the point of this thread)

I don't care what the entire thread was about. I was replying to ONE message, not the entire thread.

This is exactly what these bots were created for and intend to do. Flood your server until it stops functioning or is unusable. They do this to web servers (and other servers) all the time. Not sure why this is new news with a BBS software. With said web servers (and other servers), most normal people put something like iptables, pfsense, fail2ban, or <insert perimeter firewall/filter name here> in front of them so shit like that doesn't happen.. albeit the rare case that firewalling/filtering is built into the software you're trying to serve to the outside world.

i specifically did, as the C file i posted shows. a linux daemon that
spawns the mystic binary when it receives socket connections. and the
other post you misunderstood involved determining why MIS was
spawning 'mystic' with parameters that didn't really make sense..
we'd like to know WHY MIS/mystic is failing.

How did I misunderstand the other post? I simply said I've never seen that before.

Logging into my Mystic setup when a caller connects, 'top -c' produces:

./mystic -TID6 -IP<address> -HOST<hostname> -ML0 -SIDTELNET -SL0 -ST0 -TTSYNCTERM -CUnknown

Where do you see the "-Tx" switch for forcing a time limit in there? Maybe, just maybe.. some misconfiguration or misunderstanding is in play here that should be looked into a little deeper. However, whatever it is - and something I definitely agree with, is it shouldn't be spiking the CPU.

Anyway, you seem to be doing a lot of ASSuming about me here. If I have to go back and read the entire thread in order to reply directly to one single message you wrote, I'll pass.

who cares.. nobody is going to grovel because a48/a49 has a
regression a47 and earlier didn't have. i certainly don't respect
someone who can't take it when people report bugs

To be fair, I haven't had an issue with a49 since it was released. I've heard things about QWK hubbing, but I don't use that feature and there's plenty of others that are that can test it. Sorry to hear that you have issues. *shrug*

Lastly, no clue as to where (or why) 'respect' and 'misunderstood' came from, but if you feel the need to randomly throw jabs in the mix to make yourself feel better about yourself, then I can definitely reciprocate with a 'likewise'. I didn't realize responding to one of your posts with another option to your script that can be done right from the BBS software's configuration itself, and questioning your "bug report" would get you so butthurt.j

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

Hey opicron!

On Wed, Feb 12 2025 18:58:34 -0600, you wrote:

Your solution was not feasable for me. Thanks for trying though. When using the connect.mps script it actually it not a workaround imho, its launching as soon as a termtype is detected, on connect.

Are you saying connect.mps runs before Mystic detects emulation? If so, then you're right, Mystic's configuration option for that probably won't work, then.

In fact dropping connections which have ascii connected saves my board becoming
unresponsive. Im unsure why you make such an issue out of this, while Fusion is
trying to help.

I didn't make an issue out of anything. I suggested another option to his script that dropped ascii callers. Then questioned something that was considered a bug that must also be a bug in 80% of other softwares out there that don't have it's own firewalling/filtering support.

Just wow.

Enjoy!

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

Hey opicron!

On Wed, Feb 12 2025 19:04:26 -0600, you wrote:

How are you running Mystic (daemon, server, etc)?

Mystic is running as a daemon

Do you have time limits set?

Yes, time limits are set for regular users

Do you have it setup to kick users/force offline when an event runs?

No, no event kicks users or forces users to log.

I posted exactly what my system shows when a user connects in another reply after I was told I misunderstood your original post about this. I hope you guys figure out whatever it is that isn't working properly!

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

Hey fusion!

On Wed, Feb 12 2025 03:49:10 -0600, you wrote:

there's a bit of nuance here. reading comprehension.. i can certainly respond to a) his first idea about dumping non ansi users and separately, b) needing workarounds being disappointing re: his script to completely kill/restart mystic to restore it to a state where it will accept connections... two separate trains of thought.

Seems the reading comprehension was on your end, chief. I was _specificall replying to you talking about not allowing non-ansi users (even quoted it second time for you, so you would understand -- guess it didn't work), and supplied another option to do so that Mystic itself provides besides your script/workaround. I wasn't replying to his message or his problem, or the that you wrote that script because of said problem.

It was simply stating that Mystic already had an option to not allow ascii callers.

Your solution wasnt feasible, because using that way Mystic is already unresponsive
and doesnt drop the user. Actually we cant even connect to any node. And its not
because the nodes are busy, its because Mystic become unresponsive, completely.

Again, it might have to do with server too-- or maybe the two together. Anyway that was the issue.

With manual drops, in whichever way works out better for me.

I think no software is 100%, our creativity and workarounds are making our lives, and indirectly the software better.

oP!

... Save the wales! Nuke Greenpeace instead!

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

Logging into my Mystic setup when a caller connects, 'top -c' produces:

./mystic -TID6 -IP<address> -HOST<hostname> -ML0 -SIDTELNET -SL0 -ST0 -TTSYNCTERM -CUnknown

Where do you see the "-Tx" switch for forcing a time limit in there? Maybe just maybe.. some misconfiguration or misunderstanding is in play here tha should be looked into a little deeper. However, whatever it is - and somet I definitely agree with, is it shouldn't be spiking the CPU.

I guarantee not misconfiguration. This is running seemingly random, and I log the high cpu jobs to my Slack channel. Its always this command, taking 99% CPU, on random times.

Nothing in my server calls a bash script, or event which triggers this exact command. Latest occurrences: 9:04 , 5:44 , 5:18 , 4:20 , 4:06, 3:20, 00:50.

No idea at all what this could be.


oP!

... Life... don't talk to me about life.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

Hey opicron!

On Thu, Feb 13 2025 10:02:58 -0600, you wrote:

Your solution wasnt feasible, because using that way Mystic is already unresponsive
and doesnt drop the user. Actually we cant even connect to any node. And its not
because the nodes are busy, its because Mystic become unresponsive, completely.

I understand that now, of course. However, it was still just another option to the script that was posted. Nothing more, nothing less.

I'm glad you at least gave it a try (even though it didn't work).

Again, it might have to do with server too-- or maybe the two together. Anyway
that was the issue.

I'm pretty confident in saying Mystic was probably never tested (by the author) in a docker instance. At least he never mentioned it to me, ever.

With manual drops, in whichever way works out better for me.

I think no software is 100%, our creativity and workarounds are making our lives, and indirectly the software better.

I agree completely. Most definitely go with whatever works best for you. The less headaches you run into the more time you have enjoying it, rather than fixing it. However, I would still always recommend running _any_ server (BBS or not) that doesn't have built-in firewalling/filtering be run behind a perimeter firewall/filter, though.

Looks like you now have something in place to help with that, now. ;)

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

Hey opicron!

On Thu, Feb 13 2025 10:12:18 -0600, you wrote:

I guarantee not misconfiguration. This is running seemingly random, and I log
the high cpu jobs to my Slack channel. Its always this command, taking 99% CPU,
on random times.

Is it completely random, or can it be narrowed down at least a little bit?

Does it only happen when a user is connected?
Does it only happen when nobody is online?
Is an event running at the same time?

.. is probably a good place to start, since ultimately it has to do with time online.

Nothing in my server calls a bash script, or event which triggers this exact command. Latest occurrences: 9:04 , 5:44 , 5:18 , 4:20 , 4:06, 3:20, 00:50.

No idea at all what this could be.

I don't doubt you are running this manually.

From the questions I wrote above, I'm just wondering if possibly when an event is triggered maybe this command is ran by MIS itself to check if a user is online, and compare it to whatever configuration settings are set.

In mystic -cfg > Configuration > General Settings:

What do you have set for "Disable Time"? If no, try setting it to yes for a couple of days and see if you see that command triggered again during that time.

In mystic -cfg > Editors > Event Editor:

Do you have anything besides "0" under "Warning" (last option) in any of your events? If so, try setting them back to "0".

That's about all I can see that could possibly trigger something like that when events come into play, or even when users are online, as far as configuration settings would go.

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On 12 Feb 2025, Accession said the following...

Seems the reading comprehension was on your end, chief. I was 'misunderstood'

yeah .. sorry for stooping to that. i didn't really mean it heh

This is exactly what these bots were created for and intend to do. Flood your server until it stops functioning or is unusable. They do this to

that's not the case. you can watch them if you want:

https://github.com/lanjelot/twisted-honeypots

they have an incentive not to be a denial of service because they're trying to find poorly configured *nix machines with weak username/password combos. also why most of them will only make one connection at a time. if they manage to log in with a weak password from the list they come back to use the machine they've gained access to. they really don't want to be banned nor put the target machine offline.

but, just as an example, normally that wouldn't be a problem with mystic but any unknown username and a password they attempt that happens to contain a 'y' will allow them a LOT of time to run through a few hundred username/password combos in the new user "full name" field (which won't hangup on you no matter how many times you don't include a last name. including just holding enter forever)

Lastly, no clue as to where (or why) 'respect'

this was regarding respect for g00r00, not really sure why your post was concerned with his feelings treating him with kid gloves or something. i think it's a bug.. it's not like i said "i think mystic is a steaming pile because it might have a bug"

anyways sorry for the overreaction :/

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi (21:1/616)

From the questions I wrote above, I'm just wondering if possibly when an e is triggered maybe this command is ran by MIS itself to check if a user is online, and compare it to whatever configuration settings are set.

When I run ./mystic -T+ myself it just starts a local board node. I guess its the command to open a telnet session when someone connects.

My first thought is that this is some bot/connection which tries to connect unconventionally. Triggering something in Mystic which runs up the cpu for a minute or two.

In mystic -cfg > Configuration > General Settings:

What do you have set for "Disable Time"? If no, try setting it to yes for couple of days and see if you see that command triggered again during that

I tried to disable time and have timeout set to 0 for a few days. No change unfortunately.

In mystic -cfg > Editors > Event Editor:

Do you have anything besides "0" under "Warning" (last option) in any of y events? If so, try setting them back to "0".

All events are set to 0.

That's about all I can see that could possibly trigger something like that events come into play, or even when users are online, as far as configurat settings would go.

So I noticed the process only very occassionaly runs ar 99% for more than 2:30 minutes. I adjusted my script to only inform me when it goes on longer than 5:00 minutes.

Nothing triggered the script so far. I'll probably leave it like this and only reset on the rare occurrence when it runs for too long.

oP!

... A: I don't know and I don't care.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

Hey fusion!

On Sat, Feb 15 2025 05:52:12 -0600, you wrote:

they have an incentive not to be a denial of service because they're
trying to find poorly configured *nix machines with weak
username/password combos. also why most of them will only make one connection at a time. if they manage to log in with a weak password
from the list they come back to use the machine they've gained access
to. they really don't want to be banned nor put the target machine
offline.

Maybe we're not referring to the same thing here..

By one connection at a time, do you mean in succession, very rapidly? As in 20+ attempts in a minute, but one connection at a time which might seem like they're all coming in at once?

I see different types of bots, I guess, and most of them don't try username/password combinations whatsoever. They basically hit as many times as they can until Synchronet temporarily bans them. Most telnet connections just sit there and don't hit a key for 20-30 seconds, but while they're sitting there another from the same IP is usually connecting again, etc..

but, just as an example, normally that wouldn't be a problem with
mystic but any unknown username and a password they attempt that
happens to contain a 'y' will allow them a LOT of time to run through
a few hundred username/password combos in the new user "full name"
field (which won't hangup on you no matter how many times you don't
include a last name. including just holding enter forever)

Wait, in the new user application it doesn't send you back to the matrix if you type in an incorrect full name? I thought it did.

anyways sorry for the overreaction :/

No worries, and same. I think plenty of people jump on the "it's a bug" train before actually doing any testing, so I questioned it right away. Clearly, that wasn't the case here. I sometimes get a bit defensive when people aren't around to defend themselves or their software at the moment.

Who knows, maybe he did read it. ;P

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

Hey opicron!

On Mon, Feb 17 2025 16:37:26 -0600, you wrote:

When I run ./mystic -T+ myself it just starts a local board node. I
guess its the command to open a telnet session when someone connects.

I believe the command is './mystic -T#' where "#" is a time in minutes that whoever logging in would be limited to (even if their user account is set to something higher). If something is running './mystic -T+' then you've really lost me, since that doesn't seem to be a valid parameter for that command, at all.

My first thought is that this is some bot/connection which tries to
connect unconventionally. Triggering something in Mystic which runs
up the cpu for a minute or two.

I'm pretty stumped on this one, to say the least. The _only_ way I can get 'top -c' to produce that command is if I manually type './mystic -T20' or something similar at the Linux console prompt (which means I'm actually forcing it to happen).

Also, I don't remember if you said that it only happens when a user connects or not? The fact that no other commands were passed to Mystic on a regular telnet connection would also leave me completely confused, since usually things like '-HOST', '-IP', and '-TID' are passed on those connections.

So I noticed the process only very occassionaly runs ar 99% for more
than 2:30 minutes. I adjusted my script to only inform me when it
goes on longer than 5:00 minutes.

Which script is this, connect.mps? When is this specifically ran?

Nothing triggered the script so far. I'll probably leave it like this
and only reset on the rare occurrence when it runs for too long.

I wouldn't want my CPU spiked for even that long, to be honest. Why not set it for like 10-20 seconds or something? I can't imagine anything else would or should spike the CPU for that long, unless something actually hangs or gets stuck or something is wrong with your hardware - which you don't really want to happen anyways.

Have you by chance tried setting up a default install outside of your setup to see if it happens there, too? Then you can re-introduce all of your mods/scripts one by one to see if one of them triggers either the command, or the CPU spikes.

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)

On Mon, Feb 17 2025 16:37:26 -0600, you wrote:

When I run ./mystic -T+ myself it just starts a local board node. I guess its the command to open a telnet session when someone connects.

I believe the command is './mystic -T#' where "#" is a time in minutes tha whoever logging in would be limited to (even if their user account is set something higher). If something is running './mystic -T+' then you've real lost me, since that doesn't seem to be a valid parameter for that command, all.

Yes, thats what I feel too. Lost.

My first thought is that this is some bot/connection which tries to connect unconventionally. Triggering something in Mystic which runs
up the cpu for a minute or two.

I'm pretty stumped on this one, to say the least. The _only_ way I can get -c' to produce that command is if I manually type './mystic -T20' or somet similar at the Linux console prompt (which means I'm actually forcing it t happen).

Also, I don't remember if you said that it only happens when a user connec not? The fact that no other commands were passed to Mystic on a regular te connection would also leave me completely confused, since usually things l '-HOST', '-IP', and '-TID' are passed on those connections.

I havent figured that out completely. Is it really a connection, because I
also run some event which call ./mystic -y (script) -ppass -uuser.

So I noticed the process only very occassionaly runs ar 99% for more than 2:30 minutes. I adjusted my script to only inform me when it
goes on longer than 5:00 minutes.

Which script is this, connect.mps? When is this specifically ran?

Thats the ./mystic -T+ process wich I am referring to.

Nothing triggered the script so far. I'll probably leave it like this and only reset on the rare occurrence when it runs for too long.

I wouldn't want my CPU spiked for even that long, to be honest. Why not se for like 10-20 seconds or something? I can't imagine anything else would o should spike the CPU for that long, unless something actually hangs or get stuck or something is wrong with your hardware - which you don't really wa happen anyways.

Well true, though Mystic runs in a docker, which is taking 100%. The CPU
of the servers goes from 3% to 14% during this time. So I am not too worried yet.

Have you by chance tried setting up a default install outside of your setu see if it happens there, too? Then you can re-introduce all of your mods/scripts one by one to see if one of them triggers either the command, the CPU spikes.

No I havent, but its a good idea.

One thing which I noticed when moving to Mystic a49 is my log files piling up with stuff like this:

2025.02.17 22:44:56 DEBUG PyDepth=0
2025.02.17 22:44:56 DEBUG PyFree6
2025.02.17 22:44:56 DEBUG PyFree7
2025.02.17 22:44:57 DEBUG PyFree4
2025.02.17 22:44:57 DEBUG PyFree5
2025.02.17 22:44:57 DEBUG PyDepth=0
2025.02.17 22:44:57 DEBUG PyFree6
2025.02.17 22:44:57 DEBUG PyFree7
2025.02.17 22:44:58 DEBUG PyFree4
2025.02.17 22:44:58 DEBUG PyFree5
2025.02.17 22:44:58 DEBUG PyDepth=0
2025.02.17 22:44:58 DEBUG PyFree6
2025.02.17 22:44:58 DEBUG PyFree7
2025.02.17 22:44:59 DEBUG PyFree4
2025.02.17 22:44:59 DEBUG PyFree5
2025.02.17 22:44:59 DEBUG PyDepth=0
2025.02.17 22:44:59 DEBUG PyFree6
2025.02.17 22:44:59 DEBUG PyFree7
2025.02.17 22:45:00 DEBUG PyFree4
2025.02.17 22:45:00 DEBUG PyFree5
2025.02.17 22:45:00 DEBUG PyDepth=0
2025.02.17 22:45:00 DEBUG PyFree6
2025.02.17 22:45:00 DEBUG PyFree7

Like thousands of these. Even when I turn off all debugging in Mystic CFG
they keep piling up.

This might have to do with it?

oP!

... Dammit, Jim, I'm a floor wax, not a dessert topping!

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

On Mon, Feb 17 2025 16:37:26 -0600, you wrote:

My first thought is that this is some bot/connection which tries t connect unconventionally. Triggering something in Mystic which run up the cpu for a minute or two.

So, after a lot of testing, debugging and trying to be on time to see what
is happening during these spikes.

It only happens when a telnet session is connecting to Mystic. The status of the node is: 'Logging in' for those 1:30-2:30 minutes at 99% CPU usage.

In the startup.mps script I added a MenuCMD function call to set the Node status to something else when my custom login prompt shows. Which means the
cpu spike is happening before startup.mps is called. Which could be BEFORE
or AFTER the Termtype detection.

I cannot set detect to ANSI only to solve this issue, because then we lost widescreen auto-support in Syncterm and Netrunner. And my board relies heavily on regular or widescreen support, depending on what is detected.

Now that I know this I will set the Node status in connect.mps to see if it
is before or after detection to maybe help g00r00 in figuring out what
might be happening.

oP!

... Hell hath no fury like the lawyer of a woman scorned.

--- Mystic BBS v1.12 A49 2024/05/29 (Linux/64)
* Origin: TheForze - bbs.theforze.eu:23 (21:3/126)

Hey opicron!

On Mon, Feb 17 2025 22:52:16 -0600, you wrote:

Yes, thats what I feel too. Lost.

I havent figured that out completely. Is it really a connection,
because I also run some event which call ./mystic -y (script) -ppass
-uuser.

Have you double checked that that event doesn't accidentally call './mystic -t (script) ..' due to a typo of any sort? That's VERY close, and the letters are right next to each other. ;)

So I noticed the process only very occassionaly runs ar 99% for more
than 2:30 minutes. I adjusted my script to only inform me when it
goes on longer than 5:00 minutes.

Which script is this, connect.mps? When is this specifically ran?

Thats the ./mystic -T+ process wich I am referring to.

I know what process you're referring to, but after that you said "I adjusted my script .." I was asking what script you were referring to.

I wouldn't want my CPU spiked for even that long, to be honest. Why
not se for like 10-20 seconds or something? I can't imagine anything
else would o should spike the CPU for that long, unless something
actually hangs or get stuck or something is wrong with your hardware
- which you don't really wa happen anyways.

Well true, though Mystic runs in a docker, which is taking 100%. The
CPU of the servers goes from 3% to 14% during this time. So I am not
too worried yet.

Is there any way you can pull your Mystic setup out of the docker instance and see if you have the same issue(s)? Maybe this is specific to docker..

One thing which I noticed when moving to Mystic a49 is my log files
piling up with stuff like this:

2025.02.17 22:44:56 DEBUG PyDepth=0
2025.02.17 22:44:56 DEBUG PyFree6
2025.02.17 22:44:56 DEBUG PyFree7

Like thousands of these. Even when I turn off all debugging in Mystic
CFG they keep piling up.

I imagine you have your loglevel set too high. Debugging in 'mystic -cfg' may be turned off, but how high do you have logging set in all of your mutil.ini files?

This might have to do with it?

I don't know for sure. I don't use any python with my Mystic install, so thousands of those may indeed be assisting in the spiking of your CPU. I suppose, in that case you could disable your python scripts for maybe 24 hours, and see if you have any more spiking issues.

If I remember right, Mystic was specifically setup for python 2.7, and then people started trying to force python 3.x into it, which started messing things up, and I don't think g00r00 has been around to address any of that yet.

Regards,
Nick

... He who laughs last, thinks slowest.
--- slrn/pre1.0.4-9 (Linux)
* Origin: The Pharcyde ~ telnet://bbs.pharcyde.org (Wisconsin) (21:1/200)