Good morning,
I have two users (+ myself), and several QWK nodes, that use the QWK via
ftp function of Synchronet. Over the past several days, all three users
and at least one of the nodes has had issues with the QWK session starting and never completing.
I am not seeing any errors on this end. On the user end, it varies between getting an eventual time out message to never seeing anything and
eventually aborting (at which point they get a 421 message).
I used to assume it was happening to me because my QWK packets were large, so I have started downloading them via telnet sessions. However, it
is turning out that is not the issue as one of the users, when they
got a packet via telnet, only had 3 messages waiting.
Has anyone else had this happen? Like I said, the session appear normal on this end, and I don't see anything in the logs.
Thanks!
You'll need to examine the logs more closely. The Event Thread is responsible f
r creating QWK packets that are to be FTP-downloaded, so if your Event Thread i
n't running or busy doing something else, QWK packets can't be created for FTP-
ownload.
You'll need to examine the logs more closely. The Event Thread is responsible f
r creating QWK packets that are to be FTP-downloaded, so if your Event Thread i
n't running or busy doing something else, QWK packets can't be created for FTP-
ownload.
Well, I was looking for error messages when there apparently are none.
Turns out I found a hung binkit session (with no error messages) that was the apparent cause. Tried to "q"uit sbbs but it then "hung" waiting for the terminal server to close. After waiting 5-10min, I gave the process a sigkill, restarted it, let it get started, "q"uit it again (to get a clean exit because ftp qwk still was not working), and started it a third time.
That seemed to clear it up.
I find it a little odd, though, that this causes the QWK packets not to create but yet won't stop another binkit event from eventually running and, too, also getting stuck. Seems like QWK packets via ftp were the only
thing not working.
The hung binkit sessions are with a mystic system. For some reason, we are bouncing the same few messages back and forth between us, and the packet has got so big that one of our sides times-out trying to send it but does not actually tell the other side, causing binkit to just sit there like it thinks the transfer is still going on.
Thing is, I don't even get that echo from the system in question and I cannot figure out what is causing sbbsecho to try to send it back as an OUT (like
it is netmail) instead of sending it in an archive like it does other echo traffic.
Also don't know why his system keeps sending it back to mine since
I don't pull that echo from that node, and it seems to send it back even after I delete the offending OUT on this side.
I have ZIPped up the OUT file in question and am going to share it with that sysop to see if he knows why his system keeps sending it back.
I may send it to you, too, if you want to see it.
It is a set of old
messages from Bill McGarrity from c2017 (I think) that somehow started flowing back and forth between us about a month ago in a bridged newsgroup.
I have not seen these messages show up in said newsgroup as seeing mail from Bill would have raised a "has he come back?" flag, or a "I have a
dupes issue" flag. :)
If there is an easier way to clear out a thread that is hung up like that
I would like to know. I tried deleting the *.bsy file and that did not
seem to clear it up.
The log output from one of these sessions could be helpful in debugging and fi[...]
ng the problem.
A careful read of the log output will likely explain what's going on.
The log output from one of these sessions could be helpful in debugging and fi[...]
ng the problem.
A careful read of the log output will likely explain what's going on.
I looked it over pretty good a couple of times and could never find an error, just where the connection began and then eventually the messages ceasing with nothing else happened. I have all of my logging going to syslog. If there is nothing in there that is too sensitive,
I would not mind sharing it. I kept copies of some days it happened.
Actually, there is an error of sorts. The first 'evnt BINKIT' message in the syslog for 11/14 is at approx. 3:34am where it says "Send failure."
That event would have started sometime the day before, several hours earlier and I am not able to find the previous message. The event continues and exits
with '0' at 03:35.
At 06:00 that same day, the next timed BINKIT event starts. The 'evnt BINKIT' messages soon disappear, and the "Send failure" message does not show up until 13:43 that afternoon. I do not see any 'evnt BINKIT'
messages in between, although they could be there as the search function of mcview appears to be seriously challenged with a file so large. That event ends at 13:44 and then a bunch of stuff that has been waiting in the meantime kicks off, including another BINKIT timed event that stops sending any messages at 13:46. That was on 11/14. The next 'evnt BINKIT' message
I can find in the syslog is a "Send failure" at 03:33 on *11/16*.
Like I said I would not mind sharing but I do not see anything showing up between what appears to be a normal message and the "Send failure" several hours later. At the very least, I think it might be good to have it time-out and continue after a few minutes of inactivity.
show up until 13:43 that afternoon. I do not see any 'evnt BINKIT'
messages in between, although they could be there as the search
function of mcview appears to be seriously challenged with a file
so large. That event ends at 13:44 and then a bunch of stuff that
has been waiting in the
It sounds like that "Send failure" might be exactly the log message which indic
tes the problem.
hours later. At the very least, I think it might be good to have it time-out and continue after a few minutes of inactivity.I agree, that's how it's supposed to work already. I look into why it might not
be in your case.
zgrep -E -e "^Nov 2. .* evnt .*BINKIT" /var/log/syslog
will show all BINKIT lines for days in november from the 20th to the 29th...
change the "2." to "[12]." and it'll be the 10th through the 29th...
maybe that helps?
Yes. One question, the syslogs that are gziped change names (i.e. syslog.2.gz, syslog.3.gz, etc. Does the command line above go through all of the syslog.* files, or do you have to change the name for each one?
Mine roll over daily.
Yes. One question, the syslogs that are gziped change names (i.e.
syslog.2.gz, syslog.3.gz, etc. Does the command line above go through all >DW> of the syslog.* files, or do you have to change the name for each one?
no, something like
zgrep -E -e " evnt .*BINKIT " /var/log/syslog*
will go through all of them...
zgrep -E -e " evnt .*BINKIT " /var/log/syslog.{1,2,3}
zgrep -E -e " evnt .*BINKIT " /var/log/syslog.{1,2,3}
Thanks for the pointers. I had heard of grep but never of zgrep!
| Sysop: | MCMLXXIX |
|---|---|
| Location: | Prospect, CT |
| Users: | 325 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 42:51:53 |
| Calls: | 508 |
| Messages: | 220032 |