Section One BBS

Welcome, Guest.


Subject: imsg on incoming echomail Date: Sun Jan 19 2025 05:36 pm
From: deon To: Digital Man

  Re: imsg on incoming echomail
  By: Digital Man to deon on Sat Jan 18 2025 06:10 pm

Howdy,

 >  > I'm going to monitor it more closely to see if I can find out why I'm not
 >  > seeing the message as I expect...
 >
 > Okay, please let me know what you find.

OK, I think I've figured out the sequence. As background, I access SBBS via my l
aptop (using Muffinterm - but that shouldnt matter), and often leave the termina
l open for hours at a time.

Over night, my laptop will go to sleep, so the connection to SBBS would eventual
ly be terminated.

So this afternoon I did this:

a) Sent a test message to clrghouz (which would generate a reply), and killed my
 network connection (simulating my laptop going to sleep and not logging off).
b) Sync exported the message
c) Sync imported the reply
d) No update to msgs/0001.msg (when there should have been).

Here is some logging:

1) I checked the status of the 0001*msgs before doing (a).

[deon@rl8-2-1 data]$ ls -al msgs/0001.*msg
-rw------- 1 root root 367 Jan 19 16:32 msgs/0001.last.0.msg
-rw------- 1 root root 285 Jan 12 16:25 msgs/0001.last.10.msg
-rw------- 1 root root  82 Jan  9 18:14 msgs/0001.last.11.msg
-rw------- 1 root root 207 Jan  9 13:03 msgs/0001.last.12.msg
-rw------- 1 root root  59 Jan  9 08:22 msgs/0001.last.13.msg
-rw------- 1 root root  64 Jan  8 13:11 msgs/0001.last.14.msg
-rw------- 1 root root 133 Jan  8 08:13 msgs/0001.last.15.msg
-rw------- 1 root root  58 Jan  7 22:23 msgs/0001.last.16.msg
-rw------- 1 root root 567 Jan  7 22:10 msgs/0001.last.17.msg
-rw------- 1 root root 567 Jan  7 22:07 msgs/0001.last.18.msg
-rw------- 1 root root 235 Jan 19 12:13 msgs/0001.last.1.msg
-rw------- 1 root root  71 Jan 19 11:02 msgs/0001.last.2.msg
-rw------- 1 root root 306 Jan 19 10:57 msgs/0001.last.3.msg
-rw------- 1 root root  71 Jan 18 20:24 msgs/0001.last.4.msg
-rw------- 1 root root 235 Jan 18 20:19 msgs/0001.last.5.msg
-rw------- 1 root root 142 Jan 18 15:36 msgs/0001.last.6.msg
-rw------- 1 root root  71 Jan 18 15:31 msgs/0001.last.7.msg
-rw------- 1 root root  64 Jan 16 17:00 msgs/0001.last.8.msg
-rw------- 1 root root  59 Jan 16 11:04 msgs/0001.last.9.msg
-rw------- 1 root root  71 Jan 19 16:37 msgs/0001.last.msg
-rw------- 1 root root   0 Jan 19 16:37 msgs/0001.msg

2) Output of sbbsecho when the test message was sent, and the reply received (b)
 and (c)

2025-01-19 17:11:01 Exported:     1 msgs                         pvt_test -> PVT
_TEST
2025-01-19 17:11:01 Exported:     1 msgs total
2025-01-19 17:11:02 SBBSecho (PID 309988) exiting with error level 0, Packets(0 
imported, 2 sent), EchoMail(0 imported, 1 exported)
2025-01-19 17:11:30 Importing /opt/sbbs/fido/inbound/000a1ebe.pkt (type 2e, 1.8K
B) from 10:1/1 to 10:1/4
2025-01-19 17:11:30 Imported:     1 msgs                         pvt_test <- PVT
_TEST
2025-01-19 17:11:30 Imported:     1 msgs total
2025-01-19 17:11:30 SBBSecho (PID 309999) exiting with error level 0, Packets(1 
imported, 1 sent), EchoMail(1 imported, 0 exported)

3) A list of the 0001*msg files after the import - notice that 0001.msg is still
 0 bytes in size (and no change in mtime), and no other *last.msg files have bee
n changed.

[deon@rl8-2-1 data]$ ls -al msgs/0001.*msg
-rw------- 1 root root 367 Jan 19 16:32 msgs/0001.last.0.msg
-rw------- 1 root root 285 Jan 12 16:25 msgs/0001.last.10.msg
-rw------- 1 root root  82 Jan  9 18:14 msgs/0001.last.11.msg
-rw------- 1 root root 207 Jan  9 13:03 msgs/0001.last.12.msg
-rw------- 1 root root  59 Jan  9 08:22 msgs/0001.last.13.msg
-rw------- 1 root root  64 Jan  8 13:11 msgs/0001.last.14.msg
-rw------- 1 root root 133 Jan  8 08:13 msgs/0001.last.15.msg
-rw------- 1 root root  58 Jan  7 22:23 msgs/0001.last.16.msg
-rw------- 1 root root 567 Jan  7 22:10 msgs/0001.last.17.msg
-rw------- 1 root root 567 Jan  7 22:07 msgs/0001.last.18.msg
-rw------- 1 root root 235 Jan 19 12:13 msgs/0001.last.1.msg
-rw------- 1 root root  71 Jan 19 11:02 msgs/0001.last.2.msg
-rw------- 1 root root 306 Jan 19 10:57 msgs/0001.last.3.msg
-rw------- 1 root root  71 Jan 18 20:24 msgs/0001.last.4.msg
-rw------- 1 root root 235 Jan 18 20:19 msgs/0001.last.5.msg
-rw------- 1 root root 142 Jan 18 15:36 msgs/0001.last.6.msg
-rw------- 1 root root  71 Jan 18 15:31 msgs/0001.last.7.msg
-rw------- 1 root root  64 Jan 16 17:00 msgs/0001.last.8.msg
-rw------- 1 root root  59 Jan 16 11:04 msgs/0001.last.9.msg
-rw------- 1 root root  71 Jan 19 16:37 msgs/0001.last.msg
-rw------- 1 root root   0 Jan 19 16:37 msgs/0001.msg

Interestingly, when I reconnected to the wifi (5 or so minutes later) and logged
 another minute or so after that, Sync thought I was still connected to Node 1 (
obviously not long enough yet to kick me off, even though Muffinterm had noticed
 (after rejoining the wifi) the TCP session was severed.

It also didnt show the message waiting status (M)?

Node Status
──── ──────────────────────────────────
  1  deon posting message via telnet (P) [UQ]

Anyway, hopefully this is enough to see it in action. Its annoying, but I guess 
I get why I dont see those messages alerts.

(And yes, I did a scan all new mail to me after I logged on, and saw the 1 new m
essage from PVT_TEST as expected).


...δεσ∩

---
 ■ Synchronet ■ AnsiTEX bringing back videotex but with ANSI

Previous Message       Next Message
In Reply To: imsg on incoming echomail (Digital Man)
Replies: imsg on incoming echomail (Digital Man)imsg on incoming echomail (Digital Man)