I had this issue a few weeks ago. I resolved it by deleting Mystic and doing
a fresh install. At this point I've got too much work into the BBS to do that.

I can log in locally, by telnetting to the Pi and running ./mystic -l, but it looks like any attempt at remote connection gets a BUSY signal. Could someone try connecting? Thanks.

Oddly, I created data/busy.txt but I'm seeing the stock BUSY message, not my customized on.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A42 2018/12/27 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 13 Mar 2019 at 04:46p, nathanael pondered and said...

I had this issue a few weeks ago. I resolved it by deleting Mystic and doing a fresh install. At this point I've got too much work into the BBS to do that.

I can log in locally, by telnetting to the Pi and running ./mystic -l,
but it looks like any attempt at remote connection gets a BUSY signal. Could someone try connecting? Thanks.

Are you running mis server in a way that you can see what nodes are in use? This error leads me to think all nodes are tied up.
Does nodespy show anything Nathanael?

Best, Paul

--- E:avon@bbs.nz ------ W:bbs.nz ---
--- K:keybase.io/avon --------------

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

Does nodespy show anything Nathanael?

I run client, server and nodespy 24/7 in a four-pane tmux window, so everything's always visible.

I have eight nodes, and I'm currently logged into node 7. The others are all "Waiting".

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Are you running mis server in a way that you can see what nodes are in

Ah, suppose I should mention mis server is showing:

17:32:51 TELNET Unabel to open IPV4 port: Error -1 (98)
17:32:51 TELNET Listening on IPV6 port 2323 using interface "::"

Similar errors for SSH and BINKP -- all fail to open IPV4, but succeed on
IPV6.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 13 Mar 2019, nathanael said the following...

I had this issue a few weeks ago. I resolved it by deleting Mystic and doing a fresh install. At this point I've got too much work into the BBS to do that.

I can log in locally, by telnetting to the Pi and running ./mystic -l,
but it looks like any attempt at remote connection gets a BUSY signal. Could someone try connecting? Thanks.

Yeah, I was getting that earlier today when I went to check your DOS game section. Not sure what's up, g00r00 would probably be able to tell better
from your logs.

--- Mystic BBS v1.12 A43 2019/02/23 (Raspberry Pi/32)
* Origin: throwbackbbs.com -\- meriden, ct -\- (21:1/114)

On 13 Mar 2019, nathanael said the following...

Are you running mis server in a way that you can see what nodes are i

Ah, suppose I should mention mis server is showing:

17:32:51 TELNET Unabel to open IPV4 port: Error -1 (98)

That's the EXACT error I get when my test MPY I'm working on hangs a node up and I have to kill the two ghosts it eventually creates, and try and relaunch Mystic. Still not sure what's causing it, but to remedy it you have to reboot the entire system. I'm sure there's an easier way to release the lock it has
on your IP/port, but I just know rebooting the OS does it.

--- Mystic BBS v1.12 A43 2019/02/23 (Raspberry Pi/32)
* Origin: throwbackbbs.com -\- meriden, ct -\- (21:1/114)

On 13 Mar 2019 at 05:44p, nathanael pondered and said...

Ah, suppose I should mention mis server is showing:

17:32:51 TELNET Unabel to open IPV4 port: Error -1 (98)
17:32:51 TELNET Listening on IPV6 port 2323 using interface "::"

Well that's key information for sure. If MIS can't bind to a port then it
could explain a lot of your issues.. as to the why.. I am not sure.

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)

I would experiment with the server settings, remove IPv6 from the options, perhaps set IPv4 as priority and v6 as fall back, or the reverse.

Could it be some firewall change in the Pi? I am sorry I don't know the OS
and possible linux related reasons that may be contributing... but I think if you solve that error your problems will likely resolve.

Best, Paul

--- E:avon@bbs.nz ------ W:bbs.nz ---
--- K:keybase.io/avon --------------

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

17:32:51 TELNET Unabel to open IPV4 port: Error -1 (98)

I had this a few times when I was testing something but with SSH not TELNET...

you have to reboot the entire system. I'm sure there's an easier way to release the lock it has on your IP/port, but I just know rebooting the
OS does it.

I just restarted the network daemon, that seemed to fix it for me...

sudo /etc/init.d/networking restart

Hope that helps =)

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÄ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: The Quantum Wormhole, Ramsgate, UK. bbs.erb.pw (21:1/158)

On 13 Mar 2019, MeaTLoTioN said the following...

I just restarted the network daemon, that seemed to fix it for me...

sudo /etc/init.d/networking restart

Hope that helps =)

I wish, but I run it in terminal mode on a xfce desktop. Restarting the
entire OS is what works for me. But it's quick, I just have to start and stop the container on my phone and it's golden.

--- Mystic BBS v1.12 A43 2019/02/23 (Raspberry Pi/32)
* Origin: throwbackbbs.com -\- meriden, ct -\- (21:1/114)

and relaunch Mystic. Still not sure what's causing it, but to remedy it you have to reboot the entire system. I'm sure there's an easier way to

Well, I rebooted the pi while troubleshooting the BUSY issue I'm having, and yep, that problem's resolved.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Well that's key information for sure. If MIS can't bind to a port then it could explain a lot of your issues.. as to the why.. I am not sure.

Turned out to be a red herring. When I rebooted the pi, the IPV4 connections were working again, but still cannot connect.

This may or may not be anything, but this morning I discovered I couldn't
even log in locally (mystic -l).

I created a new Mystic install which I could log into, then started copying files over from my main Mystic install until I was getting BUSY from the new install. Through a process of elimination, I narrowed the issue down to the Mystic/data/chat*.dat files.

So I move the chat*.dat files from my main Mystic setup into a backup folder and suddenly I could log in locally again. But remote log-in is still not working.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Well, *HUMONGOUS* is back online -- I *think*. Could someone try connecting just to verify?

But )#$(*$- I don't know how I fixed it. I created a fresh Mystic install,
then started just copying files a bit at a time from my broken install until the new install would stop working. Eventually I had almost everything copied over (except the chat*.dat files I mentioned in an earlier post) and the new install was mostly working -- except that polling from it would fail with authorization errors.

But now the original install seems to be working again. Perhaps deleting the data/chat*.dat stuff was the key. I could try copying them back from my
backups to see if things break again, but I don't want to mess with success.

So could someone tell me how the board looks from the outside?

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Yeah, I was getting that earlier today when I went to check your DOS game

I think I'm back up now. Give it a try.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 14 Mar 2019 at 12:41p, nathanael pondered and said...

So could someone tell me how the board looks from the outside?

Looks OK I am just on looking now, the only thing I see amiss is your file bases seem to have been duplicated several times. I see the same bases listed three times each.

Message bases and a quick of doors seemed fine :)

Best, Paul

--- E:avon@bbs.nz ------ W:bbs.nz ---
--- K:keybase.io/avon --------------

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

file bases seem to have been duplicated several times. I see the same bases listed three times each.

That started last week sometime. It's just cosmetic and other fires have
been burning hotter. Hopefully I'll have time this weekend.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Well, *HUMONGOUS* is back online -- I *think*. Could someone try

And then it wasn't again. Just tried five minutes ago and couldn't connect remotely -- "closed by foreign host".

Clearing out /mystic/data/chat*.dat got it working again. Not a clue why.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 13 Mar 2019 &4, nathanael said the following...

I had this issue a few weeks ago. I resolved it by deleting Mystic and doing a fresh install. At this point I've got too much work into the BBS to do that.

I can log in locally, by telnetting to the Pi and running ./mystic -l,
but it looks like any attempt at remote connection gets a BUSY signal. Could someone try connecting? Thanks.

Oddly, I created data/busy.txt but I'm seeing the stock BUSY message,
not my customized on.

can you run nodespy to see if the nodes are actually being used?

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Cyberia BBS | cyberiabbs.zapto.org | San Jose, CA (21:1/120)

On 13 Mar 2019 &4, nathanael said the following...

Are you running mis server in a way that you can see what nodes are i

Ah, suppose I should mention mis server is showing:

17:32:51 TELNET Unabel to open IPV4 port: Error -1 (98)
17:32:51 TELNET Listening on IPV6 port 2323 using interface "::"

Similar errors for SSH and BINKP -- all fail to open IPV4, but succeed on IPV6.

Is something else running on port 2323? Maybe reboot the system to refresh
and use nmap to see if the port is already in use.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Cyberia BBS | cyberiabbs.zapto.org | San Jose, CA (21:1/120)

On 14 Mar 2019 &4, nathanael said the following...

So I move the chat*.dat files from my main Mystic setup into a backup folder and suddenly I could log in locally again. But remote log-in is still not working.

It's pretty safe to delete the chatN.dat files (but leave chatroom.dat) as
they will be created/modified when a user does things on the BBS.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Cyberia BBS | cyberiabbs.zapto.org | San Jose, CA (21:1/120)

can you run nodespy to see if the nodes are actually being used?

No, they are not.

I've found that, when it happens, deleting all data/chat*.dat files clears it up. Don't know why.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

It's pretty safe to delete the chatN.dat files (but leave chatroom.dat)

Last night I was able to log in to my board remotely; this morning not. Once again, deleting the chat##.dat files fixed the issue.

This is happening almost daily now. Are the chat files related to the chat logging option in general settings? I've turned that off and created a
script which automatically deletes chat##.dat when I log in. Hopefully there won't be any unforeseen consequences.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Last night I was able to log in to my board remotely; this morning not. Once again, deleting the chat##.dat files fixed the issue.
This is happening almost daily now. Are the chat files related to the
chat logging option in general settings? I've turned that off and
created a script which automatically deletes chat##.dat when I log in. Hopefully there won't be any unforeseen consequences.

Nathanael, I was wondering what language/region is your PI OS on??
I wondering if maybe its a UTF-8 translation issue??

Michael2

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Mike's Mansion - Pdx,Or (21:2/145)

Nathanael, I was wondering what language/region is your PI OS on??

# File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

On 16 Mar 2019, nathanael said the following...

Last night I was able to log in to my board remotely; this morning not. Once again, deleting the chat##.dat files fixed the issue.

This is happening almost daily now. Are the chat files related to the

It might be a permissions/ownership issue. I'm sure you've done it correctly, but just in case:

sudo chown -R username:username /path/to/mystic
sudo chmod -R 755 /path/to/mystic

setting username to the one the Pi is using when you login, not root.

If you're using su to access the BBS, then yeah, probably
permissions/ownership issues. One thing you'll have to do if you set the ownership to the default user is do this:

setcap cap_net_bind_service=+ep /path/to/mystic/mis

where the /path/to/mystic is the path, and putting mis at the end. This will let a non-root user access priviliged ports (1-1024).

Good luck!

--- Mystic BBS v1.12 A43 2019/02/23 (Raspberry Pi/32)
* Origin: throwbackbbs.com -\- meriden, ct -\- (21:1/114)

sudo chown -R username:username /path/to/mystic
sudo chmod -R 755 /path/to/mystic

Thanks. Yeah, I'd already done that, but to be thorough I just ran it
again. I had forgotten to run setcap against mis after upgrading to A43, however.

My mystic start-up script now wipes all data/chat??.dat; this morning I was still able to connect remotely.

Still curious as to why I'm the only one having the problem, however.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

Last night I was able to log in to my board remotely; this morning not. Once again, deleting the chat##.dat files fixed the issue.

This is happening almost daily now. Are the chat files related to the
chat logging option in general settings? I've turned that off and
created a script which automatically deletes chat##.dat when I log in. Hopefully there won't be any unforeseen consequences.

I would like you to do an experiment for me:

1. Do not autostart Mystic at all. Take it out of your init.rd or whatever you are using to start Mystic. Take it out of a cron if you have a script checking to see if its running, please don't use it.

2. Before you start it, pick a user that should own the BBS and do:
"sudo chown -R me:me /mystic"

3. Clear out any residual data files but don't touch .BSY files or anything afterwards (no fidopoll killbusy, etc):
"sudo rm /mystic/data/chat*.dat"

4. Start Mystic manually, assuming you use it in daemon mode do this:
"sudo ./mis daemon"
or if you use it in GUI mode then do this:
"sudo ./mis server"

Then let it run and don't muck with it for a bit to see if it runs for you.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Sector 7 (21:1/108)

I would like you to do an experiment for me:

No problem. In case it's helpful, here's my usual routine:

I don't run mystic from init.rd or a cron job. Instead, I have a script which creates a four-paned tmux session, then loads each of mis (in server mode), nodespy and the mystic client in separate panes with commands like "while
true; do clear; ./mystic -l; sleep 5; done" to auto-reload anything that
gets shut down or logged out of.

So for the time being I will run mis with this script:

#!/bin/bash
sudo chown -R <me>:<me> /mystic
cd /mystic
rm data/chat*.dat
sudo ./mis daemon

And hands of .BSY stuff.

ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄ· ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
*HúUúMúOúNúGúOúUúS* BúBúS nathanael : jenandcal.familyds.org:2323
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄĽ ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ

--- Mystic BBS v1.12 A43 2019/03/03 (Raspberry Pi/32)
* Origin: *HUMONGOUS* BBS (21:4/123)

So for the time being I will run mis with this script:

#!/bin/bash
sudo chown -R <me>:<me> /mystic
cd /mystic
rm data/chat*.dat
sudo ./mis daemon

I wouldn't script deleting the chat*.dat part at least. Part of the
experiment I am after is just starting Mystic properly without any scripts involved and just letting it go. Thats what I do and I have months of
uptime, never had the BUSY issue, etc.

The idea is if we strip everything away to nothing and it runs fine, then add piece by piece back in what you want, then we can figure out where the issue is.

--- Mystic BBS v1.12 A43 2019/03/02 (Linux/64)
* Origin: Sector 7 (21:1/108)