Digital Man wrote to mark lewis <=-
Re: SBBSecho logging.
By: mark lewis to Digital Man on Wed Dec 30 2015 06:55 pm
Do you know that raw packets are being sent in this case? That is a pretty uncommon configuration.
no, i don't know how joe, michiel and wilfred are set up...
as for uncommon configuration, i switched to raw PKTs years ago... there's no need for bundles, really, when the mailers can compress better on the fly during transmission... then again, i also switched because some of my downlinks
were in really rough areas and pulling one large bundle was tough but they could pull lots of smaller PKTs over several connections without having to start all over at the beginning again ;)
And you're using SBBSecho in this configuration? It be good to know
that at least one sysop is testing that feature. :-)
Joe Delahaye wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Digital Man on Wed Dec 30 2015 23:01:00
Echomail packets are bundled into archives and those bundles are
what is sent to the downlinks. Are you wanting to know the name of
the bundle files created or the actual packets within those bundles?
BinkD has no knowledge of the packets within a bundle it sends or
receives, so I'm not clear how the packet filename (which is what I
assume you meant by "pkt #" in your msg) from the SBBSecho log would
help you. I can add more log output, but if it is too much or the
wrong kind, then that's not going to be helpful to you (or whomever
is having the issue). More clarity is needed.
I don't compress here so binkd sees the pkt #'s that are being sent.. even though there maybe 4 to 5 being sent during one connection to that node.
My request is to log the actual PKT # sbbsecho creates so we can compare the creation, the sending and receiving on one end (anyone who's running sbbsecho for instance). The node in question (non Synch user), says they're not receiving any pkt's being delivered or showing in the bit bucket or being stored in the bad pkt area on his system.
Creating one test message and sending it to the two systems should resolve the issue either way. If there is an issue with sbbsecho (highly doubt), then you'll have some more info to resolve it.
The above is already being tested. We found that although the packet
name at least was created, (archived), when the connections were made,
the mail went to the one system, and tried to send to the other, but
file not found.
Joe Delahaye wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Joe Delahaye on Sun Jan 03 2016 17:40:00
The above is already being tested. We found that although the
packet name at least was created, (archived), when the connections
were made, the mail went to the one system, and tried to send to the
other, but file not found.
Were there not two separate PKT's created for each node? Why not remove archieving from the equation and just create a .*lo file as well and check your binkd logs.
I tried that, resulting in an over abundance of .pkt files sitting in
the outbound. Some of my nodes only collect mail maybe once a week or less, and that becomes a problem in my mind at least <G>. When packets are created, it seems that they mostly go to the master outbound
folder, with the .lo files mostly going to the proper areas (i.e. outbound.002), but not always
Digital Man wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Joe Delahaye on Mon Jan 04 2016 09:07 am
Joe Delahaye wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Joe Delahaye on Sun Jan 03 2016 17:40:00
The above is already being tested. We found that although the
packet name at least was created, (archived), when the connections
were made, the mail went to the one system, and tried to send to the
other, but file not found.
Were there not two separate PKT's created for each node? Why not remove archieving from the equation and just create a .*lo file as well and check your binkd logs.
I tried that, resulting in an over abundance of .pkt files sitting in the outbound. Some of my nodes only collect mail maybe once a week or less, and that becomes a problem in my mind at least <G>. When packets are created, it seems that they mostly go to the master outbound folder, with the .lo files mostly going to the proper areas (i.e. outbound.002), but not always
OK.... that's fair. One other thing, could you post from echocfg your "Toggle Options"? If I can remember correctly, you had Fuzzy Zone disabled. I've always had that enabled and have no issue.
Fuzzy Zone operations effect NetMail only, not EchoMail.
Digital Man wrote to Bill McGarrity <=-
Joe Delahaye wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Joe Delahaye on Sun Jan 03 2016 17:40:00
The above is already being tested. We found that although the
packet name at least was created, (archived), when the connections
were made, the mail went to the one system, and tried to send to the
other, but file not found.
Were there not two separate PKT's created for each node? Why not remove archieving from the equation and just create a .*lo file as well and check your binkd logs.
I tried that, resulting in an over abundance of .pkt files sitting in the outbound. Some of my nodes only collect mail maybe once a week or less, and that becomes a problem in my mind at least <G>. When packets are created, it seems that they mostly go to the master outbound folder, with the .lo files mostly going to the proper areas (i.e. outbound.002), but not always
OK.... that's fair. One other thing, could you post from echocfg your "Toggle Options"? If I can remember correctly, you had Fuzzy Zone disabled. I've always had that enabled and have no issue.
Fuzzy Zone operations effect NetMail only, not EchoMail.
Digital Man wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Digital Man on Mon Jan 04 2016 02:32 pm
Digital Man wrote to Bill McGarrity <=-
Hiya Rob...
Joe Delahaye wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Joe Delahaye on Sun Jan 03 2016 17:40:00
The above is already being tested. We found that although the
packet name at least was created, (archived), when the connections
were made, the mail went to the one system, and tried to send to the
other, but file not found.
Were there not two separate PKT's created for each node? Why not remove archieving from the equation and just create a .*lo file as well and check your binkd logs.
I tried that, resulting in an over abundance of .pkt files sitting in the outbound. Some of my nodes only collect mail maybe once a week or less, and that becomes a problem in my mind at least <G>. When packets are created, it seems that they mostly go to the master outbound folder, with the .lo files mostly going to the proper areas (i.e. outbound.002), but not always
OK.... that's fair. One other thing, could you post from echocfg your "Toggle Options"? If I can remember correctly, you had Fuzzy Zone disabled. I've always had that enabled and have no issue.
Fuzzy Zone operations effect NetMail only, not EchoMail.
One thing I did find in my logs...
2016-01-04 14:12:24 ERROR line 1836 renaming c:\fd\outbound\04141202.pk_ to c:\fd\outbound\04141202.pkt
Interesting. Is this a one time occurrence or have you seen this error before? Is it possible there were 2 instance of SBBSecho running at
this time (e.g. one spawned by Synchronet timed event and another
spawned by another means)? I don't really have another explanation for that at this time, but it certainly should not happen.
2016-01-04 14:12:24 Sending packet (c:\fd\outbound\04141202.pkt) to 24:110/1 2016-01-04 14:16:04 Stray Outbound Packet (c:\fd\outbound\04141202.pk_) possibly still in use (ftime: Mon Jan 04 14:12:02 2016)
Now when I checked the folder, both 04141202.pk_ and 04141202.pkt were listed and what does "possibly still in use" mean?
A .pk_ file is a temporary packet (i.e. a packet under construction). Stray temporary packets less than 60 minutes old are not processed by SBBSecho since it may be possible that some other instance of SBBSecho
is actually working on that packet. The "rename" error before this was
the cause of the stray temporary packet. After 60 minutes, that packet should have been handled by SBBSecho and been sent out.
Digital Man wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Digital Man on Tue Jan 05 2016 07:40 pm
Digital Man wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Digital Man on Mon Jan 04 2016 02:32 pm
Digital Man wrote to Bill McGarrity <=-
Hiya Rob...
Joe Delahaye wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Joe Delahaye on Sun Jan 03 2016 17:40:00
The above is already being tested. We found that although the
packet name at least was created, (archived), when the connections
were made, the mail went to the one system, and tried to send to the
other, but file not found.
Were there not two separate PKT's created for each node? Why not remove archieving from the equation and just create a .*lo file as well and check your binkd logs.
I tried that, resulting in an over abundance of .pkt files sitting in the outbound. Some of my nodes only collect mail maybe once a week or less, and that becomes a problem in my mind at least <G>. When packets are created, it seems that they mostly go to the master outbound folder, with the .lo files mostly going to the proper areas (i.e. outbound.002), but not always
OK.... that's fair. One other thing, could you post from echocfg your "Toggle Options"? If I can remember correctly, you had Fuzzy Zone disabled. I've always had that enabled and have no issue.
Fuzzy Zone operations effect NetMail only, not EchoMail.
One thing I did find in my logs...
2016-01-04 14:12:24 ERROR line 1836 renaming c:\fd\outbound\04141202.pk_ to c:\fd\outbound\04141202.pkt
Interesting. Is this a one time occurrence or have you seen this error before? Is it possible there were 2 instance of SBBSecho running at this time (e.g. one spawned by Synchronet timed event and another spawned by another means)? I don't really have another explanation for that at this time, but it certainly should not happen.
OK... that is quite possible. Naturally I run fidoin when I get something from my uplink and then it processes it to downlinks but I also have a timed event fidoout running every 10 minutes for netmail to be processed. There could be an overlap. Interesting...
When you say you "run fidoin", does that mean you trigger the timed
event by touching a semaphore file or you're running SBBSecho
externally somehow?
The normal/best way to run SBBSecho (for both import and export) is
*only* from the Synchronet event thread. This will insure that there is only one instance of SBBSecho running at a time and avoid race
conditions that could cause the kind of error you reported.
Lord Time wrote to Bill McGarrity <=-
OK... that is quite possible. Naturally I run fidoin when I get something from my uplink and then it processes it to downlinks but I also have a timed event fidoout running every 10 minutes for netmail to be processed. There could be an overlap. Interesting...
hmmm, you run fidonin way more then I do, mine is set at every 15 mins
(96 times a day), I figure as a fidonet hub boss, my net (league 10), whispernet hub, (was another net hub) every 15 mins would be enought
Digital Man wrote to Bill McGarrity <=-
Yes, fidoin is triggered by a semaphore ONLY. Being I have downlinks, as soon as sbbsecho does it's thing importing, it creates outbound pkt's, as you well know. I run a timed event for fidoout incase there are any *.msg's sitting in my netmail so they get converted and sent. I don't get many callers but if someone wants to send a netmail, I really don't want it sitting around waiting for fidoout to run.
The solution to that is set set SCFG->Networks->FidoNet->NetMail
Semaphore to your ../data/fidoout.now file. Then whenever Synchronet creates a NetMail message (e.g. a user sends NetMail), then the
"FIDOUT" event will run.
The normal/best way to run SBBSecho (for both import and export) is *only* from the Synchronet event thread. This will insure that there is only one instance of SBBSecho running at a time and avoid race conditions that could cause the kind of error you reported.
Agreed, but now that you told me the stray pk_ gets converted after 60 minutes, i'm not too worried. Yes, statistically two instances can, and have run together but it doesn't create a huge issue.
If you're only running one instance of Synchronet and SBBSecho is only
run via Synchronet timed-event, then two instance shouldn't be able to
run concurrently. (Unless you have the events configured for
"background execution", which you should not).
Joe Delahaye wrote to Digital Man <=-
Re: Re: SBBSecho logging.
By: Digital Man to Joe Delahaye on Wed Jan 06 2016 14:17:21
I think we're good now. If you see another problem, let me know, and as usual, the log snippets usually help.
I'm not certain yet. Had a problem today. Could not toss mail in or
out due to a node being locked with a .bsy file. Finally cleared that.
Had to shut down binkd to remove the .bsy files, and then most mail
went out, and inbound got imported. I'll keep an eye on it.
I have another question that may seem silly. As RC I get netmails from the NCs and the ZC, from Makenl. Those are addressed to Coordinator at either my 303 address or my 12/0 address. I have all my node numbers
as AKA, and while I would have to check to be certain right now, I'm pretty sure that I have coordinator as an aka as well. None of these
are imported, so I do not see those netmails, other then with another
old reader. Is there anything special I have to do to get those
imported?
Joe Delahaye wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Joe Delahaye on Wed Jan 06 2016 19:29:00
I'm not certain yet. Had a problem today. Could not toss mail in
or out due to a node being locked with a .bsy file. Finally cleared
that. Had to shut down binkd to remove the .bsy files, and then most
mail went out, and inbound got imported. I'll keep an eye on it.
Binkd offers a command to kill .bsy files... kill-old-bsy 12h
Yeah, I have that turned on. but 12 hours would be a long time to wait
to import or export <G> I know you can change it. I wish the old .try files would disappear as well, since they clutter up the directory.
I have another question that may seem silly. As RC I get netmails
from the NCs and the ZC, from Makenl. Those are addressed to
Coordinator at either my 303 address or my 12/0 address. I have all
my node numbers as AKA, and while I would have to check to be
certain right now, I'm pretty sure that I have coordinator as an aka
as well. None of these are imported, so I do not see those
netmails, other then with another old reader. Is there anything
special I have to do to get those imported?
Was wondering the same thing but I have Frontdoor's FM editor to see them. I get "Unknown User" in sbbsecho log unless I delete them. It's no biggie for me as I read and delete anyway.
I used Intermail's editor for that, but it seems to be sporadic in
nature these days. It is getting long in the tooth for sure and
Windows 10 is not helping it any.
Joe Delahaye wrote to Bill McGarrity <=-
Re: Re: SBBSecho logging.
By: Bill McGarrity to Joe Delahaye on Fri Jan 08 2016 18:22:00
I used Intermail's editor for that, but it seems to be sporadic in
nature these days. It is getting long in the tooth for sure and
Windows 10 is not helping it any.
Being I run htick for my fileareas here, the -y for fidoin can't be used as it imports the filefix netmail. It's not biggie actually, I just go delete the Cordinator MakeNL mail when I see it.
I run Htick as well, in addition to Tick. I do not h ave filefix
turned, as I am not that conversant with htick in any case. It is an
old version and a very old setup <G>
| Sysop: | Nelgin |
|---|---|
| Location: | Plano, TX |
| Users: | 513 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 21:03:42 |
| Calls: | 8,291 |
| Calls today: | 4 |
| Files: | 15,520 |
| Messages: | 928,831 |