Good evening,
I pulled and recompiled syncrhonet on my linux system on Sunday morning, 10/7. Since then, I have noticed an issue. I do not think it has been happening the whole time, but has been happening for the last couple of days.

Whenever a REP packet is uploaded via FTP, the system does not automatically unpack it like it used to. I have had to (q)uit sbbs and start it over, at which point it will unpack any REP packets that are waiting.

In past, I think I used to notice it doing this when another event was hung, like FIDOIN or FIDOOUT. However, in those instances, the hung event would also run when I restarted the system. In the instances I have noticed this week, there does not appear to be another event waiting... I have actually watched other events run while waiting for the REP to unpack (before giving up and restarting).

Unfortunately, there is also no error message. The console shows the packet being uploaded and all appears normal, just no unpack activity.

Thanks!

---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: QWK packet issues
By: Dumas Walker to Digital Man on Thu Oct 11 2018 07:20 pm

Good evening,
I pulled and recompiled syncrhonet on my linux system on Sunday morning, 10/7. Since then, I have noticed an issue. I do not think it has been happening the whole time, but has been happening for the last couple of days.

Whenever a REP packet is uploaded via FTP, the system does not automatically unpack it like it used to. I have had to (q)uit sbbs and start it over, at which point it will unpack any REP packets that are waiting.

In past, I think I used to notice it doing this when another event was hung, like FIDOIN or FIDOOUT. However, in those instances, the hung event would also run when I restarted the system. In the instances I have noticed this week, there does not appear to be another event waiting... I have actually watched other events run while waiting for the REP to unpack (before giving up and restarting).

Unfortunately, there is also no error message. The console shows the packet being uploaded and all appears normal, just no unpack activity.

Check the last log output from your event thread to determine the event that's stuck (and preventing other events from running).

digital man

This Is Spinal Tap quote #5:
Nigel Tufnel: Authorities said... best leave it... unsolved.
Norco, CA WX: 66.2øF, 58.0% humidity, 8 mph ENE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

10-11-18 19:20 Dumas Walker wrote to Digital Man about QWK packet issues
Howdy! Mike,

@MSGID: <5BBFDAC9.26365.sync@capitolcityonline.net>
Good evening,
I pulled and recompiled syncrhonet on my linux system on Sunday
morning, 10/7. Since then, I have noticed an issue. I do not think it
has been happening the whole time, but has been happening for the last couple of days.

Whenever a REP packet is uploaded via FTP, the system does not automatically unpack it like it used to. I have had to (q)uit sbbs and start it over, at which point it will unpack any REP packets that are waiting.

In past, I think I used to notice it doing this when another event was hung, like FIDOIN or FIDOOUT. However, in those instances, the hung
event would also run when I restarted the system. In the instances I
have noticed this week, there does not appear to be another event waiting... I have actually watched other events run while waiting for
the REP to unpack (before giving up and restarting).

Unfortunately, there is also no error message. The console shows the packet being uploaded and all appears normal, just no unpack activity.

Thanks!

Reading about REP packet uploaded via FTP makes me wonder did ED DO IT?
(again)


... DOES ANYBODY ELSE THINK IT'S TOO QUIET IN HERE-The Family Circus20180607 --- MultiMail/MS-DOS v0.49
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Check the last log output from your event thread to determine the event that's >stuck (and preventing other events from running).

Where does one find that? The only log output I am ever able to find shows
the telnet and http connections and not much else.

That said, I believe it is binkit that is hanging. I cannot find the
binkit log output, either, but I do have the output from the system I am
trying to connect with. It appears that we are connecting securely but
then the file transfers are hanging.

+ 2018.10.12 12:01:00 BINKP 1-HostName host-067-131-057-133.dhcp.fewpb.net + 2018.10.12 12:01:00 BINKP
1-Country United States of America (US) + 2018.10.12 12:01:00 BINKP
1-C: NUL OPT CRYPT + 2018.10.12 12:01:00 BINKP 1-S: NUL OPT SSL CRAM-MD5-6b161b2a6a3bcd0a60383d0f10917adc
+ 2018.10.12 12:01:00 BINKP 1-S: NUL SYS fsxHUB [fsxNet WHQ]
+ 2018.10.12 12:01:00 BINKP 1-S: NUL ZYZ Paul Hayton
+ 2018.10.12 12:01:00 BINKP 1-S: NUL VER Mystic/1.12A39 binkp/1.0
+ 2018.10.12 12:01:00 BINKP 1-S: ADR 21:1/100@fsxnet 21:1/3@fsxnet 21:1/2@fsxnet 21:1/0@fsxnet 21:0/0@fsxnet
+ 2018.10.12 12:01:02 BINKP 1-C: NUL SYS Capitol City Online
+ 2018.10.12 12:01:02 BINKP 1-System Capitol City Online
+ 2018.10.12 12:01:02 BINKP 1-C: NUL ZYZ Mike Powell
+ 2018.10.12 12:01:02 BINKP 1-SysOp Mike Powell
+ 2018.10.12 12:01:02 BINKP 1-C: NUL LOC Frankfort, KY
+ 2018.10.12 12:01:02 BINKP 1-Location Frankfort, KY
+ 2018.10.12 12:01:02 BINKP 1-C: NUL NDL 115200,TCP,BINKP
+ 2018.10.12 12:01:02 BINKP 1-Info NDL 115200,TCP,BINKP
+ 2018.10.12 12:01:02 BINKP 1-C: NUL TIME Thu Oct 11 2018 19:01:06 GMT-0400 (EDT)
+ 2018.10.12 12:01:02 BINKP 1-Info TIME Thu Oct 11 2018 19:01:06
GMT-0400 (EDT)
+ 2018.10.12 12:01:02 BINKP 1-C: NUL VER BinkIT/2.10,JSBinkP/1.111,sbbs3.17a/Linux binkp/1.1
+ 2018.10.12 12:01:02 BINKP 1-Mailer BinkIT/2.10,JSBinkP/1.111,sbbs3.17a/Linux binkp/1.1
+ 2018.10.12 12:01:02 BINKP 1-C: ADR 21:1/175@fsxnet
1:2320/105@fidonet 276:10/0@gtpower 637:1/112.8@happynet
454:1/105@ilink 618:250/1@micronet 314:314/25@pinet 1337:3/103@tqwnet 432:1/120@vkradio + 2018.10.12 12:01:02 BINKP 1-C: PWD
+ 2018.10.12 12:01:02 BINKP 1-Authenticating 21:1/175@fsxnet by
CRAM-MD5 + 2018.10.12 12:01:02 BINKP 1-S: OK secure
+ 2018.10.12 12:01:02 BINKP 1-Queued 12 files for 21:1/175@fsxnet
+ 2018.10.12 12:01:03 BINKP 1-Sending: 0000ffb5.th1 (69,340 bytes)
+ 2018.10.12 12:01:03 BINKP 1-S: FILE 0000ffb5.th1 69340 1539302326 0
+ 2018.10.12 12:01:36 BINKP 1-Connection lost
+ 2018.10.12 12:01:36 BINKP 1-Session ended (0 sent, 0 rcvd, 0 skip)
+ 2018.10.12 12:01:36 BINKP 1-Client shutting down

It did not hang when I ran it just now but it did fail:

10/13 14:17:43 evnt BINKIT Attempting poll for node 21:1/100@fsxnet
10/13 14:17:43 evnt BINKIT JSBinkP/1.111 callout to 21:1/100@fsxnet started 10/13 14:17:43 evnt BINKIT Connecting to agency.bbs.nz:24556
10/13 14:17:53 evnt BINKIT Connection to agency.bbs.nz:24556 failed.

---
þ SLMR 2.1a þ Got my tie caught in the fax... Suddenly I was in L.A.
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: QWK packet issues
By: Dumas Walker to DIGITAL MAN on Sat Oct 13 2018 02:21 pm

Check the last log output from your event thread to determine the event that's >stuck (and preventing other events from running).

Where does one find that?

In the BBS's log output. http://wiki.synchro.net/monitor:syslog

The only log output I am ever able to find shows
the telnet and http connections and not much else.

You need to be able to watch/review all of your BBS's log output.

digital man

Synchronet "Real Fact" #38:
Synchronet first supported Windows NT-based operating systems w/v3.00b (2000). Norco, CA WX: 59.7øF, 91.0% humidity, 1 mph ESE wind, 0.52 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Where does one find that?

In the BBS's log output. http://wiki.synchro.net/monitor:syslog

So if you don't run daemon you don't get any logging? I am leary of
running beta software in the background as I don't really have any idea
when something is amiss. For example, it would have taken a lot longer to figure out that I had something hung and that no REP packets were unpacking.
I probably still would not know.

In console mode, I could see it immediately after I uploaded a packet.

You need to be able to watch/review all of your BBS's log output.

I agree, see above. It does not make much sense to me that output that is caught in daemon cannot be caught somewhere when running in console. I understand maybe not in /var/log, but not why not in /sbbs/data/logs.

Sorry if I am misunderstanding what I read on that page. Please let me
know if that is the case. Thanks!

---
þ SLMR 2.1a þ How do you tell when you're out of invisible ink?
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: QWK packet issues
By: Dumas Walker to DIGITAL MAN on Sun Oct 14 2018 10:05 am

Where does one find that?

In the BBS's log output. http://wiki.synchro.net/monitor:syslog

So if you don't run daemon you don't get any logging?

No, it "logs" to the console. But if you want to log to syslog without running daemonized, you can pass the "syslog" command-line option to sbbs.

I am leary of
running beta software in the background as I don't really have any idea
when something is amiss. For example, it would have taken a lot longer to figure out that I had something hung and that no REP packets were unpacking. I probably still would not know.

Actually, if you're monitoring your syslog output, you'd likely know sooner.

In console mode, I could see it immediately after I uploaded a packet.

You need to be able to watch/review all of your BBS's log output.

I agree, see above. It does not make much sense to me that output that is caught in daemon cannot be caught somewhere when running in console. I understand maybe not in /var/log, but not why not in /sbbs/data/logs.

It can go where ever you like based on your configuration of syslog.

Sorry if I am misunderstanding what I read on that page. Please let me
know if that is the case. Thanks!

It's usually preferable to run daemonized, but if you don't want to, that's your choice. You can still log to the syslog or scroll-back your console buffer to find the log output which tells you what you need to know.

digital man

Synchronet "Real Fact" #88:
SBBSecho v3.00 was first committed to cvs.synchro.net on Apr-11-2016.
Norco, CA WX: 64.1øF, 81.0% humidity, 2 mph ESE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Where does one find that?

In the BBS's log output. http://wiki.synchro.net/monitor:syslog

So if you don't run daemon you don't get any logging?

No, it "logs" to the console. But if you want to log to syslog without running >daemonized, you can pass the "syslog" command-line option to sbbs.

Awesome, I shall try that out. In the meantime, whatever was going on with binkit seems to have worked itself out. Thanks!

---
þ SLMR 2.1a þ ....we came in?
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

On 2018 Oct 14 10:05:00, you wrote to DIGITAL MAN:

Where does one find that?

In the BBS's log output. http://wiki.synchro.net/monitor:syslog

So if you don't run daemon you don't get any logging? I am leary of running beta software in the background as I don't really have any
idea when something is amiss. For example, it would have taken a lot longer to figure out that I had something hung and that no REP packets were unpacking. I probably still would not know.

FWIW: i have sbbs starting automatically in daemon mode... then i specifically ssh in a few times and in each login, i run a script similar to the following...


----->8 ~/monitor_sbbs 8<-----

if [ -z "$1" ]; then
sudo tail -F /var/log/syslog | egrep -e "synchronet"
else
sudo tail -F -n $1 /var/log/syslog | egrep -e "synchronet"
fi

----->8 ~/monitor_sbbs 8<-----


we can take that output and filter it further if we decide to watch things in individual logins...


eg:
$ ~/monitor_sbbs 100000 | egrep -e " ftp "
$ ~/monitor_sbbs 100000 | egrep -e " irc "
$ ~/monitor_sbbs 100000 | egrep -e " web "
$ ~/monitor_sbbs 100000 | egrep -e " evnt "
$ ~/monitor_sbbs 100000 | egrep -e " svcs "
$ ~/monitor_sbbs 100000 | egrep -e " term "

the number is the number of lines from the end of the file for tail to start displaying...

here's one for monitoring sbbsecho.log, too... it works the same was as above except there's only sbbsecho output available in the sbbsecho.log file...


----->8 ~/monitor_sbbsecho 8<-----

if [ -z "$1" ]; then
sudo tail -F /sbbs/data/sbbsecho.log
else
sudo tail -F -n $1 /sbbs/data/sbbsecho.log
fi

----->8 ~/monitor_sbbsecho 8<-----


HTH

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Good examples have twice the value of good advice.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net